第8章 微服务架构设计 【4、微服务的分解和组合模式有哪些】

8.4 微服务的分解和组合模式有哪些？

答：

微服务技术团队在转型过程中往往会经历三个阶段：技术架构、业务落地与云端运维。

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

在微服务设计中，有6种设计模式，分别是：聚合模式、代理模式、链路模式、分支模式、异步模式与数据共享模式。

（1）聚合模式

聚合模式是微服务设计中最常见的一种设计模式，它根据业务流程处理的需要，以一定的顺序调用依赖的多个微服务，对依赖的微服务返回的数据进行组合，加工和转换，最后以一定的形式返回给使用方。适用于大多数应用场景。

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

聚合模式充分体现了DRY（Don't Repeat Yourself）原则的设计理念，在设计或者构造应用时，最大限度的重用了现有的实现。

聚合模式由前端的一个聚合服务与其后面的一堆原子服务组成。聚合服务的任务主要有两个：展示用户界面与接收用户请求。

 

基于聚合模式设计的微服务架构如下图所示；整个系统被分为网关层、聚合层、原子服务层与数据层。

在实际项目中，可以将聚合服务设计成基于Node.js的HTTP服务，而将原子服务设计成基于Spring Cloud的应用服务。

聚合模式在拆分原子服务的同时，也需要根据职责拆分数据库。这一方面会带来可维护性、易变更性等诸多好处，但又会带来两个性能问题：跨库的关联查询与跨库的的事务处理。跨库的关联查询可通过数据补填来完成。跨库的事务处理也不再采用传统的两阶段提交或三阶段提交，可采用分布式事务的TCC方案，或者基于消息的最终一致方案，从而获得性能与吞吐量的大幅度提升。

聚合服务也可以是一个纯后台服务，通过聚合对使用方输出组合服务。

（2）代理模式

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

 

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

1）在新老系统上双写。

2）迁移双写之前的历史遗留数据。

3）将读请求切换到新系统。

4）下调双写逻辑，只写新系统。

服务代理模式常常应用到第3步，一般会对读请求切换设计一个开关，开关打开时查询新系统，开关关闭时查询老系统。迁移案例中开关的逻辑如下图所示。

 

（3）链路模式（串联模式）

链路模式就是将比较复杂的业务流程，拆分成多个微服务，串联起来执行。

它类似于一个工作流，上层的服务负责接收请求和响应使用方，接到请求和继续与下层服务交互，最后底层的结果向上逐级处理以后返回给使用方。

服务串联模式之间的调用通常使用同步的RESTful风格的远程调用实现，同步调用在串联服务没有完成并返回之前，所有服务都会阻塞和等待，一个请求会占用一个线程来处理，性能较差；由于执行过程的编排被分散到各个微服务中分别定义，因此如果日后要变更流程，需要同时修改多个微服务，维护成本高。因此在这种模式下不建议服务的层级太多。它是6种微服务设计模式中最少应用的一种模式。

 

（4）分支模式

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

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

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

 

（5）异步模式

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

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

 

（6）数据共享模式

微服务架构最理想的一种组织形式是，每个微服务都有自己的数据库，都只读写与访问自己的数据库，而对其他数据的读写则通过接口调用交给其他微服务去执行。这样的设计能够很好的体现微服务的“小而专”特点，降低微服务间的耦合，进行降低日后变更的维护成本。

所谓的“数据共享模式”，就是在微服务架构中，多个微服务访问同一个数据库。这样的做法，虽然改造过程会比较平稳，但又会带来另外一个反模式：数据共享反模式

对于留存系统进行微服务改造时，需要将原有的数据库按照功能模块进行拆分，即涉及海量历史数据的迁移问题，也涉及跨库的事务处理、跨库的关联查询等技术难题。因此，在微服务转型的初期不建议这样做。微服务转型初期的一个非常重要的反模式就是“太多数据迁移”。

服务共享数据模式其实是反模式。之前的去数据共享模式，由于去掉数据共享，所以服务之间通过定义的接口进行交互和通信。但在如下的特殊场景下仍然需要考虑数据共享模式：

1）单元化架构

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

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

2）遗留的整体服务

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

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