GTS 今年雙 11 的成績
今年 2684 億的背後，有一個默默支撐，低調到幾乎被遺忘的中間件雲産品——GTS（全局事務服務，Global Transaction Service），穩穩地通過了自 2014 年誕生以來的第 5 次“大考”。
2019 年 11 月 1 日至 12 日，GTS 日均處理分布式事務數量達 億級 ，每天峰值 TPS 達 萬級 。
這背後最重要意義在于：成績是在給業務應用的設計和開發帶來 0 負擔 的前提下得到的。
GTS 帶來的價值
随着企業的發展，企業業務架構面臨資料、服務的分布化，幾乎無可避免地要遇到分布式架構帶來的資料一緻性問題。
GTS 開創性地把分布式事務問題從業務中剝離出來，作為一個獨立的技術切面來單獨管理，以服務的形式給建構在雲上的應用提供簡單、易用、高效的分布式事務解決方案。
GTS 給業務應用帶來的價值展現在以下幾個方面：
- 架構複雜度降低：分布式事務這個 切面 的技術問題，全部 收斂 到 GTS 提供的服務來解決。
- 設計和開發成本減輕：業務邏輯的設計和開發，完全不需要針對是否涉及分布式事務而做任何額外的事情，對業務 0 侵入 。
- 項目傳遞、疊代速度加快：歸因于上述兩點，項目得以很快傳遞和疊代。GTS 賦予業務應用 快速試錯 的能力，在這個商業機會瞬息萬變的時代，顯得尤為重要。
設想一個典型的雲原生企業應用的成長路徑：
- 1.0：單體應用，快速上線，這個時候完全不涉及分布式事務。
- 2.0：單個資料庫無法支撐，資料分布到多個資料庫，産生分布式事務問題。
- 3.0：微服務化，進一步産生跨服務的分布式事務。
- 4.0：跨應用的整合，成為 SaaS 或 FaaS 的平台，在更大的範圍，産生分布式事務問題。
基于 GTS 提供的分布式事務服務，企業發展各階段産生的不同場景下的資料一緻性問題，可以得到一站式的解決。這使得業務可以平滑自然地，像搭積木一樣成長起來。
從上面示例可以看到：GTS 實際上是把分布式事務（或者說分布式場景下的資料一緻性）能力，作為一種 雲原生 的服務，提供給生長在雲上的應用，讓分布式事務不再成為業務要面臨的一個令人頭疼的問題，而成為一種可以彈性伸縮，按需取用的服務能力。
GTS 的原理和創新
下面，從幾個方面來大體介紹 GTS 的原理和創新。
首先，GTS 把分布式事務定義為由若幹本地事務（分支）組成的全局事務。被全局事務管理的全部分支，将在協調器的協調下，保證一起成功或一起復原。
其次，GTS 定義了一個事務模型，把整個全局事務過程模型化為 TM、RM、TC 三個元件之間協作的機制。
- Transaction Coordinator (TC)： 事務協調器，維護全局事務的運作狀态，負責協調并驅動全局事務的送出或復原。
- Transaction Manager (TM)： 控制全局事務的邊界，負責開啟一個全局事務，并最終發起全局送出或全局復原的決議。
- Resource Manager (RM)： 控制分支事務，負責分支注冊、狀态彙報，并接收事務協調器的指令，驅動分支（本地）事務的送出和復原。
一個典型的分布式事務過程：
- TM 向 TC 申請開啟一個全局事務，全局事務建立成功并生成一個全局唯一的 XID。
- XID 在微服務調用鍊路的上下文中傳播。
- RM 向 TC 注冊分支事務，将其納入 XID 對應全局事務的管轄。
- TM 向 TC 發起針對 XID 的全局送出或復原決議。
- TC 排程 XID 下管轄的全部分支事務完成送出或復原請求。
第三，GTS 創新地基于 SQL 解析實作對業務無侵入的自動補償復原機制。這種機制，GTS 将其命名為 Auto Transaction (AT) 模式。基本工作原理如下：
GTS 把全局事務分為兩個階段：執行階段 和 完成階段 。
執行階段：
GTS 的 JDBC 資料源代理通過對業務 SQL 的解析，把業務資料在更新前後的資料鏡像組織成復原日志，利用 本地事務 的 ACID 特性，将業務資料的更新和復原日志的寫入在同一個 本地事務 中送出。
這樣，可以保證：任何送出的業務資料的更新一定有相應的復原日志存在。
基于這樣的機制，分支的本地事務便可以在全局事務的 執行階段 送出，馬上釋放本地事務鎖定的資源。
完成階段：
- 如果 TM 發出的決議是全局送出，此時分支事務此時已經完成送出，不需要同步協調處理（隻需要異步清理復原日志），完成階段 可以非常快速地完成。
- 如果 TM 發出的決議是全局復原，RM 收到協調器發來的復原請求，通過 XID 和 Branch ID 找到相應的復原日志記錄，通過復原記錄生成反向的更新 SQL 并執行，以完成分支的復原。
最後，GTS 通過事務協調器叢集以及對業務應用節點的容錯，實作一個拒絕單點故障的高可用服務。
一方面，GTS 服務叢集機制，保障任意服務節點當機，可以其他節點無縫接管。
另一方面，應用任意節點的當機，相應事務分支的請求也會路由到連接配接相同資料庫的其他節點上，不影響全局事務的完整執行。
分布式事務模式融合及标準化（保護）
截止目前，還沒有任何一種分布式事務的技術方案，可以滿足所有場景的問題。GTS 的 AT 模式适用于絕大部分常見場景，但仍有一些場景更适合于使用業界其他的分布式事務解決方案。GTS 會把各類解決方案融合到 GTS 提供的雲服務架構中，為雲原生應用提供一站式的分布式事務服務。
這是 GTS 的抽象出的事務架構。通過這個抽象，分布式事務得以從整體架構中剝離出來，形成一個單獨的技術切面，作為服務提供給應用。
簡單來說，基于這個架構的應用，其分布式事務問題，就收斂到基于 RM 的分支事務機制和 TC 提供的穩定、可靠的服務中。分而治之，才能更有效地解決問題。
目前分布式應用層面，最具代表性的事務模式有 4 種，分别是 AT、TCC、Saga 和 XA，這些模式各有優缺點和适用的場景。
下面列出 4 種事務模式的優劣，以及在 GTS 的事務架構中的映射。
AT
優勢： 業務無侵入；輕量，不依賴資料庫的進階特性；復原較少的場景性能高。
劣勢： 隔離性不高，目前隻能支援到接近 讀已送出 的程度，更高的隔離級别，實作成本将非常高。
TCC
優勢： 适用場景廣泛；隔離性和性能都可以做極緻優化。
劣勢： 業務侵入性非常高。
Saga
優勢： 長事務。
劣勢： 有一定業務侵入性；隔離性差。
XA
優勢： 業務無侵入；隔離性好。
劣勢： 阻塞協定。
GTS 與開源
為了更好地建構一個雲原生的分布式事務标準，2019 年初，GTS 選擇了開源，發起了開源項目
SEATA（曾用名 FESCAR）。項目開源不到 1 年時間，收獲 STAR 數已經突破 1.2 萬，Contributor 超過 120 名，獲得社群的廣泛關注和認可。
分布式事務一直以來都可以稱得上是世界性難題，希望可以通過 SEATA 這個開放的平台，聚集全世界的智慧來給這道難題交上一份讓人滿意的答卷。
進一步，GTS 将這份答卷轉化為阿裡雲上高效、穩定、可靠的服務，賦能給廣大雲原生開發者。
總結
GTS 自從 2014 年誕生于阿裡巴巴中間件的 5 年來，從支撐集團内第一個業務方開始，經曆了從内部到雲産品化，從封閉到開源，從單一模式到相容并蓄和标準化，一直堅定地走在分布式事務領域的最前沿。
GTS 的目标是雲原生時代，分布式事務的全面解決方案，任何分布式事務需求，在 GTS 上都能找到滿意的答案。
本文作者：煊檍，GitHub ID：sharajava，阿裡巴巴中件間 GTS 研發團隊負責人，SEATA 開源項目發起人，曾在 Oracle 北京研發中心多年，從事 WebLogic 核心研發工作。長期專注于中間件，尤其是分布式事務領域的技術實踐。