聊聊那些用Go写的分布式事务框架，第二弹来了，继续深入探讨它们的设计和挑战

上次我们聊了几个用Go语言写的分布式事务框架，像是DTM和Seata-Go，主要讲了它们是怎么保证事务要么全做、要么全不的原子性，今天咱们继续深入，看看这些框架在实现过程中，还遇到了哪些有意思的挑战，以及它们是怎么想办法解决的，内容主要参考了各个开源项目的官方文档、技术博客以及社区讨论。

第一个大挑战就是网络这东西太不可靠了，你想啊，一个分布式事务牵扯到好几个服务，这些服务可能分布在不同的机器上，甚至在不同的机房，它们之间全靠网络来通信，但网络可能会延迟，数据包可能会丢，更麻烦的是，一个请求发出去了，对方可能已经处理完了，但返回成功的消息却在半路丢了，这时候，发起事务的那个“事务管理器”就懵了：我到底是该认为它成功了呢,还是失败了呢？

为了解决这个难题，框架们普遍用了一个叫异步重试和状态可追溯的法子，简单说，就是会把事务进行中的每一个步骤、每一个状态（已开始”、“尝试中”、“确认中”、“已成功”、“已失败”）都老老实实地记录到一个可靠的存储里，比如数据库，这样，即使网络抽风，导致事务管理器不确定某个服务到底干没干成，它就可以时不时地去查一下这个服务的状态，或者干脆重新发一次指令，因为每个操作本身是幂等的（就是重复执行多次效果和执行一次一样），所以多试几次也没关系，直到最终确认状态为止，DTM的文档里就特别强调了这种基于持久化存储的状态机机制,来应对各种网络不确定性。

第二个挑战是性能和高并发下的压力，一提到事务，很多人会想到数据库事务，里面经常用“锁”来保证数据不会乱，但在分布式环境下，如果动不动就锁住一大片资源，那系统的并发能力就完蛋了，大家都得排队等着,速度肯定快不起来。

像TCC这类模式的框架，其设计思想本身就是一种避免长期锁资源的尝试，TCC把事务分成三个阶段：尝试、确认、取消，在“尝试”阶段，它只是先去检查一下资源够不够，预先冻结一部分（比如检查库存并冻结10件商品），但并不真正扣减，这个阶段可以上锁，但会很快释放，如果所有服务都“尝试”成功了，再进入快速的“确认”阶段，才真正完成操作；如果中间有失败，就进入“取消”阶段，释放之前冻结的资源，这样，真正锁住资源的时间非常短，大大提升了并发能力，Seata的AT模式也是类似，通过生成反向SQL日志并在第一阶段提交，从而释放锁,保证了效率。

第三个挑战是如何与现有的服务和技术栈和平共处，很多公司不是从零开始做微服务的，而是把一个大的单体应用慢慢拆出来的，这些服务可能用不同的语言编写，或者已经运行了很久，改造起来很麻烦，一个理想的分布式事务框架，最好能比较容易地让这些“老”服务也参与到分布式事务里来。

这方面，框架通常提供灵活的集成方式，除了提供原生的Go语言SDK让你方便地在服务中嵌入事务控制代码外，还会支持通过HTTP、gRPC等标准协议与异构服务进行通信，事务管理器通过发送标准的HTTP请求，就可以调用一个用Java或Python写的服务，并把它纳入到全局事务管理中，DTM就明确支持这种多语言接入的方式,降低了接入门槛。

还有一个容易被忽略但很重要的挑战：运维的复杂性和数据一致性之间的权衡，框架功能越强大，保证的一致性级别越高，往往意味着架构就越复杂，需要额外部署的组件（比如独立的事务协调器）就越多，这会给运维带来压力，比如要保证这个协调器本身的高可用，不然它一挂,所有事务都进行不下去了。

有些框架也提供了更轻量级或嵌入式的方案作为选项，不一定非要部署一个独立全局事务服务，也可以将事务协调的能力以库的形式集成在某个主导服务中，这在某些简单场景下能简化部署，但这就需要开发人员根据自己业务的真实需求，在“强一致性”和“系统简单性”之间做出明智的选择了，业界讨论中经常提到，不要为了用分布式事务而用，能避免尽量避免，如果业务上能通过最终一致性或补偿机制解决，往往系统会更简单 robust。

用Go构建分布式事务框架，不仅仅是代码实现，更是在网络不可靠、高性能要求、易集成性和运维成本这几个大坑之间不断地寻找平衡点，这些框架的演进,也反映了开发者们在这些挑战下的智慧和取舍。