辞旧迎新，22年要结束了，明年做什么想好了嘛？要不要用 Seata 搞定公司分布式事务管理的规范化建设？

欢迎关注微信公众号「架构染色」交流和学习

一、背景

在上一篇《明年用Seata搞定分布式事务管理的规范化建设 | 上篇》 中介绍了微服务架构演进，必然带来数据不一致的问题，在一些特性场景下数据的一致性要求会很高，而大多数情况下对一致性的要求又不高，这些差异也导致了对分布式事务解决方案呈现两种相对的顾念，一种认为可以置之不理，一种则认为必须解决，在没有标准方案的情况下，很容易出现各显神通，做出的东西即不通用也不健壮。

这两种情况从标准架构规范的大局来看都非合理状态，实际上从公司技术架构管理的角度看，需要的是一套规范的、通用的、可靠的分布式事务解决方案，能够帮助开发者在分布式的环境下，既能保证业务数据的一致性，又不需要投入太多的资源用于业务数据一致性的开发维护，还能加快迭代速度保障项目交付。

Seata 所兼备的 TC 高可用、 TCC 模式和 AT 模式特别符合一套规范的、通用的、可靠的分布式事务解决方案的诉求，能将分布式事务问题从业务中尽量剥离出来（AT模式剥离的比较彻底），作为一个独立的技术切面由专人管理运维（独立的服务端和模块化的客户端），提供简单、易用、高效、稳定的分布式事务解决方案，体现出以下价值：

1. 架构复杂度降低：分布式事务这个切面的技术问题，全部由 Seata 所提供的服务能力来解决。
2. 设计和开发成本减轻，加快交付和迭代速度：业务逻辑的设计和开发中，若采用 AT 模式，则无需考虑是否涉及分布式事务，是否需要做额外的准备，专注 SQL 编写实现业务逻辑即可，对业务 0 侵入  。
3. 运营成本降低，保证业务数据准确度，以及出错时的自动回滚和及时通知

本篇我们探讨一下项目的推进思路，以及AT模式的原理

二、如何推进

之前好朋友在聚餐时提到说自己在尝试来落地分布式事务，但自己也遇到一些问难，之后我们经常沟通，也探索出了一些可行方案，整理出来给大家做个参考。

当下的大环境并不好，公司调整为业务导向的方针，因此基础技术领域的部门需重新审视自己的角色、调整自己职责，不能以技术至上的心态一味追求高精尖，而他作为一向偏爱技术的个体也需调整思路，全力转向为开发者服务。在老板业务导向的方针下，新技术的引入、推进就不能再纯粹以技术视角考量，要结合业务，评估是否有痛点，是否有需求，需求是否强烈。

PMO 与多个业务部门组织需求和使用场景的沟通后，他们得到了比较一致的反馈，较多同事有听到过 Seata 在其他公司的实践分享，但此技术的可用性、稳定性方面在本公司尚无案例借鉴，无法给与充足的信任，即使有需求也不敢贸然明确提出使用 Seata 就能解决问题；基础设施需要先行，给出兼容性、性能、稳定性等方面的一些可靠结论。新能力需要业务方提需求，业务方要基础设施先提供能力保障，这个“死锁现象”按照工程化的思路重新梳理，跟 PMO 商定徐图缓进的应对之策：

1. 加强对 Seata 技术层的掌控力，针对公司的技术栈和数据库中间件进行全面的功能性验证，明确其可靠能力的合集；在此过程中梳理原理、解决问题并将验证结论等进行整理
2. 通过每周宣导的方式，进行同步、培训和引导，互动的过程中，搜集需求和意向用户以及其需求场景
3. 理清 Seata 的安全保障机制，以最小测试单元的原则来保障试点应用的接入和验证。

TCC 模式对代码的侵入性较高，需要做大量的改造，这对当下 Seata 的推进并不友好，而 AT 模式能适配的应用场景很多，只需要少量代码的微调即可，并且通过 AT 模式即也能证验证大部分 Seata 的能力。基于以上考虑，他们将尝试的方向先聚焦到 AT 模式上，有了 AT 模式的积累沉淀后，TCC 模式的应用将会水到渠成。

三、介绍 AT 模式业务无侵入的的原理

1）一阶段：

在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其读出保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其读出保存成“after image”，最后生成事务锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

2）二阶段提交：

二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段的事务锁释放，完成对应”before | after image“数据的清理即可。

3）二阶段回滚：

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。

四、总结与预告

本篇介绍了好朋友公司在业务导向的主旨下，推进 Seata 时所遇到的一些困难，以及应对策略，给读者朋友做个参考借鉴。之后介绍了 AT 模式业务无侵入的的原理，从而让读者朋友能直观的感受到此模式能适配的应用场景很多，只需要少量代码的微调即可，读者朋友可将尝试的方向先聚焦到 AT 模式上，有了 AT 模式的积累沉淀后，TCC 模式的落地将会水到渠成。

等好朋友结合自家公司的技术栈，做完兼容性测试，以及将遇到的问题解决后，再将有价值的信息同步给大家，帮助大家少踩坑。每家的技术栈情况会有微小差异，兼容性测试真的很重要，没问题就很开心，有问题就不能带病上线。

五、最后说一句

我是石页兄，如果这篇文章对您有帮助，或者有所启发的话，欢迎关注笔者的微信公众号【 架构染色 】进行交流和学习。您的支持是我坚持写作最大的动力。