本文将对Seata和EasyTransaction两种分布式事务的一些高层设计进行对比，相信大家一定有所收获。Seata简介Seata（原名Fescar，开源版GTS）是阿里开源的分布式事务框架。其RoadMap指出，希望与社区合作重建一个全面的分布式事务框架。关于Seata的相关介绍可以看这里，本文不再赘述。虽然其后续路线有所调整，但普遍适用。https://github.com/seata/seat...学习了Seata之后，我们可以对比一下EasyTransaction的架构设计。EasyTransaction概述EasyTransaction（以下简称ET）的目标也是构建一个完善的分布式事务解决方案。目前为止，包括TCC、自动补偿（SeataAT）、手动补偿、可靠交易消息、Saga交易等多种形式。下面将分析这两个框架的设计差异。核心区别图借用了Seata的一张图：与Seata不同，EasyTransaction对应的图片如下：TC区别Seata：中心化的TCRM，独立部署的TM和TC通过RPC进行交互。在TC中可以看到各个具体的事务分支，并协调所有事务分支的提交和回滚。EasyTransaction：TC是业务服务流程中的一个模块，不是独立的，有子事务的服务实例会调用TC模块，比如ServiceA、B、C都有TC，但是ServiceD、E没有TC.这里是否存在是指在本次交易中是否触发了TC功能。TC、TM、RM的交互是在这个过程中进行的。每个TC只能协调其直接子交易。比如ServiceA的TC只知道ServiceB和ServiceE的子事务，但是ServiceB知道还有ServiceC的子事务，所以可以递归协调各个服务实例发起的全局事务。服务实例本身会先Try自协调一次（大部分都能成功）。如果自协调失败，由一个服务实例来处理事务协调Seata有一个中心化的TC，可以更方便的实现分布式事务的监管和控制，比如关于APM、Metrics、统一限流等功能。但是，EasyTransaction中的TC表单可以节省TC网络交互时间。在上述Seata业务图中，ET表单在两阶段提交的第一阶段可以节省6倍的网络往返时间和正反序列化时间。[(registerBranchandreportBranch)*ncalllevels]在两阶段提交的第二阶段，在统一提交或回滚过程中，Seata的形式比EasyTransaction更快，因为它不需要向下传递。根据调用级别N的不同，ET形式的第二阶段在网络往返和正反向序列化的时间上会比Seata慢n-1。[(commitorrollback)*(n-1)calllevels]（注：如果考虑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（Springnativetransactions），但是PTMwithsub-transactions会挂载扩展分布式事务相关的处理，启动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有一个masterRM（initiatorRM，发起交易），和交易RM的区别。Seata全局事务中的RM都是平等的，整体逻辑有简洁统一之美，但因此其所有RM必须能够接受两级控制。但是在正常的业务模型中，全局事务starter（Seata中有TM的那个）基本可以知道全局事务应该在一个stage内回滚或者提交。需要使用AT方式（记录回滚数据），或者写TCC的commit回滚方法。还有一些额外的性能损失。在ET模式下，有一个事务发起者RM设置。全局事务被（最终）提交，如果发起者未能提交，则全局事务（最终）被回滚。因此，事务发起者不需要兼容两阶段提交协议，节省了相关的性能开销。当然，ET的交易发起方RM也可以不写任何业务。在这种情况下，它与Seata的模型相同。自动补偿实现差异Seata：通过TC保存全局锁并实现EasyTransaction：通过本地业务数据库保存全局锁Seata通过TC保存全局记录Locks引入了更多的复杂性，但是可以自由控制锁的实现，可以实现对于场景更高效的锁。EasyTransaction改造Seata的自动补偿功能，将原来的远程TC依赖改造为EasyTransaction的分布式TC，将全局锁实现改造为业务DB。自动补偿的整体实现复杂度降低，但性能可能会降低（未测试）。不过，与Seata相关的实现也在进行中。RPC接口Seata处于早期阶段。Seata尽量保持核心功能简单，不涉及任何业务级RPC内容。集成Ant的TCC后，框架的核心代码开始出现。原接口接口输入输出参数比较自由。EasyTransactionRPC是EasyTransaction的一部分，可以更改和替换。直接暴露给用户的不是RPC框架，而是ET的相关接口。RPC只是作为输入输出参数的底层通信支持接口。形式有限。EasyTransaction之所以使用自己的接口来替代原来的RPC接口，其中一个原因是可以更方便地控制整个交易过程。它直接和业务交互，知道这个调用的结果。需要立即返回或者可以稍后返回，知道这个调用是重试还是业务主动触发，可以通过sdk主动设置RPC框架不重试，主动设置让它成为粘性会话提高效率而不用要求用户单独使用同时，由于RPC是ET的一部分，幂等、取消挂起等繁琐重复的问题可以更容易地由框架自动支持（已经实现），但如果Seata坚持当前的轻量级方法，它将在未来实现。功能可能更难。当然，将ET接口暴露给业务也可以看作是耦合的增强。动态配置、服务发现、APM等。Seata通过主动配置连接EasyTransaction，使用Spring等现有设施连接ET，使用Spring现有的配置接口进行配置。因此，只要将相关配置中心接入Spring，即可使用EasyTransaction。但是为了减少Seata对Spring的依赖，需要单独进行相关的对接。ET的TC是集成到业务服务中的，所以TC相关的服务发现只需要利用业务本身的服务发现就可以完成。Seata的TC是单独部署的，所以需要做一些适配工作。与上述原因类似，EasyTransaction的APM等操作只需要借用已经集成到RPC框架中的APM，而Seata需要做一定的适配工作。总结海塔在短短几个月的时间里，可以积累近万颗星辰。除了号召力之外，当然还有一个原因就是分布式事务这个领域如此普遍和重要，但是却缺少一个让小白放心使用权限的实现。毫无疑问，有如此热情的社区支持，Seata是很有希望的。成为这样的认识。不过在Seata真正成为这个权威实现之前，我想大家也可以抽空了解一下EasyTransaction，目前功能更强大，代码更稳定，已经在生产中实现了~当然以上很多内容都有个人主观有偏见，希望大家能补充各种意见，听听吧！如果这篇文章对你有帮助，别忘了连打3个，点赞、转发、评论，我们下期再见！获取方式：点赞、评论、关闭~学习更多JAVA知识技能，关注并私信博主(666)
