微服务架构技巧篇:分布式事务
李运华

你好,我是华仔。
上一节我们讲解了微服务架构设计中“服务分布式”带来的技术挑战,以及各种应对技巧。这一节,我们将继续讲解如何应对微服务架构另一个特点“数据分布式”带来的技术挑战。
“数据分布式”带来的技术挑战,本质上都可以归因于原来可以在单个关系数据库上完成的复杂操作,因为微服务拆分后就没法用了。
行业技术老兵应该都见过“存储过程”这种典型的面向数据库的开发模式。我曾见过长达几百上千行的存储过程,无论是看代码、调试、定位,还是修改、重用、移植等,对技术人员来说都是地狱级的难度。即便有的企业给出了存储过程使用的各种规范和限制,但只要没有严格的审核和监督,开发人员就会逐步滥用存储过程。很多时候,单次开发用存储过程确实很方便和快速,某些场景下性能也更高,因为不需要从数据库读取数据到应用程序中,处理后又将数据写入数据库。
当单体或者 SOA 系统拆分成微服务架构后,单个微服务职责简化,管理的数据范围缩小,微服务之间只能通过接口访问,可以说从根源上改变了复杂存储过程生存的土壤,而简单的存储过程相比代码来说没有什么优势,所以微服务中使用存储过程其实没有必要。
微服务架构虽然不需要“存储过程”这种开发模式了,但这也带来了一个新的技术挑战:多个微服务如何保证数据一致性。接下来,我们按照不同的拆分模式简单分析一下。
公开
同步至部落
取消
完成
0/2000
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结

1. 微服务架构中的数据分布式带来了技术挑战,需要解决复杂操作无法直接应用于微服务架构的问题。 2. 存储过程在微服务架构中失去了优势,因此在微服务中使用存储过程并不必要。 3. 多个微服务如何保证数据一致性是微服务架构中的一个新技术挑战,需要应对分布式事务和全局幂等的问题。 4. 业务级分布式事务是在分布式系统中为了保证数据一致性而执行的一系列操作,可以基于接口调用或消息队列实现。 5. 本地事务消息是一种业务级分布式事务模式,通过记录事务相关的消息来推动分布式事务的协作和执行。 6. MQ事务消息是在普通消息基础上支持二阶段提交能力,将二阶段提交和本地事务绑定,实现全局提交结果的一致性。 7. TCC是应用层面符合2PC协议的分布式事务解决方案,包括Try、Confirm和Cancel三个操作,需要业务系统实现并对外提供接口。 8. 分布式事务的处理流程和异常处理逻辑需要仔细考虑,以确保数据一致性和系统稳定性。 9. 分布式事务解决方案需要根据具体业务场景和系统架构选择合适的模式,并在实践中不断优化和调整。 10. 分布式事务的实现需要考虑故障恢复、人工订正以及异常处理分支等方面,以确保系统的可靠性和稳定性。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》,新⼈⾸单¥68
《从 0 开始学架构》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论