微服务：微服务的分解和组合模式。

使用微服务架构划分服务和团队是微服务架构实施的重要一步，良好的划分和拆分使系统达到松耦合和高内聚的效果，然后通过微服务的灵活组装可以满足上层的各种各样的业务处理需求。

在微服务架构的需求分析和架构设计过程中，通常使用领域的动词和名词来划分微服务的，例如，对于一个电商后天系统，可以分解为订单、商品、商品目录、库存、购物车、交易、支付、发票、物流等子系统，每个名词和动词都可以是一个微服务，将这几个微服务组合在一起，就实现了电商平台用户购买商品的真个业务流。

这样拆分以后，系统具有敏捷性、灵活性、可伸缩性等，拆分后有多个高度自治的微服务，那么以什么方式组合微服务呢？

服务代理模式

服务代理模式是最简单的服务组合模式，他根据业务的需求选择调用后端的某个服务。在返回给使用端之前，代理可以对后端服务的输出进行加工，也可以直接把后端服务的返回结果返回给使用端。

服务代理模式的架构如下图所示。

在微服务化架构平台下，经常会使用这种模式，典型的案例是做平滑的系统迁移，通常经历如下4个阶段。

• 在新老系统上双写。
• 迁移双写之前的历史遗留数据。
• 将读请求切换到新系统。
• 下调双写逻辑，只写新系统。

服务代理模式常常应用到第3步，一般会对读请求切换设计一个开关，开关打开时查询新系统，开关关闭时查询老系统。

迁移案例中开关的逻辑如下图所示。

服务聚合模式

服务聚合模式是最常用的服务组合模式，他根据业务流程处理的需要，以一定的顺序调用依赖的多个微服务，对依赖的微服务返回的数据进行组合、加工和转换，最后以一定的形式返回给使用方。

这里，每个被依赖的微服务都有自己的缓存和数据库，聚合服务本身可以有自己的数据存储，包括缓存和数据库等，也可以是简单的聚合，不需要持久化任何数据。

服务聚合模式的架构如下图所示。

这里体现了DRY（Don't Repeat Yourself）原则的设计理念，在设计或者构造应用时，最大限度的重用了现有的实现。加入一块业务逻辑由三个独立的逻辑块封装成三个独立运行的微服务，然后用服务集合模式开发聚合服务，将三个独立的逻辑块聚合在一起提供给上层组合服务。这样的设计原则有如下好处。

• 三个独立的子服务可以独自开发、敏捷变更和部署。
• 聚合服务封装下层的业务处理服务，由三个独立的子服务完成数据持久化等工作，项目结构清晰明了。
• 三个独立的子服务对于其他使用方仍然可以重用。

在对微服务进行拆分时，将电商后台系统大致拆分成订单、商品、商品目录、库存、购物车、交易、支付、发票、物流等微服务，那么电商平台的前端应用就是后端各个微服务的一个最大的聚合服务，前端应用通过调用商品和商品目录显示商品列表，提供给用户选择商品的功能，用户选择商品后增加商品到购物车，在用户从购物车结算时，调用交易系统完成交易和支付等。

电商前台的聚合模式的案例架构如下图所示。

另外，聚合服务也可以是一个纯后台服务，通过聚合对使用方输出组合的服务，例如在上面的电商系统案例中，在用户选择结算后，系统调用交易，交易系统

会调用库存系统锁库存，然后创建交易订单，引导用户去支付，支付成功后扣减库存，最后通过发票服务开具电子发票。
电商后台交易服务的聚合模式架构如下图所示。

服务串联模式

服务串联模式类似于一个工作流，最前面的服务1负责接收请求和响应使用方，串联服务后再与服务1交互，随后服务1与服务2交互，最后，从服务2产生的结果经过服务1和串联服务逐个处理后返回给使用方，如下图所示。

服务串联模式之间的调用通常使用同步的RESTful风格的远程调用实现，注意，这种模式采用的是同步调用方式，在串联服务没有完成并返回之前，所有服务都会阻塞和等待，一个请求会占用一个线程来处理，因此在这种模式下不建议服务的层级太多，如果能用服务聚合模式代替，则优先使用服务聚合模式，而不是使用这种服务串联模式。

相对于服务聚合模式，服务串联模式有一个优点，即串联链路上再增加一个节点时，只要不是在串联服务的正后面增加，那么串联服务是无感知的。

在串联服务中调用链的最后端增加服务无感知的架构如下图所示。

在上面提及的电商案例中，UI前端应用调用交易，交易调用商品库存系统锁定库存和扣减库存，使用的就是服务串联模式。

服务串联模式案例 的架构如下图所示。

服务分支模式

服务分支模式是服务代理模式、服务聚合模式和服务串联模式相结合的产物。

分支服务可以拥有自己的数据库存储，调用多个后端的服务或者服务串联链，然后将结果进行组合处理再返回给客户端。分支服务也可以使用代理模式，简单地调用后端的某个服务或者服务链，然后将返回的数据直接返回给使用方。

服务分支模式的架构如下图所示。

在实际的业务平台建设中，由于业务的复杂性，抽象的微服务可能有多层的依赖关系，依赖关系并不会太简单，经常呈现树形的分支结构。

以电商平台的支付服务架构为例，如下图所示。

支付服务对接两个外部的支付网关，都要经过各自的支付渠道网管，同时支持账户余额支付，这个支付服务其实就是一个分支模式，在实际项目中这种服务分支模式很多。

由于分支模式放大了服务的依赖关系，因此在现实的微服务设计中尽量保持服务调用级别的简单，在使用服务组合和服务代理模式时，不要使用服务串联模式和服务分支模式，以保持服务依赖关系明了，这也减少了日后维护的工作量。

服务异步消息模式

前面的所有服务组合模式都使用同步的RESTful风格的同步调用来实现，同步调用模式在调用的过程中会阻塞线程，如果服务提供方迟迟没有返回，则服务消费方会一直阻塞，在严重情况下会撑满服务的线程池，出现雪崩效应。

因此，在构建微服务架构系统时，通常会梳理核心系统的最小化服务集合，这些核心的系统使用同步调用，而其他核心链路以外的服务可以使用异步消息队列进行异步化。

服务异步消息模式的架构如下所示。

在上图中，聚合服务同步调用服务1和服务2，而服务2通过消息队列将异步消息传递给服务3和服务4。

典型的案例就是在电商系统中，交易完成后向物流系统发起消息通知，通知物流系统发货，如下所示。

服务共享数据模式

服务共享数据模式其实是反模式，在去数据共享模式中，由于去掉了数据共享，所以仅仅通过服务之间良好定义的接口进行交互和通信，使得每个服务都是自治的，服务本身和服务的团队包含全角色栈的技术和运营人员，这些人都是专业的人做专业的事，使沟通在团队内部解决，因此可以使效率最大化。

服务共享数据模式的架构如下图所示。

然而在下面两种场景下，我们仍然需要数据共享模式。

单元化架构

一些平台由于对性能有较高的要求，所以采用微服务化将服务进行拆分，通过网络服务进行通信，尽管网络通信的宽带已经很宽，但是还会有性能方面的损耗，在这种场景下，可以让不同的微服务共享一些资源，例如：缓存、数据库等，甚至可以将缓存和数据在屋里拓扑上与微服务部署在一个物理机中，最大限度地减少网络通信带来的性能损耗，我们将这种方法称为“单元化架构”。

单元化架构的示意图如下所示。

遗留的整体服务

对于历史遗留的传统单体服务，我们在重构微服务的过程中，发现单体服务依赖的数据库表耦合在一起，对其拆分需要进行反规范化的处理，可能会造成数据一致性问题，在没有对齐完全理解和有把握的前提下，会选择保持现状，让不同的微服务暂时共享数据存储。

除了上面提到的两个场景，任何场景都不能使用服务数据共享模式。