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

Posted 商业运营技术栈

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了响应式架构在系统集成过程中分布式事务处理实践相关的知识,希望对你有一定的参考价值。

首先,我们来看一下什么是响应式编程。响应式编程简称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:后续处理流程

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

 

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

 

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

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

 

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

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

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

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

 

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

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

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




作者简介:

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



 

 


以上是关于响应式架构在系统集成过程中分布式事务处理实践的主要内容,如果未能解决你的问题,请参考以下文章

分布式技术专题「架构实践于案例分析」总结和盘点目前常用分布式事务特别及问题分析(中)

分布式事务架构实践

阿里分布式事务多场景多维度架构的全攻略实践

互联网高并发架构技术实践

深入分布式事务之多场景架构设计全攻略实践篇(建议收藏)

不懂分布式事务实践,我被同事diss了