微服务架构简介

从单体应用架构发展到SOA架构，再到微服务架构，应用架构经历了多年的不断演进。微服务架构不是凭空产生的，而是技术发展的必然结果，分布式云平台的应用环境使得微服务代替单体应用成为互联网大型系统的架构选择。目前，虽然微服务架构还没有公 认的技术标准和规范草案，但业界已经有了一些很有影响力的开源微服务架构解决方案，在进行微服务化开发或改造时可以进行相应的参考。

目前软件架构有三种架构类型，分别是业务架构、应用架构、技术架构。它们之间的关系是业务架构决定应用架构，技术架构支撑应用架构。架构的发展历程是从单体架构、分布式架构、SOA架构再到微服务架构，如下图所示。

单体应用架构

传统的单体架构在Java领域可以理解为一个Web应用，大部分Web工程都是将所有的功能打包在一起部署和运行。按照程序调用顺序，从上到下为表示层、业务层、数据访问层、DB层。如下图所示

因为所有的功能模块都是在一个工程编写的，所以从开发和测试的角度来看，开发人员可以在短时间内就开发出单体应用，并且由于没有过多的依赖项，测试也可以节约很多时间。

但是，随着应用不断的发展，开发团队不断的扩张之后，单体应用的不足和弊端就会很明显的暴露出来，主要有以下不足点：

• 灵活度不够：如果程序有任何修改，那么修改的不止一个点，可能需要从上到下地去修改，并且测试的时候必须等到整个程序部署完才能看出效果，并且由于整个开发工作都是在一个工程下进行的，可能需要等待其他开发人员开发完成才能完成部署，大大的降低了团队的灵活性。
• 可靠性：一旦出现了bug，影响的将是整个应用。因为所有的模块功能都是运行在一个进程中的。
• 复杂性高：单体应用的代码量可能会让团队新来的成员望而生畏，应用难以理解和迭代，从而到时开发速度大大降低。
• 系统扩展性差：添加新东西的时候不能针对某个点增加，要全局性增加。
• 系统启动慢：一个应用包含了所有功能模块，导致系统的启动时间较长。

SOA架构

SOA的核心主体是服务，其目标是通过服务的流程化来实现业务的灵活性。服务就像一堆“元器件”，这些元器件通过封装形成标准服务，它们有相同的接口和语义表达规则。但服务要组装成一个流程和应用，还需要有效的“管理”，包括如何注册服务、如何发现服 务、如何包装服务的安全性和可靠性，这些就是SOA治理。SOA治理是将 SOA 的一堆元器件进行有效组装。这是形成一个“产品”的关键，否则那些永远是一堆元器件，而无法形成一个有机整体。
完整的SOA架构由五大部分组成：基础设施服务、企业服务总线、关键服务组件、开发工具、管理工具等。

• 基础设施：为整个SOA组件和框架提供一个可靠的运行环境，以及服务组件容器，它的核心组件是应用服务器等基础软件支撑设施，提供运行期完整、可靠的软件支撑 。
• 企业服务总线：提供可靠消息传输、服务接入、协议转换、数据格式转换、 基于内容的路由等功能，屏蔽了服务的物理位置、协议和数据格式 。
• 关键服务组件：SOA在各种业务服务组件的分类。
• 开发工具和管理工具：提供完善的、可视化的服务开发和流程编排工具，包括服务的设计、开发、 配置、部署、监控、重构等完整的SOA项目开发生命周期 。

SOA 架构中有两个主要角色：服务提供者（Provider）和服务消费者（Consumer）。
SOA架构的优点：

• 把模块拆分， 使用接口通信， 降低模块之间的耦合度。
• 把项目拆分成若干个子项目，不同的团队负责不同的子项目。
• 增加功能时只需要增加一个子项目，调用其他系统的接口即可。
• 可以灵活地进行分布式部署。

SOA 架构的缺点：系统之间的交互需要使用远程通信， 接口开发增加工作量 。

微服务架构

微服务的概率最早是由 Martin Fowler 与 James Lewis 于 2014 年共同提出。根据其描述，总体来说，微服务是一种架构风格， 对于一个大型复杂的业务系统，它的业务功能可以拆分为多个相互独立的微服务，各个微服务之间是松搞合的，通过各种远程协议进行同步／异步通信，各微服务均可以被独立部署、 扩／缩容以及升／降级。这些服务是基于业务逻辑和范围，通过自动 化部署的机制来独立部署的，并且服务的集中管理应该是最低限度的，即每个服务可以采用不同的编程语言编写，使用不同的数据存储技术 。
如今，微服务架构已经不是一个新概念了，很多业界前沿互联网公司的实践表明，微服务是一种渐进式的演进架构，是企业应对业务复杂性，支持大规模持续创新行之有效的架构手段。

微服务组成

微服务架构是一种比较复杂、内涵丰富的架构模式，它包含很多支撑“微”服务的具体组件和概念，其中一些常用的组件及其概念如下：

• 服务注册与发现：服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址。
• 负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，服务节点选择的过程对服务调用方来说是透明的。
• 服务网关：服务网关是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、 A/B测试、负载限流等功能。
• 配置中心：将本地化的配置信息（ Properties 、 XML 、 YAML 等形式）注册到配置中心，实现程序包在开发、测试、生产环境中的无差别性，方便程序包的迁移。
• 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形 式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够 在统一的界面中使用系统。
• 调用链监控：记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
• 支撑平台：系统微服务化后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控等都比单体应用架构更加复杂，这就需要将大部分的工作自动化。 现在，Jenkins、Docker、Kubernetes等工具可以给微服务架构的部署带来较多的便利，例如持续集成、蓝绿 发布、健康检查、性能健康等等。如果没有合适的支撑平台或工具，微服务架构就无法发挥它最大的功效 。

微服务架构模式有很多优势可以有效解决单体应用扩大之后出现的大部分问题。首先，通过将巨大单体式应用分解为多个服务的方法解决了复杂性问题。在功能不变的情况下，应用分解为多个可管理的模块或服务。每个服务都有一个用RPC或者消息驱动API定义清楚的边界。微服务架构模式为采用单体式编码方式，由此，单个服务变得很容易开发、理解和维护。
其次，微服务架构模式使得团队并行开发得以推进，每个服务都可以由专门开发团队来开发。不同团队的开发者可以自由选择开发技术，提供API服务。这种自由意味着开发者不需要被迫使用之前采用的过时技术，他们可以选择最新的技术。甚至于，因为服务都是相对简单的，即使用新技术重写以前的代码也不是很困难的事情。

微服务的一些想法是好的，但在实践中也会呈现出其复杂性，具体如下：

• 运维要求较高：更多的服务意味着需要更多的运维投入。在单体架构中只需要保证一个应用的正常运行即可；而在微服务中，需要保证几十甚至几百个服务的正常运行与协作，这带来了巨大的挑战。
• 分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统来说，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
• 接口调整成本高：微服务之间通过接口进行通信。 如果修改某个微服务的API，可能所有使用了该接口 的微服务都需要做调整。
• 重复劳动：很多服务可能都会使用到相同的功能， 而这个功能并没有达到分解为一个微服务的程度， 这个时候，可能各个服务都会开发这一功能，导致代码重复。
• 可测试性的挑战：在动态环境下，服务间的交互会产生非常微妙的行为，难以进行可视化及全面测试。

Spring Cloud简介

Spring Cloud是一系列框架的有序集合。目前由 Spring 官方开发维护，基于 Spring Boot 开发，提供一套完整的微服务解决方案。包括服务注册与发现、配置中心、全链路监控、 API 网关、熔断器等开源组件，可以随需扩展和替换组装。Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

Spring Cloud 不同于其他独立项目，它是拥有众多子项目的项目集合。因为 Spring Cloud 的子项目居多，每个子项目有自己的版本号，为了对 Spring Cloud 整体进行版本编号，确定一个可用于生产上的版本标识。这些版本采用伦敦地铁站的名字，按名称首字母排序，比如 Dalston 版、Edgware 版、Finchley 版、Greenwich 版。

Spring Cloud 组成

Spring Cloud 包含的组件众多，各个组件都有各自不同的特性和优点，为使用者提供丰富的选择 ：

• 服务注册与发现组件：Eureka、Zookeeper 和 Consul 等。

• 服务调用组件：Hystrix、Ribbon 和 OpenFeign。其中 Hystrix 能够使系统在出现依赖服务访问不可达的情况下，通过隔离系统依赖服务的方式，防止服务雪崩，同时提供失败回滚机制，使系统能够更快地从异常中恢复。Ribbon 用于提供客户端的软件负载均衡算法，还提供了一系列完善的配置项如连接超时、重试等。OpenFeign 是一个声明式 RESTful 网络请求客户端，它使编写 Web 服务客户端变得更加方便和快捷。

• 路由和过滤组件：包括 Zuul 和 Spring Cloud Gateway。Spring Cloud Gateway 提供了一个构建在 Spring 生态 之上的 API 网关，其旨在提供一种简单而有效的途径来发送API，并为他们提供横切关注点。如：安全性、监控指标和弹性。

• 消息组件：Spring Cloud Stream 和 Spring Cloud Bus。Spring Cloud Stream 对于分布式消息的各种需求进行了抽象，包括发布订阅、分组消费和消息分区等功能，实现了微服务之间的异步通信。Spring Cloud Bus 主要提供了服务间的事件通信（比如：刷新配置 ）。

• 安全控制组件：Spring Cloud Security 基于 OAuth2.0 开放网络的安全标准，提供了微服务环境下的单点登录、资源授权和令牌管理等功能。

• 链路监控组件：Spring Cloud Sleuth 提供了全自动、可配置的数据埋点，以 收集微服务调用链路上的性能数据，并可以结合 Zipkin 进行数据存储、统计和展示。

除了上述组件之外，Spring Cloud 还提供了命令行工具 Spring Cloud Cli 和集群工具 Spring Cloud Cluster。 Spring Cloud Cli 提供了以命令行和脚本的方式来管理微服务及 Spring Cloud 组件的方式，Spring Cloud Cluster 提供了集群选主、分布式锁和一次性令牌等分布式集群需要的技术组件。

组件名称	所属项目	组件分类
Eureka	spring-cloud-netfix	注册中心
Consul	spring-cloud-consul	注册中心
Zookeeper	spring-cloud-zookeeper	注册中心
Zuul	spring-cloud-netfix	第一代网关
Ribbon	spring-cloud-netfix	负载均衡
Hystrix	spring-cloud-netfix	熔断器
Turbine	spring-cloud-netfix	集群监控
Feign	spring-cloud-openfeign	远程调用
Gateway	spring-cloud-gateway	第二代网关
Sleuth	spring-cloud-seluth	链路追踪
Bus	spring-cloud-bus	总线
config	spring-cloud-config	配置中心
Pipeline	spring-cloud-pipeline	部署管道
Dataflow	spring-cloud-dataflow	数据处理
Security	spring-cloud-Security	安全控制

Spring Cloud 并不能与微服务或者微服务架构划上等号，不能误认为使用了 Spring Cloud 的应用服务就是微服务。微服务架构是一种架构的理念，重点是微服务的设计原则，从理论上为具体的技术落地提供了指导思想。Spring Cloud 是一个基于 Spring Boot 实现的服务治理工具包，关注全局的服务治理框架。