本文将会比照Seata与EasyTransaction两个分布式事务的一些高层设计，置信大家会有播种。
Seata的概述
Seata（曾用名Fescar,开源版本GTS）是阿里的开源分布式事务框架，其RoadMap中指出了其心愿与社区单干从新构建出一个全面的分布式事务框架。
对于Seata的相干介绍能够看这里，本文不再赘述。尽管其后续路线有所调整，但整体实用。
https://github.com/seata/seat…
学习理解Seata后咱们能够比对着理解EasyTransaction的架构设计。
EasyTransaction概述
EasyTransaction（后简称ET）的指标也是构建出一个全面分布式事务解决方案，到目前为止其蕴含TCC,主动弥补（Seata AT），手动弥补，牢靠事务音讯、Saga事务等等多种状态。
上面将就两个框架在设计上的差别进行剖析
外围差别图示
借用Seata的一张图：
与Seata不同，EasyTransaction对应的图如下：
TC差别
Seata:
有独立部署的集中式TCRM、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这个目前性能更为弱小、代码更为稳固、已上过生产的实现~
当然以上内容很多都带集体主观偏见，心愿各位能补充各种认识，兼听则明！
如果本文对你有帮忙，别忘记给我个3连 ，点赞，转发，评论，
咱们下期见！答案获取形式：已赞 已评 已关~
学习更多JAVA常识与技巧，关注与私信博主（666）
发表回复