怎么在实战中落地分布式事务？Springcloud + RocketMQ 带你入坑

开篇思考

1. 为什么要分布式事务？
2. 分布式事务有哪些实现方式？哪种可靠？
3. 分布式哪些环节会出问题？出了问题怎么应对？

站在巨人的肩膀观察和思考

随着互联网时代的高速发展，分布式成了大型系统的标配，这是时代发展的选择。大型分布式系统不是每个公司和开发人员都能够涉及的领域，因为大型系统后面都 隐藏着众多代名词：复杂，昂贵，高科技，人才云集，大战略。。。

大部分领头互联网公司甚至依托自己的分布式经验逐步建立自己的体系，并使用这套体系搭建自己的平台对内，甚至对外提供服务， 就像现在众多的云平台提供的服务，甚至有些大战略提出促进发展：大中台小前台、大炮台支援单兵作战等等。

这里提到了中台的概念，这个概念很广，都是以用户为中心的，分布式只是其中的一小部分运用，之所以强行和分布式挂钩，是想说明现在的发展趋势变了， 我们的眼界是有限的，但是完全可以站在巨人的肩膀上，利用他们的高度来提升自己的眼界，来思考，我们到底应该怎么做，怎么做适合 我们自身发展。

我认为思考能力永远是一个程序员魅力所在，善于发现和思考，能够不断的帮助我们提升。

微服务架构的优势和问题

优势：

• 扩展性强：可根据业务需要增加服务，不影响现有的服务架构
• 单一隔离：服务和服务之前通过远程调用，单个服务只提供单一职责的功能，开发人员可以一人一服务进行开发，互不影响
• 高可用：服务可以集群部署，单个应用失败通过重试和熔断等措施可以提高稳定性
• 技术选型灵活：可以根据团队特点、业务需求选择合适的技术栈，提高开发效率
• 突破性能瓶颈：可以集群方式部署，解决单体访问峰值等处理能力的性能瓶颈
• 降低运维成本：应对不同的场景，例如双十一，可以动态增减服务集群数量，做到按需付费，减少开支

问题：

• 复杂度高：整体架构设计十分复杂，需要考虑到整体性、经济性、稳定性
• 容易混肴服务界限：哪些服务需要划分微服务，哪些可以作为子模块，需要认真思考
• 难以确保一致性：因为是链路调用，一个请求会经过多个服务，难以确保执行结果达到一致性

CAP & BASE

因为写过这两个理论的具体介绍，这里简单再说明下。还有疑问的可以看介绍 链接

这两是分布式架构发展至今形成的理论基础，只要分布式都绕不开的原则。CAP 教会我们如何在设计的时候取舍，是要高可用，还是强一致性？ 这个看业务的具体情况和需求分析，如果是关于资金的流转的
例如：银行转账系统，肯定会要求保证