開源分散式事務中介軟體 Fescar 自1月10日上線v0.1版本以來，受到了開發者們的極大關注（watch249，star3005，fork649，社群討論的issue58，資料統計於1月17日14:00），可見，天下苦分散式事務久矣。
為此，我們收集了大家在社群（Github）和社群（釘釘群&微信群）關注的核心問題，總結如下，並給出回覆。
Q1：Fescar 的發展經歷了哪些歷程？和阿里雲全域性事務服務GTS之間是什麼關係？
A1：阿里巴巴是國內最早一批進行應用分散式（微服務化）改造的企業，所以很早就遇到微服務架構下的分散式事務問題。
- 2014 年
阿里巴巴中介軟體團隊釋出TXC（Taobao Transaction Constructor），為集團內應用提供分散式事務服務。
- 2016 年
TXC 經過產品化改造，以GTS（Global TransactionService）的身份上線阿里雲，成為當時業界唯一一款雲上分散式事務產品，以阿里雲公有云或專有云解決方案的形式，交付給眾多外部客戶。
- 2019 年
基於 TXC 和 GTS 的技術積累，阿里巴巴中介軟體團隊發起了開源專案Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社群一起建設這個分散式事務解決方案。
TXC/GTS/Fescar一脈相承，為解決微服務架構下的分散式事務問題交出了一份與眾不同的答卷。
Q2：Fescar 有哪些適用場景？
A2：Fescar 的願景是讓分散式事務的使用像現在本地事務的使用一樣簡單、高效，最終的目標是希望可以適用於所有的分散式事務場景。目前，核心的 AT 模式適用於構建於支援本地 ACID 事務的關係型資料庫。非關係型資料庫類資源的管理，通過 MT 模式來支援。AT 模式與 MT 模式完全相容，所以可以在同一個分散式事務中，同時管理兩類資源。
Q3：目前有已經有一些其他的分散式事務開源方案，Fescar 和他們之間有哪些區別？和JTA支援分散式事務有哪些區別？
A3：既有的分散式事務解決方案按照對業務侵入性分為兩類，即：對業務無侵入的和對業務有侵入的。
- 業務無侵入的方案
既有的主流分散式事務解決方案中，對業務無侵入的只有基於 XA 的方案（注：問題中提到的 JTA 是XA 方案的 Java 版本），但應用XA 方案存在 3 個方面的問題：
1、要求資料庫提供對 XA 的支援。如果遇到不支援 XA（或支援得不好，比如 MySQL 5.7 以前的版本）的資料庫，則不能使用。
2、受協議本身的約束，事務資源（資料記錄、資料庫連線）的鎖定週期長。長週期的資源鎖定從業務層面來看，往往是不必要的，而因為事務資源的管理器是資料庫本身，應用層無法插手。這樣形成的局面就是，基於 XA 的應用往往效能會比較差，而且很難優化。
3、已經落地的基於 XA 的分散式解決方案，都依託於重量級的應用伺服器（Tuxedo/WebLogic/WebSphere 等)，這是不適用於微服務架構的。
- 侵入業務的方案
實際上，最初分散式事務只有 XA 這個唯一方案。XA 是完備的，但在實踐過程中，由於種種原因（包含但不限於上面提到的3 點）往往不得不放棄，轉而從業務層面著手來解決分散式事務問題。比如：
- 基於可靠訊息的最終一致性方案
- TCC
- Saga
都屬於這一類。這些方案的具體機制在這裡不做展開，網上這方面的論述文章非常多。總之，這些方案都要求在應用的業務層面把分散式事務技術約束考慮到設計中，通常每一個服務都需要設計實現正向和反向的冪等介面。這樣的設計約束，往往會導致很高的研發和維護成本。
不可否認，侵入業務的分散式事務方案都經過大量實踐驗證，能有效解決問題，在各行種業的業務應用系統中起著重要作用。但回到原點來思考，這些方案的採用實際上都是迫於無奈。
回到問題：
與基於訊息的最終一致、TCC、Saga等業務邏輯侵入方案的不同在於，Fescar 的設計初衷就是保持對業務的非侵入性，不要求業務層面按照分散式事務的特定場景來設計正向和反向的兩套（甚至多套）業務邏輯。這方面的差別就不展開了。
與 XA 的區別在於，設計了一套不同與 XA 的兩階段協議，在保持對業務不侵入的前提下，保證良好的效能，也避免了對底層資料庫協議支援的要求。可以看作是一套輕量級的XA 機制。具體的差別如下：
- 架構層次
XA方案的 RM 實際上是在資料庫層，RM本質上就是資料庫自身（通過提供支援 XA 的驅動程式來供應用使用）。
而 Fescar 的RM 是以二方包的形式作為中介軟體層部署在應用程式這一側的，不依賴與資料庫本身對協議的支援，當然也不需要資料庫支援XA 協議。這點對於微服務化的架構來說是非常重要的：應用層不需要為本地事務和分散式事務兩類不同場景來適配兩套不同的資料庫驅動。
這個設計，剝離了分散式事務方案對資料庫在協議支援上的要求。
- 兩階段提交
先來看一下 XA 的2PC 過程。
無論 Phase2 的決議是commit 還是 rollback，事務性資源的鎖都要保持到Phase2 完成才釋放。
再看 Fescar 的2PC 過程。
分支事務中資料的 本地鎖 由本地事務管理，在分支事務 Phase1 結束時釋放。
同時，隨著本地事務結束，連線 也得以釋放。
分支事務中資料的 全域性鎖 在事務協調器側管理，在決議 Phase2 全域性提交時，全域性鎖馬上
可以釋放。只有在決議全域性回滾的情況下，全域性鎖 才被持有至分支的 Phase2 結束。
這個設計，極大地減少了分支事務對資源（資料和連線）的鎖定時間，給整體併發和吞吐的提升提供了基礎。
Q4：Fescar 支援 Dubbo 的哪些版本？
A4：所有版本。
Q5：Fescar 支援 Spring Cloud麼？
A5：Fescar 與微服務框架的介面點在於，需要把事務的唯一標識 XID（一個字串）通過微服務框架的服務呼叫間呼叫的機制中，透明地傳遞，並通過 Fescar 的 API 來繫結（或解綁）到應用的執行緒上下文中。（機制可以參考內建的對 Dubbo 支援的實現 com.alibaba.fescar.dubbo.TransactionPropagationFilter）所以，本質上這個問題不是支不支援 Spring Cloud，而是如何支援 Spring Cloud 中選用的服務呼叫機制。目前正在和 Spring Cloud Alibaba 的同學合作，準備在v0.5.x版本（或更早）釋出對 Spring Cloud預設的支援。同時，非常歡迎社群的朋友參與進來，貢獻包括 Spring Cloud 在內的各類微服務框架的支援。
Q6：Fescar 是否支援本地跨庫多資料來源？除了關係型資料庫，是否還支援NoSQL資料庫？
A6：本地跨多資料來源同樣是支援的，在 Fescar 的架構中，同一個服務中的多個資料來源與跨服務的多個資料來源，沒有本質區別。AT 模式目前僅限於對關係型資料庫的支援（本身具備ACID 事務支援），後面會發布出來的 MT 模式可以支援 NoSQL 這類本身不具備本地事務支援的資源。
Q7：Fescar 現在開源的是AT模式，MT模式暫時不支援，什麼時候會開源？
A7：當前 0.1.0 版本只是把 Fescar 最核心的 AT 模式的最小集釋出出來，一方面是按開源的規劃和架構的重構進展，另一方面也是希望通過最小集版本，讓使用者和開發者社群更容易理解到我們核心的設計思路，讓更多人比較容易地參與進來建設，而不是完全由阿里巴巴主導，僅僅把我們的整套方案開源出來給大家用而已。阿里巴巴在分散式事務上的技術積累，我們會通過 Fescar 專案毫無保留地貢獻給社群，所有功能特性都會按規劃和社群的反饋陸續開源出來。MT 按初步的計劃，會在 0.5.x 版本釋出。
Q8：Fescar 什麼時候提供HA cluster，單節點的server的瓶頸如何處理？
A8：按初步的計劃，HA Cluster 會在 0.5.x 版本釋出，解決單機部署的單點問題。
Q9：因網路中斷、網張閃斷、節點當機和超時等引起的異常，Fescar會提供相應的補償措施麼？
A9：這些異常情況的處理是分散式事務解決方案的基本要求，Fescar 同樣也是提供了整套方案來處理各類異常場景。這方面的具體機制會在 HA Cluster 版本釋出時，給出全面的分析介紹。
Q10：Fescar框架中，如何監控分散式事務？
A10：監控是非常重要的一塊兒內容。TXC 和 GTS 的監控在阿里巴巴內部使用了很多基礎設施的輔助。而在開源版本中，我們還沒有一個現成的監控方案。大體上，監控的基礎是兩個方面：一方面是日誌，通過日誌的採集和處理，可以形成一個完整的事務鏈路，這些資料對於業務層面的分析和調優是重要的參考依據。另一方面是 API，Fescar 會提供一套管控 API，用於對執行時事務的管理。我們後續會把這兩方面的資料格式、部署形態及介面整理出來，希望和社群來共建監控這個重要的方面。
Q11：Fescar 的roadmap 有了麼？
A11：目前最新的roadmap如下：
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
當然，專案迭代演進的過程，我們最重視的是社群的聲音，路線圖會和社群充分交流及時進行調整。
Q12：Fescar 官網什麼時候上線？
A12：Fescar 官方域名已經註冊，官網將採用靜態開源站點搭建工具Docsite「傳送門」進行搭建，logo 已經設計並將於近期公佈。
Q13：如何加入 Fescar 社群，進行貢獻，已經摩拳擦掌了。
A13：我們非常歡迎大家通過各種形式參與到我們專案的建設中，包括但不限於：
- 架構設計
- 模組設計
- 程式碼實現
- Bug Fix
- Demo樣例
- 文件、網站和翻譯
具體的參與方法可以參見我們專案中的CONTRIBUTING 指引，或與 @eternaltingting@163.com 聯絡。實際上，我們並不拘泥於貢獻的形式，開發者提出的每一個 issue，無論是Bug Report、改進建議或者甚至是問題諮詢都代表著對專案的關注和幫助。希望 Fescar 專案和社群一起健康成長，成為分散式事務領域一個優秀的解決方案。
本文作者：中介軟體小哥
本文為雲棲社群原創內容，未經允許不得轉載。