分布式事务解决方案 dbpack 和 hptx 的演进

2019 年 1 月，阿里中间件部门开源了分布式事务框架 SEATA。笔者从 SEATA 开始开源就关注着 SEATA 社区的发展。同时，随着 Kubernetes、istio 等技术的流行，笔者开始转向 Golang 技术栈，逐渐萌生了开发一款 Go 语言的分布式事务框架的想法。2020 年 4 月，这一想法开始付诸行动，并在 github 开源了项目 seata-golang。经过约 2 个月的时间，seata-golang 发布了 v1 版本。但在开发过程中，也发现 SEATA 设计上的一些不合理之处。

一、存在的问题

1、非云原生设计

SEATA 的 client 严格区分了 TransactionManager ™ 和 ResourceManager (RM)，在和 TC Server 通信的时候，TM 和 RM 都会和 TC Server 建立连接。在 TM 与 TC Server 建立的连接上，只能发送全局事务的开启、提交、回滚等请求。在RM 与 TC Server 建立的连接上，只能发送事务分支注册、分支事务执行结果报告、全局锁查询等请求。TM 的的连接上不能发送 RM 的请求，RM 的连接上不能发送 TM 的请求。这就造成连接管理的逻辑非常复杂，在 TC Server 上的连接管理就要区分 TM 连接和 RM 连接。事务分支注册的请求，它的响应必须通过 RM 连接发往 client，如果通过 TM 的连接发送，则响应消息无法解析。

同时，一个应用的多个副本都会与 TC Server 建立连接，TC Server 的内部使用了