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

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

答：

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

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

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

（1）聚合模式

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

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

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

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

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

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

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

聚合服务也可以