分佈式事務框架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