响应式架构在系统集成过程中分布式事务处理实践

首先，我们来看一下什么是响应式编程。响应式编程简称RP，一种面向数据流和变化传播的编程范式。这意味着可以在编程语言中很方便地表达静态或动态的数据流，而相关的计算模型会自动将变化的值通过数据流进行传播（百科：https://baike.baidu.com/item/%E5%93%8D%E5%BA%94%E5%BC%8F%E7%BC%96%E7%A8%8B/15549849?fr=aladdin）。更通俗一点讲，响应式编程实际上是对Java编程中常见的观察者模式的扩展。

：刘备生病住院，有一日忽感不适，急忙触发了床头的呼叫系统，香香闻讯而来，及时进行了处理。用药及时，刘备化险为夷。

剧中人物：

被观察者：刘备。

观察者：香香。

分布式事务是在分布式系统、服务建设中，不得不面对的问题。分布式事务管理，常见的方案有如下几种：

方案一：两阶段事务

两阶段事务执行逻辑：

客户端提交请求到事务管理器（协调者），协调者会通知各参与方准备执行事务。各事务参与方接收到请求后，执行事务并记录日志，并将执行结果反馈给事务管理器。当事务管理器收到所有反馈后，结合反馈信息，再发送通知到事务参与方，决定提交还是回滚事务。

方案二： 三阶段事务

三阶段事务与两阶段事务流程类似，此处不在赘述。

方案三：Raft一致性保证

目前分布式系统中应用比较广泛的一种分布式事务处理算法。通常基于TLog实现。图中L表示leader， F表示flower。具体的流程可以参考：http://thesecretlivesofdata.com/raft/

方案4: 基于RESTFul API 的TCC事务

（图片来自网络）

TCC事务应用于基于RESTFul的分布式事务处理场景中。其中事务调节器的主要作用是确认、提交。当事务发起者发起事务时，先向事务调节器提交一个确认信息，同时向所有的事务参与者提交事务。事务参与者接收到事务请求后，向事务发起者询问事务确认信息，尝试执行事务。事务执行成功，则提交事务并且返回处理结果到事务协调者。事务协调者会依据具体的处理结果进行回滚或者提交操作确认，从而完成分布式事务的处理。

综合评估了各实现方案与技术，开发成本不考虑，特定场景下，上述方案依然不能满足实际需求：

A、B、C三个系统之间基于Rest API 共同完成业务需求D。事务由A发起。由于B系统的建设原因，B系统不具备确认、回滚等能力（TCC中的CC），B的流程之后还需要处理C事务。如果B成功，C失败，则B系统中存在脏数据。示意如下：

上述场景中，即使B系统支持回滚，那A系统在处理自身业务时，也会陷入事务的汪洋大海中，代码复杂度会随业务复杂度的提升而提升。

系统集成过程中，事务由A系统触发，但是A系统本身操作不属于事务范畴，并且A系统不支持重试。

通过充分调研和设计，我们团队提出了如下解决方案：基于响应式架构提供可重复播放的分布式事务解决方案，解决我们实际项目中的问题。具体方案如下：

整个方案我们抽象出来几个主要角色：

事件管理器：中控台的角色，负责转发事件

路由服务：子中控台角色，转发某一类事件

处理步骤：具体的某种事件

分布式处理步骤：事件处理器，处理特定业务

事务回放器：容错恢复机制，运维人员手动触发，从出错位置继续执行事务

事务的各参与方：事件处理器

事务的各个环节：事件

实现逻辑如下：

首先：所有的时间都要注册到系统自身的事件处理单元—路由服务，路由服务向事件管理器注册自身（这样做的目的避免事件处理器hanle太多时间导致响应过慢，因此增加路由服务）

其次：每个事件处理器（分布式事务处理步骤）都需要实现三个方法：

doAction：正常处理业务

doFailed：异常情况处理逻辑

nextEvent：后续处理流程

通过这样的组织，将整个事务处理链条按照事件链的方式串联。

最后：当发起事务的时候，应用程序只需要触发整个事务的第一个环节事件就可以了。整个事务管理器会按照用户的编排，完成整个事务流程的调度。

异常情况：当系统出现异常，导致某个流程中断时，系统会持久化特定事务到指定设备，并发送通知告知运维人员进行跟进。解决环境或者系统问题后，只需要回放事件，事件就可以从失败的地方继续执行，从而达到数据的最终一致。各组件之间调用关系如下：

其中：红线代表正常调用 绿线+蓝线表示错误处理机制。

基于此方案，我们有效的解决了在服务集成过程柔性事务的处理，从而确保多个系统调用过程中，事务的完整性和数据的一致性。同时，我们还得到了额外的收益：

借助响应式系统的异步特性，通过多重路由，提升了系统的吞吐量

对于业务RD来说，不再关注事务细节，业务处理逻辑更聚焦，程序复杂度降低

通知服务提示的异常信息，能够准确定位问题原因，降低了分布式系统、服务排查异常问题的成本

再次理解“纸上得来终觉浅，绝知此事要躬行”的深刻含义。

方案中自然也有很多不足之处，希望大家批评指正。

希望和大家一起交流，共同进步。

作者简介：

王雨学–多年软件开发从业经验的互联网老兵、BIPlatform开源项目负责人（https://github.com/baidu/BIPlatform）。专注分布式应用、BI系统架构设计与开发。

因为微信关闭了留言，欢迎关注我们的微信号进行交流：