工程中实践的微服务设计模式

大家好，我是方圆。最近在读《微服务架构设计模式》，开始的时候我非常的好奇，因为在我印象中，设计模式是常说的那23种设计模式，而微服务的设计模式又是什么呢？这个问题也留给大家，在文末我会附上我对这个问题的理解。本次文章的内容主要是工作中对微服务设计模式的应用，希望能对大家有所启发。

事务发件箱模式

事务发件箱模式：将消息保存在数据库 “发件箱”表 作为事务的一部分

policy 为处理投保的微服务，以投保事务为例：

在这里插入图片描述
如上图所示，在投保过程中有4步操作（注意持久化结算任务（Task）A的操作），这个过程便是事务发件箱模式的体现，为什么说它是事务发件箱模式呢？

Task 表中持久化的消息任务最终会被发送到 MQ 中，所以它是发件箱
持久化 Task 记录的操作被包含在事务中，所以称它为事务发件箱

Task 记录中保存的消息体是通过另一个服务 service-job 轮询扫描初始化状态的任务，并将其发送到 MQ 的，发送成功后任务修改为完成状态，这种方式被称为事务性发件箱模式中的轮询发布数据模式。

这种设计模式有一个弊端：随着数据量不断增大，经常轮询数据库可能造成昂贵的开销。在我们的系统中采用了两种措施进行优化：

分库分表：以空间换时间，避免单表数据量过大造成的开销
将完成状态的任务进行“数据结转”的设计：任务先保存在 Task 表中，被执行完成后被归档到 TaskRecord 表中

此外还有一种更加高效但是开发稍复杂的方式：拖尾数据库日志模式。

拖尾数据库日志模式

在这里插入图片描述
数据库的每次更新都对应着一条数据库事务日志，通过事务日志挖掘器读取事务日志，并将每条与消息有关的记录发送给消息代理（开源框架可参考：Github: debezium，可以将MySQL的binlog读取到Kafka中），但是这种方法的弊端是需要在开发上做一些努力，因为需要监听数据库事务日志和调用数据库底层相关的API。

相信“邮递员”

工程实践中，还有一种没有采用事务发件箱模式来保证数据一致性的方法：在事务中先持久化完成状态的任务，随后直接将消息发送给消息队列，如果消息发送失败，捕获异常并将任务修改成初始化状态，随后依赖 service-job 服务进行补偿：即将初始化状态的任务发送给 MQ。我们还是以投保的过程为例，如下代码所示：

// 1. 持久化保单数据
savePolicy();
// 2. 持久化保单明细数据
savePolicyDetail();
// 3. RPC 调用投保接口
rpcPolicy();
// 4. 持久化完成状态的任务，任务中记录了要发送给MQ的消息体
int num = insertTask(TaskStatus.COMPLETE);
// 5. 如果插入成功了，借助线程池发送消息
if (num > 1) {threadPoolExecutor.execute(() -> {try {mq.send(task.info);} catch(Exception e) {// 发送失败，抛出异常，修改任务状态为初始化状态，依赖 service-job 服务进行补偿updateTask(TaskStatus.INIT);}});
}

这种设计模式默认认为MQ集群始终是高可用的，我将这种设计模式命名为相信“邮递员”。在生产实践中，因为有MQ运维团队在保障MQ集群的高可用，所以这种设计模式也是比较稳定的。

在投退保流程中，涉及不同数据库的修改操作，如保单的持久化、保单状态的修改以及相关结算的推送，要保证这个过程中的数据一致性，那么便不能再依赖ACID本地事务，而是需要使用跨服务的 Saga 设计模式来维护数据一致性。下面我们来介绍两种，分别是协同式Saga和编排式Saga。

Saga 通过使用异步消息来驱动一系列本地事务，来维护多个服务之间的数据一致性。

协同式Saga

我们先带着 Saga 的概念来看一下投保的流程：

在这里插入图片描述

在这个过程中，Saga的决策和执行顺序分布在Saga的每一个参与方中，并且通过消息交换的方式进行沟通，一个Saga的参与方执行完触发另一个Saga执行，保证数据一致性，这种方式被称为协同式Saga。

这种设计模式的优劣如下：

优势：比较简单，服务间松耦合
弊端：比较难理解，因为它没有一个地方定义了Saga的执行流程，Saga的处理逻辑分布在不同的服务中，需要根据代码触发的任务去整理整个流程

为什么没有采用XA来实现分布式事务？

XA采用两阶段提交协议实现分布式事务，在事务中的所有参与者都成功时提交，有失败时便回滚。要使用该模式一方面要求所有的事务参与者（数据库或消息代理）满足XA标准，另一方面，它本质上是同步的进程间通讯，同步的通讯机制有一个弊端：它会降低分布式系统的可用性（假如分布式系统中每个服务的可用性为99%，如果服务与服务之间是同步调用的方式：服务必须从另外一个服务获取响应后才能返回它的客户端调用，那么分布式系统的可用性为各个服务可用性的乘积，随着同步交互服务的增加，可用性会随之降低，最大化可用性的方式应该最小化系统间的同步操作量）。所以，一般互联网公司很少采用强一致性的设计，而是采用最终一致性设计（银行可能会使用到强一致性）。此外，XA实现分布式事务需要依赖事务的协调者（如Seata），实现起来相比于上述方式复杂。