在开发或软件架构的过程中,经常会遇到数据一致性的问题。尤其是在微服务架构下,每个微服务都有自己的数据库,导致微服务架构的系统不能简单地满足 ACID,我们就需要寻找微服务架构下的数据一致性解决方案。
传统情况下,当一个事务要跨越多个分布式服务时,开发者想到的第一个方案就是两阶段提交——2PC。在这个过程中,事务协调者(事务管理器)给每个参与者(资源管理器)发送 Prepare 消息,如果参与者有可用资源,对数据加锁,如果所有参与者都返回成功,就执行第二阶段,否则,执行回滚操作。
由于数据库通常比业务服务更难扩容,而两阶段提交需要依赖于数据库实现,并且对数据加锁,所以性能较低,应用并不是十分广泛。
那么,如何保证微服务架构中的数据一致性?华为云 PaaS 团队架构师王启军老师提到了几个方面:
1. 可靠事件通知模式
该模式下,一种通知模式是同步事件,即主服务完成后将结果通过事件(以消息队列为主)传递给服务,进而完成业务流程,达到主服务与服务间的消息一致性。另一种是异步事件,即业务服务和事件服务解耦,需要将提交失败的事件进行重试,目前业界多数采用本地消息表 +MQ 的方式来进行重试,但也因此对数据库产生压力。
2. 使用 Saga 保证微服务的最终一致性
Saga 将一个跨服务的事务拆分成多个事务,每个子事务都需要定义一个对应的补偿操作。通过异步的模式来完成整个 Saga 流程。具体操作是将项目创建流程拆分成多个 Saga,并为 Saga 分配一个事务管理器。当服务启动时,会将服务中所有的 SagaTask 注册到管理器中。在业务执行时,执行状态可以通过事务管理器进行查看。
3. TCC/Try Confirm Cancel 模式
在 TCC 模式下,当一个服务提交失败时,可以做到完全补偿,且在补偿后不留下补偿记录。这样可以在业务层处理时,平衡数据库的压力。但其代价也在于增加了业务的复杂度,需要提供相应的 Try、Confirm、Cancel 接口等。
4. 华为云分布式事务服务—DTM
DTM 是华为云分布式事务管理中间件,它的具体步骤是,先由实物发起者向 DTM 集群申请注册一个全局事务的 ID,并透传到所调用的事务参与者中,事务参与者利用得到的 ID 向 DTM 集群注册申请一个分事务 ID,在事务参与者完成自身业务逻辑后,将结果上传至 DTM 集群,并示意分支事务结束,在后续完成 TCC 二阶段后,DTM 集群通稿事务发起者全局事务结束。具体流程如下图所示:
最后,王启军老师总结:不是所有的地方对一致性要求都这么高,要根据自己的业务需求来选择一致性的模型。一致性没有绝对的,更严格的一致性只是降低概率而已,更高的一致性需要更高的成本,需要企业综合考虑。
除了一致性话题之外,王老师将在 12 月 7 日北京 ArchSummit 全球架构师峰会上分享《反应式微服务框架 Apache ServiceComb 设计思想》的话题,介绍 Reactive 编程模型带来的好处,以及在微服务架构下,如何快速建立 Reactive 架构。
感兴趣可以点击 https://archsummit.infoq.cn/2019/beijing/track 查看官网了解更多议题内容。9 折倒计时 20 天,团购更优惠哦~详情联系票务经理灰灰:15600537884(同微信)
评论