雖然微服務現在如火如荼，但對其實踐其實仍處於初級階段。即使網際網路巨頭的實踐也大多是試驗層面，鮮有核心業務系統微服務化的案例。GTS是目前業界第一款，也是唯一的一款通用的解決微服務分散式事務問題的中介軟體，而且可以保證資料的強一致性。本文將對GTS做出深入解讀。

微服務倡導將複雜的單體應用拆分為若干個功能簡單的、鬆耦合的服務，這樣可以降低開發難度、增強擴充套件性、便於敏捷開發。概念2012年提出迅速火遍全球，被越來越多的開發者推崇，很多網際網路行業巨頭、開源社群等都開始了微服務的討論和實踐。根據Netflix雲架構總監Adrian Cockcrof，Hailo有160個不同服務構成，NetFlix有大約600個服務。國內方面，阿里巴巴、

GTS是一款分散式事務中介軟體，由阿里巴巴中介軟體部門研發，可以為微服務架構中的分散式事務提供一站式解決方案。GTS方案的基本思路是：將分散式事務與具體業務分離，在平臺層面開發通用的事務中介軟體GTS，由事務中介軟體協調各服務的呼叫一致性，負責分散式事務的生命週期管理、服務呼叫失敗的自動回滾。

GTS方案有三方面的優勢，首先它將微服務從分散式事務中解放出來，微服務的實現不需要再考慮反向介面、冪等、回滾策略等複雜問題，只需要業務自己的介面即可，大大降低了微服務開發的難度與工作量。將分散式事務從所謂的“貴族技術”變為大家都能使用的“平民技術 ”，有利於微服務的落地與推廣。 其次，GTS對業務程式碼幾乎沒有侵入，只需要通過註解@TxcTransaction界定事務邊界即可，微服務接入GTS的成本非常低。第三，效能方面GTS也非常優秀，是傳統XA方案的8～10倍。

1.1 基本原理

GTS中介軟體主要包括客戶端（GTS Client）、資源管理器（GTS RM）和事務協調器（GTS Server）三部分。GTS Client主要完成事務的發起與結束。GTS RM完成分支事務的開啟、提交、回滾等操作。GTS Server主要負責分散式事務的整體推進，事務生命週期的管理。 

GTS和微服務整合後的結構圖如上圖所示。GTS Client需要和業務應用整合部署，RM與微服務整合部署。當業務應用發起服務呼叫時，首先會通過GTS Client向TC註冊新的全域性事務。之後GTS Server會給業務應用返回全域性唯一的事務編號xid。業務應用呼叫服務時會將xid傳播到服務端。微服務在執行資料庫操作時會通過GTS RM向GTS Server註冊分支事務，並完成分支事務的提交。如果A、B、C三個服務均呼叫成功，GTS Client會通知GTS Server結束事務。假設C呼叫失敗，GTS Client會要求GTS Server發起全域性回滾。然後由各自的RM完成回滾工作。

1.2 GTS的關鍵機制

• 可用性 
  GTS服務也是由多個節點構成的高可用叢集，可以彈性擴張，可以接收高併發的客戶端請求。可以支援跨機房部署，支援同城容災和兩地三中心容災。任何異常情況下的保證高可用。
• 自動回滾策略 
  當有微服務呼叫失敗時，GTS服務可以驅動各微服務的RM替微服務完成呼叫的回滾工作。舉個轉賬的例子，轉賬應用通常呼叫存款服務和扣款服務完成轉賬功能。先呼叫扣款服務從A賬戶扣掉100元，然後呼叫存款服務向B賬戶中存款100元。如果轉賬應用在呼叫存款服務失敗時，GTS Client會要求GTS Server發起回滾，然後通知扣款服務對應的RM，RM會直接在A賬戶增加100元。然後GTS Server通知轉賬應用回滾成功。從這個過程可以看到，在呼叫服務失敗後，其實微服務不用做任何工作，而是由RM替微服務執行反向操作，也很自然的避免了冪等操作。TCC方案中，事務協調器需要顯示呼叫微服務的反向向介面，如果反向介面呼叫失敗還需要不斷重試。
• 可擴充套件性 
  有些情況下，應用需要呼叫第三方系統的介面或者不是基於GTS開發的微服，GTS無法接入到這些服務的實現中。此時需要用到GTS的MT模式。GTS的MT模式可以等價於TCC模式。

MT模式預留了一階段和二階段的提交介面，允許應用介入GTS的兩階段提交。應用將提交及回滾介面註冊後，GTS會自動完成呼叫。

• 隔離級別 
  GTS目前支援讀未提交和讀已提交兩種隔離級別。

1.3 GTS與其他方案的對比

1. 和XA方案對比

相比XA方案，GTS更加通用，可以對上層業務遮蔽底層實現細節，對業務幾乎沒有侵入。這一點在微服務時代特別有用，微服務面對的是大量的中小企業，甚至是個人開發者，業務訴求不盡相同，普適、標準的分散式事務產品是非常有必要的，可以讓開發者從底層技術細節中脫離出來，更專注於業務邏輯的實現，從而獲得更高效、快速的業務發展。兩個方案都可以遵循ACID特性，都可以實現事務的強一致性。GTS效能要比XA方案高。

2. 和TCC方案對比

GTS方案和TCC方案最大的區別是實現分散式事務實現的層面不同。TCC方案選擇從業務層面實現分散式事務功能，將事務的回滾、重試等功能在微服務中實現。而GTS選擇從中介軟體層面解決分散式事務問題，對微服務幾乎無侵入。兩個方案都可以獲得比較好的效能，都可以保證呼叫的一致性。TCC方案實現難度比較大，適合技術實力較強的團隊。GTS方案可以實現事務的強一致性，另外採用GTS方案後微服務會更簡單，耦合性也非常低。TCC主要提供開發框架，實現需要依賴業務方，而GTS是完整的分散式事務解決方案，所有分散式事務問題不需要業務方介入。

3. 和訊息最終一致性對比

相比訊息方案，GTS方案侵入性非常低，可以實現資料的強一致性。採用訊息方案，上下游服務之間有很強的耦合性，測試、部署都不是很方便，需要單獨建設訊息系統。不過訊息方案實現相對簡單，如果對一致性要求不高，也是一個選擇。

1.4 GTS的應用場景

GTS可應用在涉及服務呼叫的多個領域，包括但不限於金融支付、電信、電子商務、快遞物流、廣告營銷、社交、即時通訊、手遊、視訊、物聯網、車聯網等，詳細介紹可以閱讀 《GTS--阿里巴巴分散式事務全新解決方案》一文。

1.5 GTS的輸出形式

GTS目前有三種輸出形式：通過公有云平臺輸出、通過公網雲服務輸出、通過專有云平臺輸出。

• 1 通過公有云平臺輸出

這種輸出形式主要面向阿里雲使用者。如果使用者的業務系統已經部署到阿里雲上，可以直接申請開通公有云GTS。開通後業務應用即可通過GTS保證服務呼叫的一致行。這種使用場景下，業務系統和GTS間的網路環境比較理想，GTS能提供更低的響應時間。

公有云提供了比較豐富的與dubbo、SpringCloud等整合的樣例，可以點選檢視。

• 2 通過公網雲服務輸出

這種輸出形式主要面向於非阿里雲的使用者，使用更加方便、靈活，業務系統只要能連線網際網路即可享受GTS提供的雲服務。在網路抖動和閃斷的情況下，GTS仍能保證服務呼叫的一致性。在正常網路環境下，以包含兩個本地事務的全域性事務為例，事務完成時間在20ms左右，業務可以輕鬆實現1000TPS以上分散式事務，可以滿足絕大多數業務系統的需要。也可以用於本地的開發和測試 。

現在提供了sample-txc-simple和sample-txc-sample兩個樣例，sample-txc-simple是GTS的入門的基礎樣例，點選下載後，搭建好本地的資料庫環境就可以直接執行樣例。sample-txc-dubbo是GTS和dubbo框架整合的樣例，也可以直接在本地機器執行。

• 3 通過專有云平臺輸出

這種形式主要面向於已建設了自己專有云平臺的大使用者，GTS可以直接部署到使用者的專有云平臺上，為專有云提供分散式事務服務。目前國家電網公司、中國郵政、浙江菸草等特大型企業的專有云都使用GTS，保證資料一致性。

1.6 GTS的使用方式

GTS對應用的侵入性非常低，使用也非常簡單。下面以訂單儲存應用為例說明。訂單業務應用通過呼叫訂單服務和庫存服務完成訂單業務，服務開發框架為dubbo。

1 訂單業務應用

在業務函式外圍使用@TxcTransaction註解即可開啟分散式事務。dubbo應用通過隱藏引數將GTS的事務xid傳播到服務端。

@TxcTransaction(timeout = 1000 * 10)
public void Bussiness(OrderServiceInterface os,StockServiceInterface ss)
{
//獲取xid
String xid = TxcContext.getCurrentXid();
//1：呼叫訂單服務，建立訂單
//通過dubbo的隱形引數將txcid傳到服務端
RpcContext.getContext().setAttachment("xid",xid);
int ret = os.setOrder(new Order(pid,num,new Date()));//呼叫訂單服務
//2：呼叫庫存服務，扣庫存
RpcContext.getContext().setAttachment("xid",xid);
}

2 服務端使用方式

庫存服務

public int setStock(Stock sk) {
//通過dubbo上下文獲取xid
String xid = RpcContext.getContext().getAttachment("xid");
//將事務id繫結到服務端txc的上下文
TxcContext.bind(xid,null);
//執行扣庫存操作
ret  = jdbcTemplate2.update("update stock set number = number -? where pid = ?",new Object[]{sk.getPnum(),sk.getPid()});
return ret;
}

1.7 GTS的應用情況

GTS在滿足事務ACID的前提下，普通配置的單伺服器可以達到15000 TPS以上的超強效能（兩個小時完成1億多筆業務）。目前已經在淘寶、天貓、阿里影業、淘票票、阿里媽媽、1688等阿里各業務系統廣泛使用，經受了16年和17年兩年雙十一海量請求的考驗。某線上業務系統最高流量已達十萬TPS（每秒鐘10萬筆事務）。GTS在阿里雲及專有云上輸出後，有很多使用者通過GTS解決SpringCloud、Dubbo、Edas等微服務的分散式事務問題，包括國家電網、中國郵政、中國菸草、特步、浙江公安、德邦快遞、一步共享科技等，涉及電力、物流、ETC、菸草、金融、零售、電商、共享出行等十幾個行業，得到使用者的一致認可。

上圖是GTS與SpringCloud整合，應用於某共享出行系統。業務共享出行場景下，通過GTS支撐物聯網系統、訂單系統、支付系統、運維繫統、分析系統等系各統應用事務一致性，保證海量訂單和數千萬流水的交易。