Spring Cloud与Docker微服务架构实战（一）——概述与微服务简介

Spring Cloud与Docker微服务架构实战

一些概述性介绍和微服务相关概念简单介绍，重点关注代码实现

一、概述

单体应用存在的一些问题

• 复杂性高
• 技术债务
• 部署频率低
• 可靠性差
• 拓展能力受限
• 阻碍技术创新
• …

微服务定义

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

每种翻译都有自己的侧重点

微服务架构的特性

• 每个微服务独立运行在自己的进程中
• 一系列独立运行的微服务共同构建起整个系统
• 独立业务开发，只关注特定功能
• 轻量级通信
• 使用不同技术栈
• 全自动部署机制

微服务优点

• 易于开发和维护：特定功能，业务清晰，代码量少。
• 单个微服务启动快
• 局部修改容易部署
• 技术栈不受限制
• 按需伸缩

微服务面临的挑战

• 运维要求高：服务多了，运维投入自然多。
• 分布式固有的复杂性：分布式系统，系统容错、网络延迟、分布式事务都会带来巨大挑战
• 接口调整成本高：微服务间通过接口进行通信，修改某个微服务API，可能所有使用了该接口的微服务都要做调整
• 重复劳动：相同功能没有分解成一个微服务，导致重复开发（微服务拆分问题）

微服务设计原则

• 单一职责原则
  • 一个单元（类、方法、服务）只应关注系统中单独有界限的一部分。
• 服务自治原则
  • 每个微服务应具备独立的业务能力、依赖与环境运行。微服务是独立的业务单元，应该与其他服务高度解耦。每个微服务从开发、测试、构建、部署都应可独立运行，不依赖其他服务
• 轻量级通信机制
  • 轻量级通信机制，首先体量较轻
  • 其次应该跨语言、跨平台（REST协议）
  • REST，AMQP，STOMP，MQTT等
• 微服务粒度
  • 代码量的多少不能作为微服务划分依据，不同微服务本身业务复杂性不同，代码量也不同
  • 设计阶段尽早确定边界，微服务之间相对独立保持松散耦合，领域驱动设计中的“界限上下文”可作为划分为服务边界、确定粒度的重要依据

微服务架构

（该图不够严谨，配置服务可以注册到服务发现组件上，服务发现组件也可以从配置服务器读取配置信息）

二、微服务开发框架——Spring Cloud

Spring Cloud特点：

• 约定优于配置
• 适用于各种环境
• 隐藏组件的复杂性，提出声明式、无xml的配置方式
• 开箱即用，快速启动
• 轻量级组件。如Eureka，Zuul等，都是各自领域的轻量级实现
• 组件丰富，功能齐全。Spring Cloud为微服务架构提供了非常完整的支持
• 选型中立、丰富
• 灵活