分布式事务框架Seata及EasyTransaction架构的比对思考

本文将会对比Seata与EasyTransaction两个分布式事务的一些高层设计，相信你们会有收获。

Seata的概述

Seata（曾用名Fescar,开源版本GTS）是阿里的开源分布式事务框架，其RoadMap中指出了其但愿与社区合做从新构建出一个全面的分布式事务框架。

关于Seata的相关介绍能够看这里，本文再也不赘述。虽然其后续路线有所调整，但总体适用。

https://github.com/seata/seata/wiki/%E6%A6%82%E8%A7%88

学习了解Seata后咱们能够比对着了解EasyTransaction的架构设计。

EasyTransaction概述

EasyTransaction（后简称ET）的目标也是构建出一个全面分布式事务解决方案，到目前为止其包含TCC,自动补偿（Seata AT），手动补偿，可靠事务消息、Saga事务等等多种形态。

下面将就两个框架在设计上的差别进行分析

核心差别图示

借用Seata的一张图：

与Seata不一样，EasyTransaction对应的图以下：

TC差别

Seata:

• 有独立部署的集中式TC
  • RM、TM与TC的交互经过RPC进行
• TC中能够看到每一个具体的事务分支，统一协调全部事务分支的提交及回滚

EasyTransaction:

• TC是业务服务进程中的一个模块，并无独立出来，且存在子事务的服务实例都会调用起TC模块
  • 如ServiceA，B,C都有TC，但ServiceD，E没有
  • 这里的有无指代的是这一次事务里TC的功能有没有被触发
  • TC与TM,RM的交互在进程内进行
• 每一个TC只能协调其直接子事务
  • 如ServiceA的TC只知道ServiceB及ServiceE的子事务
  • 但ServiceB知道还有ServiceC的子事务，所以能够递归协调
  • 每一个服务实例发起的全局事务，服务实例自身会先尝试一次自协调（大多数都能成功），若自协调失败，则由一个服务实例兜底处理事务协调

Seata有集中式的TC，这样其能够 更容易 实现对分布式事务的监管控,如关于APM、Metrics、统一限流 等等功能。

但在EasyTransaction中的TC形式能够节约TC网络交互时间，在上述Seata的业务图中，ET的形式在两阶段提交中的第一阶段能节约6次 网络来回时间 及 正反序列化时间。

[（registerBranch以及reportBranch）* n个调用层级]

在两阶段提交的第二阶段中，统一提交或者回滚过程当中，Seata的形式则是比EasyTransaction快，由于其不须要层级传递下去。视调用层级N的区别，ET形态的第二阶段会比Seata慢 n-1 个网络来回及正反序列化的的时间。

[ (commit或者rollback) * (n-1)个调用层级]   
(注：若考虑commit/rollback的次序的话，实际上 seata要按照 业务发生顺序依次提交 或者 逆序回滚，其也为串行，这也为其默认作法，因此实际上ET在这个阶段也会比Seata快一个 网络来回及正反序列化的的时间)

至于 因为数据分散性等等缘由APM、Metrics、统一限流 等等功能在ET形式如何实现 的这个问题，咱们能够参考普通的RPC是怎么作的，将其归入统一的RPC管理便可，只是统一管控的力度没有集中式的强大。

同时分散型的TC能 更容易 达到更高级别的可用性，其无需保证TC是否存活，业务服务在则TC在。分散的特征也让压力能在正常业务状况下，能均匀分散到不一样的业务实例当中。

TM差别

Seata:

• 独立于Spring/JTA的TransactionManager单首创建了另一套TransactionManager
• TransactionManager在一个全局事务里只有一个

EasyTransaction:

• 扩展Spring的PlatformTransactionManager（后称PTM）的功能，使其能够管控分布式事务
• 在每一个事务分支里都有PTM（Spring原生的事务），但存在子事务的PTM将会挂载扩展分布式事务相关处理以及启动TC模块功能

Seata单独抽象了一套TM，其好处是自由可控，并能够不依赖于任何框架。

ET其TM依赖于Spring的PTM的话，Spring这个框架就变成了使用ET的必选项。但相对的好处就是，全部做用于这个PTM的设施均可以做用于EasyTransaction。

例如Spring的RollbackFor，Transactional，Suspend注解，XML事务切面配置等等均可以直接为EasyTransaction所用。由于ET仅仅只是扩展，所以这些功能都能兼容。甚至于咱们要引入JTA，EasyTransaction也能兼容，由于PTM自身就有JTA的实现。

RM差别

Seata:

• 全部参与到全局事务的RM都是平等的存在

EasyTransaction

• 存在主控RM（发起方RM、发起方事务）,从事务RM的区别

Seata全局事务里的RM都是平等的存在，总体逻辑上有简单统一的美，但所以其全部的RM都必须能接受两阶段的管控。

但在常规的业务模式中，全局事务开始者（Seata里带TM的那个）的事务，基本均可以在一阶段内获知全局事务应该回滚或者提交，但因为Seata RM都平等的模式，发起方RM必要要用AT模式（记录回滚数据），或者编写TCC的提交回滚方法，这里有一些额外的性能损耗

ET模式里存在事务发起方RM的设定，其只要事务发起方的事务提交成功则全局事务（最终）提交，发起方事务提交失败则全局事务（最终）回滚，所以其事务发起方无需兼容两阶段提交的协议，节约了相关的性能成本。固然，ET的事务发起方RM也能够不写入任何业务，这样的话，就跟Seata的模式同样了。

自动补偿实现差别

Seata:

• 全局锁经过TC保存并实现

EasyTransaction:

• 全局锁经过本地业务数据库保存

Seata经过TC保存全局记录锁引入了更多的复杂度，但其能自由控制锁的实现，能针对场景实现出效率更高的锁。

EasyTransction改造Seata的自动补偿功能，将原有的远程TC依赖改形成了EasyTransaction的分布式TC，并将全局锁实现改造到业务DB中。自动补偿的总体实现复杂度下降了，但性能可能有所降低（未经测试）。

不过Seata相关的实现也在进行中

RPC接口

Seata

• 初期Seata试图维持其核心功能简洁，不涉及任何业务层次RPC的内容
  • 后面整合蚂蚁的TCC后框架核心代码开始出现RPC相关内容
• 暴露给用户的是RPC框架原生的接口
• 接口入参出参形式较为自由

EasyTransaction

• RPC是EasyTransaction的一部分，其可更改替换
• 直接暴露给用户使用的并不是RPC框架，而是ET的相关接口，RPC仅做为底层通信的支持
• 接口入参出参形式有限制

EasyTransaction没有采用常规的作法，而是用本身的接口替代原RPC接口的一个缘由是这样作能对整个事务过程能 更容易 地把控，其直接与业务交互，知道这一次调用的结果须要立刻返回仍是能够稍后返回，知道这一次调用是重试仍是业务主动触发的，能够经过sdk主动设置RPC框架不进行重试，主动设置使其进行黏性会话以提升效率而不用用户额外单独配置

同时由于RPC是ET的一部分，所以幂等、cancel悬挂等等繁琐重复的问题，能更容易地经过框架自动支持（已经实现），但若是Seata坚持目前轻量级作法的话，未来在实现相关功能时可能会更困难。

固然对业务暴露了ET的接口也算是一种耦合的加强。

动态配置、服务发现、APM等

Seata

• 经过主动配置对接

EasyTransaction

• 利用Spring等现有设施对接

ET利用Spring现有的配置接口进行配置，所以只要相关配置中心对接了Spring，EasyTransaction就能使用。但Seata为了减小对Spring的依赖，所以相关对接须要单独进行。

ET的TC整合到业务服务中，所以TC相关的服务发现只要利用业务自身的服务发现就能完成。而Seata的TC单独部署，所以须要必定的适配工做。

跟上面的缘由相似，EasyTransaction的APM等操做只需借用已经整合到RPC框架的APM便可，而Seata须要必定的适配工做

总结

Seata在短短几个月内能积累近万Star除了阿里的技术号召力外，固然还有另一个缘由是分布式事务领域如此广泛且重要，但缺乏一个能让小白都能放心无脑使用权威的实现，无疑Seata在如此热烈的社区支持下颇有但愿能成为这么一个实现。

但在Seata真正成为这个权威实现前，我以为你们也能够抽空了解下EasyTransaction这个目前功能更为强大、代码更为稳定、已上过生产的实现~

固然以上内容不少都带我的主观偏见，但愿各位能补充各类见解，兼听则明！

做者我的公众号

多年金融行业经验，现为某Top2互联网（民营）银行高级搬砖工，曾在两家TOP3股份制商业银行及一家互金创业公司工做（架构、核心业务主程），EasyTransaction做者，欢迎关注我的公众号，在这里我会分享平常工做、生活中对于架构、编码和业务的思考。

公众号

做者微信，添加微信请附上 暗号 ET