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

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

事务发件箱模式

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

policy 为处理投保的微服务,以投保事务为例:

如上图所示,在投保过程中有4步操作(注意持久化结算任务(Task)A的操作),这个过程便是事务发件箱模式的体现,为什么说它是事务发件箱模式呢?

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

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

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

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

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

拖尾数据库日志模式

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

相信"邮递员"

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

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

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


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

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

协同式Saga

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

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

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

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

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

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

编排式Saga

Saga 的另一种实现方式是编排式,编排式 Saga 需要事务的协调者(DTM),全局事务发起人将整个全局事务的编排信息,包括每个步骤的正向操作和反向补偿操作定义好之后,提交给事务协调者(DTM),协调者按步骤异步执行Saga逻辑。

如果投保流程使用编排式Saga的话,投保成功的过程如下:

编排式Saga的事务定义执行步骤非常灵活,假如我们要在投保失败的情况下做取消结算的补偿逻辑的话,可以自行定义,图示如下:

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

优势 :能够集中流程控制、易于扩展和服务间松耦合,如果服务之间的依赖关系复杂,且业务流程经常变动,使用编排式Saga是合适的 弊端 :引入协调者增加了开发复杂性(扩展学习:DTM开源项目文档


现在我们回到文章开篇的问题:微服务架构设计模式与我们常说的设计模式的区别是什么?

我们常说的设计模式是面向对象的设计模式,它的解决方案元素是类,而微服务设计模式是站在更高维度即系统架构层面的设计模式,它面向的对象是系统中各个服务,解决方案也由相互协作的服务构成的。


巨人的肩膀

  • 《微服务架构设计模式》:第 1 - 4 章
相关推荐
javaDocker18 分钟前
业务架构、数据架构、应用架构和技术架构
架构
新知图书22 分钟前
Rust编程与项目实战-模块std::thread(之一)
开发语言·后端·rust
盛夏绽放44 分钟前
Node.js 和 Socket.IO 实现实时通信
前端·后端·websocket·node.js
Ares-Wang1 小时前
Asp.net Core Hosted Service(托管服务) Timer (定时任务)
后端·asp.net
JosieBook2 小时前
【架构】主流企业架构Zachman、ToGAF、FEA、DoDAF介绍
架构
Rverdoser2 小时前
RabbitMQ的基本概念和入门
开发语言·后端·ruby
Tech Synapse3 小时前
Java根据前端返回的字段名进行查询数据的方法
java·开发语言·后端
.生产的驴3 小时前
SpringCloud OpenFeign用户转发在请求头中添加用户信息 微服务内部调用
spring boot·后端·spring·spring cloud·微服务·架构
微信-since811923 小时前
[ruby on rails] 安装docker
后端·docker·ruby on rails