偶然間看到阿里開源的分散式事務中介軟體，期待有投入到生產階段的栗子。從藍圖上看出目前有支援dubbo的解決方案，後續0.5.x版本會推出支援spring cloud的方案。 下面看官方正文，喜歡的可以去官方Github上瞧瞧看看。
Fescar 是 阿里巴巴 開源的 分散式事務中介軟體，以 高效 並且對業務 0 侵入 的方式，解決 微服務 場景下面臨的分散式事務問題。
1. 什麼是微服務化帶來的分散式事務問題？
首先，設想一個傳統的單體應用（Monolithic App），通過 3 個 Module，在同一個資料來源上更新資料來完成一項業務。
很自然的，整個業務過程的資料一致性由本地事務來保證。
隨著業務需求和架構的變化，單體應用被拆分為微服務：原來的 3 個 Module 被拆分為 3 個獨立的服務，分別使用獨立的資料來源（Pattern: Database per service）。業務過程將由 3 個服務的呼叫來完成。
此時，每一個服務內部的資料一致性仍有本地事務來保證。而整個業務層面的全域性資料一致性要如何保障呢？這就是微服務架構下面臨的，典型的分散式事務需求：我們需要一個分散式事務的解決方案保障業務全域性的資料一致性。
2. Fescar 的發展歷程
阿里是國內最早一批進行應用分散式（微服務化）改造的企業，所以很早就遇到微服務架構下的分散式事務問題。
2014 年，阿里中介軟體團隊釋出 TXC（Taobao Transaction Constructor），為集團內應用提供分散式事務服務。
2016 年，TXC 經過產品化改造，以 **GTS（Global Transaction Service）**的身份登陸阿里雲，成為當時業界唯一一款雲上分散式事務產品，在阿雲裡的公有云、專有云解決方案中，開始服務於眾多外部客戶。
2019 年起，基於 TXC 和 GTS 的技術積累，阿里中介軟體團隊發起了開源專案 Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社群一起建設這個分散式事務解決方案。
TXC/GTS/Fescar 一脈相承，為解決微服務架構下的分散式事務問題交出了一份與眾不同的答卷。
2.1 設計初衷
高速增長的網際網路時代，快速試錯 的能力對業務來說是至關重要的：
- 一方面，不應該因為技術架構上的微服務化和分散式事務支援的引入，給業務層面帶來額外的研發負擔。
- 另一方面，引入分散式事務支援的業務應該基本保持在同一量級上的效能表現，不能因為事務機制顯著拖慢業務。
基於這兩點，我們設計之初的最重要的考量就在於：
- 對業務無侵入： 這裡的 侵入 是指，因為分散式事務這個技術問題的制約，要求應用在業務層面進行設計和改造。這種設計和改造往往會給應用帶來很高的研發和維護成本。我們希望把分散式事務問題在 中介軟體 這個層次解決掉，不要求應用在業務層面做額外的工作。
- 高效能： 引入分散式事務的保障，必然會有額外的開銷，引起效能的下降。我們希望把分散式事務引入的效能損耗降到非常低的水平，讓應用不因為分散式事務的引入導致業務的可用性受影響。
2.2 既有的解決方案為什麼不滿足？
既有的分散式事務解決方案按照對業務侵入性分為兩類，即：對業務無侵入的和對業務有侵入的。
業務無侵入的方案
既有的主流分散式事務解決方案中，對業務無侵入的只有基於 XA 的方案，但應用 XA 方案存在 3 個方面的問題：
- 要求資料庫提供對 XA 的支援。如果遇到不支援 XA（或支援得不好，比如 MySQL 5.7 以前的版本）的資料庫，則不能使用。
- 受協議本身的約束，事務資源的鎖定週期長。長週期的資源鎖定從業務層面來看，往往是不必要的，而因為事務資源的管理器是資料庫本身，應用層無法插手。這樣形成的局面就是，基於 XA 的應用往往效能會比較差，而且很難優化。
- 已經落地的基於 XA 的分散式解決方案，都依託於重量級的應用伺服器（Tuxedo/WebLogic/WebSphere 等)，這是不適用於微服務架構的。
侵入業務的方案
實際上，最初分散式事務只有 XA 這個唯一方案。XA 是完備的，但在實踐過程中，由於種種原因（包含但不限於上面提到的 3 點）往往不得不放棄，轉而從業務層面著手來解決分散式事務問題。比如：
- 基於可靠訊息的最終一致性方案
- TCC
- Saga
都屬於這一類。這些方案的具體機制在這裡不做展開，網上這方面的論述文章非常多。總之，這些方案都要求在應用的業務層面把分散式事務技術約束考慮到設計中，通常每一個服務都需要設計實現正向和反向的冪等介面。這樣的設計約束，往往會導致很高的研發和維護成本。
2.3 理想的方案應該是什麼樣子？
不可否認，侵入業務的分散式事務方案都經過大量實踐驗證，能有效解決問題，在各行種業的業務應用系統中起著重要作用。但回到原點來思考，這些方案的採用實際上都是 迫於無奈。設想，如果基於 XA 的方案能夠不那麼 重，並且能保證業務的效能需求，相信不會有人願意把分散式事務問題拿到業務層面來解決。
一個理想的分散式事務解決方案應該：像使用 本地事務 一樣簡單，業務邏輯只關注業務層面的需求，不需要考慮事務機制上的約束。
3. 原理和設計
我們要設計一個對業務無侵入的方案，所以從業務無侵入的 XA 方案來思考：
是否可以在 XA 的基礎上演進，解決掉 XA 方案面臨的問題呢？
3.1 如何定義一個分散式事務？
首先，很自然的，我們可以把一個分散式事務理解成一個包含了若干 分支事務 的 全域性事務。全域性事務 的職責是協調其下管轄的 分支事務 達成一致，要麼一起成功提交，要麼一起失敗回滾。此外，通常 分支事務 本身就是一個滿足 ACID 的 本地事務。這是我們對分散式事務結構的基本認識，與 XA 是一致的。
其次，與 XA 的模型類似，我們定義 3 個元件來協議分散式事務的處理過程。
- Transaction Coordinator (TC)： 事務協調器，維護全域性事務的執行狀態，負責協調並驅動全域性事務的提交或回滾。
- Transaction Manager (TM)： 控制全域性事務的邊界，負責開啟一個全域性事務，並最終發起全域性提交或全域性回滾的決議。
- Resource Manager (RM)： 控制分支事務，負責分支註冊、狀態彙報，並接收事務協調器的指令，驅動分支（本地）事務的提交和回滾。
一個典型的分散式事務過程：
- TM 向 TC 申請開啟一個全域性事務，全域性事務建立成功並生成一個全域性唯一的 XID。
- XID 在微服務呼叫鏈路的上下文中傳播。
- RM 向 TC 註冊分支事務，將其納入 XID 對應全域性事務的管轄。
- TM 向 TC 發起針對 XID 的全域性提交或回滾決議。
- TC 排程 XID 下管轄的全部分支事務完成提交或回滾請求。
至此，Fescar 的協議機制總體上看與 XA 是一致的。
3.2 與 XA 的差別在什麼地方？
架構層次
XA 方案的 RM 實際上是在資料庫層，RM 本質上就是資料庫自身（通過提供支援 XA 的驅動程式來供應用使用）。
而 Fescar 的 RM 是以二方包的形式作為中介軟體層部署在應用程式這一側的，不依賴與資料庫本身對協議的支援，當然也不需要資料庫支援 XA 協議。這點對於微服務化的架構來說是非常重要的：應用層不需要為本地事務和分散式事務兩類不同場景來適配兩套不同的資料庫驅動。
這個設計，剝離了分散式事務方案對資料庫在 協議支援 上的要求。
兩階段提交
先來看一下 XA 的 2PC 過程。
無論 Phase2 的決議是 commit 還是 rollback，事務性資源的鎖都要保持到 Phase2 完成才釋放。
設想一個正常執行的業務，大概率是 90% 以上的事務最終應該是成功提交的，我們是否可以在 Phase1 就將本地事務提交呢？這樣 90% 以上的情況下，可以省去 Phase2 持鎖的時間，整體提高效率。
這個設計，在絕大多數場景減少了事務持鎖時間，從而提高了事務的併發度。
當然，你肯定會問：Phase1 即提交的情況下，Phase2 如何回滾呢？
3.3 分支事務如何提交和回滾？
首先，應用需要使用 Fescar 的 JDBC 資料來源代理，也就是 Fescar 的 RM。
Phase1：
Fescar 的 JDBC 資料來源代理通過對業務 SQL 的解析，把業務資料在更新前後的資料映象組織成回滾日誌，利用 本地事務 的 ACID 特性，將業務資料的更新和回滾日誌的寫入在同一個 本地事務 中提交。
這樣，可以保證：任何提交的業務資料的更新一定有相應的回滾日誌存在。
基於這樣的機制，分支的本地事務便可以在全域性事務的 Phase1 提交，馬上釋放本地事務鎖定的資源。
Phase2：
- 如果決議是全域性提交，此時分支事務此時已經完成提交，不需要同步協調處理（只需要非同步清理回滾日誌），Phase2 可以非常快速地完成。
- 如果決議是全域性回滾，RM 收到協調器發來的回滾請求，通過 XID 和 Branch ID 找到相應的回滾日誌記錄，通過回滾記錄生成反向的更新 SQL 並執行，以完成分支的回滾。
3.4 事務傳播機制
XID 是一個全域性事務的唯一標識，事務傳播機制要做的就是把 XID 在服務呼叫鏈路中傳遞下去，並繫結到服務的事務上下文中，這樣，服務鏈路中的資料庫更新操作，就都會向該 XID 代表的全域性事務註冊分支，納入同一個全域性事務的管轄。
基於這個機制，Fescar 是可以支援任何微服務 RPC 框架的。只要在特定框架中找到可以透明傳播 XID 的機制即可，比如，Dubbo 的 Filter + RpcContext。
對應到 Java EE 規範和 Spring 定義的事務傳播屬性，Fescar 的支援如下：
- PROPAGATION_REQUIRED： 預設支援
- PROPAGATION_SUPPORTS： 預設支援
- PROPAGATION_MANDATORY：應用通過 API 來實現
- PROPAGATION_REQUIRES_NEW：應用通過 API 來實現
- PROPAGATION_NOT_SUPPORTED：應用通過 API 來實現
- PROPAGATION_NEVER：應用通過 API 來實現
- PROPAGATION_REQUIRED_NESTED：不支援
3.5 隔離性
全域性事務的隔離性是建立在分支事務的本地隔離級別基礎之上的。
在資料庫本地隔離級別 讀已提交 或以上的前提下，Fescar 設計了由事務協調器維護的 全域性寫排他鎖，來保證事務間的 寫隔離，將全域性事務預設定義在 讀未提交 的隔離級別上。
我們對隔離級別的共識是：絕大部分應用在 讀已提交 的隔離級別下工作是沒有問題的。而實際上，這當中又有絕大多數的應用場景，實際上工作在 讀未提交 的隔離級別下同樣沒有問題。
在極端場景下，應用如果需要達到全域性的 讀已提交，Fescar 也提供了相應的機制來達到目的。預設，Fescar 是工作在 讀無提交 的隔離級別下，保證絕大多數場景的高效性。
事務的 ACID 屬性在 Fescar 中的體現是一個比較複雜的話題，我們會有專門的文章來深入分析，這裡不做進一步展開。
4. 適用場景分析
前文所述的 Fescar 的核心原理中有一個 重要前提：分支事務中涉及的資源，必須 是支援 ACID 事務的 關係型資料庫。分支的提交和回滾機制，都依賴於本地事務的保障。所以，如果應用使用的資料庫是不支援事務的，或根本不是關係型資料庫，就不適用。
另外，目前 Fescar 的實現還存在一些侷限，比如：事務隔離級別最高支援到 讀已提交 的水平，SQL 的解析還不能涵蓋全部的語法等。
為了覆蓋 Fescar 原生機制暫時不能支援應用場景，我們定義了另外一種工作模式。
上面介紹的 Fescar 原生工作模式稱為 AT（Automatic Transaction）模式，這種模式是對業務無侵入的。與之相應的另外一種工作模式稱為 MT（Manual Transaction）模式，這種模式下，分支事務需要應用自己來定義業務本身及提交和回滾的邏輯。
4.1 分支的基本行為模式
作為全域性事務一部分的分支事務，除本身的業務邏輯外，都包含 4 個與協調器互動的行為：
- 分支註冊： 在分支事務的資料操作進行之前，需要向協調器註冊，把即將進行的分支事務資料操作，納入一個已經開啟的全域性事務的管理中去，在分支註冊成功後，才可以進行資料操作。
- 狀態上報： 在分支事務的資料操作完成後，需要向事務協調器上報其執行結果。
- 分支提交：響應協調器發出的分支事務提交的請求，完成分支提交。
- 分支回滾：響應協調器發出的分支事務回滾的請求，完成分支回滾。
4.2 AT 模式分支的行為模式
業務邏輯不需要關注事務機制，分支與全域性事務的互動過程自動進行。
4.3 MT 模式分支的行為模式
業務邏輯需要被分解為 Prepare/Commit/Rollback 3 部分，形成一個 MT 分支，加入全域性事務。
MT 模式一方面是 AT 模式的補充。另外，更重要的價值在於，通過 MT 模式可以把眾多非事務性資源納入全域性事務的管理中。
4.4 混合模式
因為 AT 和 MT 模式的分支從根本上行為模式是一致的，所以可以完全相容，即，一個全域性事務中，可以同時存在 AT 和 MT 的分支。這樣就可以達到全面覆蓋業務場景的目的：AT 模式可以支援的，使用 AT 模式；AT 模式暫時支援不了的，用 MT 模式來替代。另外，自然的，MT 模式管理的非事務性資源也可以和支援事務的關係型資料庫資源一起，納入同一個分散式事務的管理中。
4.5 應用場景的遠景
回到我們設計的初衷：一個理想的分散式事務解決方案是不應該侵入業務的。MT 模式是在 AT 模式暫時不能完全覆蓋所有場景的情況下，一個比較自然的補充方案。我們希望通過 AT 模式的不斷演進增強，逐步擴大所支援的場景，MT 模式逐步收斂。未來，我們會納入對 XA 的原生支援，用 XA 這種無侵入的方式來覆蓋 AT 模式無法觸達的場景。
5. 擴充套件點
5.1 微服務框架的支援
事務上下文在微服務間的傳播需要根據微服務框架本身的機制，訂製最優的，對應用層透明的解決方案。有興趣在這方面共建的開發者可以參考內建的對 Dubbo 的支援方案，來實現對其他微服務框架的支援。
5.2 所支援的資料庫型別
因為 AT 涉及 SQL 的解析，所以在不同型別的資料庫上工作，會有一些特定的適配。有興趣在這方面共建的開發者可以參考內建的對 MySQL 的支援方案，來實現對其他資料庫的支援。
5.3 配置和服務註冊發現
支援接入不同的配置和服務註冊發現解決方案。比如：Nacos、Eureka、ZooKeeper 等。
5.4 MT 模式的場景擴充
MT 模式的一個重要作用就是，可以把非關係型資料庫的資源，通過 MT 模式分支的包裝，納入到全域性事務的管轄中來。比如，Redis、HBase、RocketMQ 的事務訊息等。有興趣在這方面共建的開發者可以在這裡貢獻一系列相關生態的適配方案。
5.5 事務協調器的分散式高可用方案
針對不同場景，支援不同的方式作為事務協調器 Server 端的高可用方案。比如，針對事務狀態的持久化，可以是基於檔案的實現方案，也可以是基於資料庫的實現方案；叢集間的狀態同步，可以是基於 RPC 通訊的方案，也可以是基於高可用 KV 儲存的方案。
6. Roadmap
藍圖
綠色 部分是已經開源釋出出來的，黃色 部分是將在後續版本中由阿里釋出出來的，藍色 部分是我們和社群共建生態部分：
- 對不同資料庫的支援，開發者可以參考 MySQL 的實現。
- 對不同微服務框架的支援，開發者可以參考 Dubbo 的實現。
- 對 MQ、NoSQL 的支援，開發者可以參考 TCC 的實現。
- 配置和服務註冊發現：開發者通過少量的工作可以接入任何可以提供這類服務的框架。
- 當然，非 藍色 的部分也非常歡迎社群參與進來，貢獻更優的解決方案。
- 另外，XA 作為分散式事務的標準，是一個完備的分散式事務解決方案不可或缺的，遠景的規劃中，我們一定需要把 XA 的支援加入進來。
初步的版本規劃
v0.1.0
- 微服務框架支援: Dubbo
- 資料庫支援: MySQL
- 基於 Spring AOP 的 Annotation
- 事務協調器: 單機版本
v0.5.x
- 微服務框架支援: Spring Cloud
- MT 模式
- 支援 TCC 模式事務的適配
- 動態配置和服務發現
- 事務協調器: 高可用叢集版本
v0.8.x
- Metrics
- 控制檯: 監控/部署/升級/擴縮容
v1.0.0
- General Availability: 生產環境適用
v1.5.x
- 資料庫支援: Oracle/PostgreSQL/OceanBase
- 不依賴 Spring AOP 的 Annotation
- 熱點資料的優化處理機制
- RocketMQ 事務訊息納入全域性事務管理
- NoSQL 納入全域性事務管理的適配機制
- 支援 HBase
- 支援 Redis
v2.0.0
- 支援 XA
當然，專案迭代演進的過程，我們最重視的是社群的聲音，路線圖會和社群充分交流及時進行調整。