事物問題是很多開發者和設計者非常頭疼的問題，本文主要介紹阿裡巴巴GTS-全新的分布式事務解決方案的思路。GTS提供完整的事務解決方案，可以解決跨資料庫事務問題，微服務化的事務問題，消息事務問題和混合事務問題，同時保證業務的一緻性。GTS對應用的侵入性非常低，性能非常強，GTS性能是傳統的分布式事務的10倍，4c8g叢集可達1.5萬TPS，目前最高可達10萬TPS。
演講嘉賓簡介：厲啟鵬（寈峰），阿裡巴巴中間件技術專家
本次直播視訊精彩回顧，戳這裡！以下内容根據演講嘉賓視訊分享以及PPT整理而成。
本次的分享主要圍繞以下四個方面：一、産品簡介
二、功能架構
三、典型場景
四、實踐操作
1.GTS是什麼GTS是一款也是唯一一款專注于分布式事務問題的中間件。我們把它定義為一站式的分布式事務解決方案。也就是說有了GTS之後，使用者不再需要考慮到復原接口的開發，幂等，以及分布式事務引發的其它異常等等。隻需要接入GTS，GTS可以保證應用的所有事務問題。我們把事務問題歸結為四個方面，也是GTS現在可以解決的四大事務問題。
第一類是跨庫問題，實際上，跨庫問題是最早碰到的事務問題。這裡跨庫是指兩方面，一方面是有很多的分布式資料庫，分布式資料庫如果沒有事務功能的話，GTS可以為它提供分布式事務的服務。還有一種是跨異構的資料庫，或者同構的資料庫。比如說業務系統要通路多個MySQL的執行個體，或者說通路一個MySQL，ObenBase這種異構的資料庫，那這時GTS也可以保證跨異構資料庫，或者同構資料庫的一緻性。
第二類是微服務化的事務，在後續這個會有非常廣的應用。因為微服務到來之後，傳統的服務被劃分的粒度非常細。之前一次的RPC調用現在可能要變成若幹次RPC調用，這時候它不可避免的會牽扯到事務的問題。我們在GTS公測之後，2月份我們陸陸續續接過來很多的公有雲使用者，很多都是因為企業在數字化轉型的過程中，微服務化之後碰到了跨事務的微服務調用。比如使用者買東西的時候，需要保證訂單服務，也需要保證庫存服務，也要保證它們的一緻性。現在很多主流的微服務架構，SpringCloud，Double，EDAS它們實際上架構并沒有獨立的事務解決方案。這是GTS未來會公開使用的重點場景。
還有一類是消息事務。現在有很多消息元件，有的支援事務功能，有的不支援事務功能。GTS也可以支援消息事務。還有一類是混合事務。有的時候業務系統又要進行本地的SQL操作，還要進行遠端的RPC調用，而且還要發消息，這時候GTS可以支援整個事務鍊上有多種類型的事務，保證多種事務的一緻性。
2.GTS與其他解決方案對比在GTS出現之前，業界也是有其它的事務解決方案，第一類是XA方案，第二類是補償方案，也就是TCC的方案，第三類是消息的方案。
XA方案最早是解決跨資料庫的事務問題，它的優勢是接口标準化，使用門檻比較低，而且能夠達到強一緻性的效果。但是有個不理想的是使用了阻塞協定，在高并發的場景下性能不是很理想。而且在微服務化之後可能沒辦法解決微服務的事務問題。第二類補償性方案（TCC）其實是比較符合也無需求的，因為它大部分都是按照特定的業務去做開發，它的效率其實取決于開發者的水準。TCC的方案中小型企業其實用的比較少，一方面它需要的人力成本非常高，對開發者的各方面能力有很高的要求。這個方案的不足之處在于非常複雜，每個服務都需求提供一個反向的接口。比如一個下單的操作，還需要一個下單方法的反向復原的方法，是以說運維成本比較高。第三類消息方案是通過消息異步的補償一緻性，這個方案實作相對簡單。但是需要建立獨立的消息系統，應用需要跟消息系統耦合在一起，而且需要業務實作幂等，它要求最終一緻性，場景會受一些限制，對一緻性要求非常搞的場景不太适應。
XA的方案是在資源的層面解決事務問題，因為XA有一個資料總管是跟資料庫放在一起，是以它對于資源是有限制的，現在絕大部分隻能支援關系型的資料庫，還不是所有的關系型資料庫，場景是受限制的。那補償方案和消息方案是從應用的層面解決事務問題，它們會和應用耦合在一起。GTS跟這三者不同點在于，它既不在資源層也不在應用層，它是在中間件層解決事務的問題，這是它們本質的差別。在中間件有什麼好處呢，大概有三點。第一，因為在中間件層，是獨立的一層，它可以解決跨資源的問題。如果應用去通路不同類型的問題，比如通路OpenBase，還有MySQL，以及Oracle，這時還需要保證一緻性。XA方案很難做到這一點，GTS可以保證異構資源事務的一緻性，異構的資料庫，甚至檔案系統。另外一個好處是GTS不在應用層面，就可以解決服務化問題。另外它和應用是松耦合的，這樣應用會更加清亮，比如說一個微服務要解決事務的問題，要實作幂等等操作，它會把非常複雜的解決事務的邏輯嵌入到微服務裡，這時微服務已不是微服務，變得非常重。GTS解決事務問題時會讓微服務更加簡單更加清亮化。而且GTS獨立開來，從中間件這層解決事務，便于應用移植。
下圖是從技術層面列的GTS的特點和優勢。GTS會提供事務的完整解決方案，第二個是GTS對應用的侵入性非常低，這一點意味着它使用的門檻就很低。如果需要用EDAS的話，隻需要加一行注解就OK了，就可以接入到事務中。而且我們還提供了APIAccess模式，使用非常友善，基本上使用Java開發半年的使用者就可以很友善的使用我們的GTS，我們官方已經有非常完善的文檔和樣例。還有GTS的性能非常強，通過很多次測試，包括做了要求非常嚴格的金融行業的測試。是傳統的分布式事務的10倍，4c8g叢集可達1.5萬TPS。我們今年春節的時候淘寶活動，當時有個應用達到了10萬TPS，是使用了三個9個節點的叢集支援這個應用。除此之外，GTS有高可用的特點。它支援應用當機，節點故障等各類異常情況下保證資料嚴格一緻，并支援同城主備及兩地三中心部署。
大家熟悉的很多平台後面都有GTS的支撐，如淘寶，阿裡音樂，盒馬生鮮，農村淘寶等等。另外有一些是專有雲使用者，很多政府部門要建設自己的專有的雲平台，GTS也可以以專有雲的形式輸出。國家的電動汽車交易是基于GTS來保證事務的功能的。另外一部分是公有雲使用者，大部分是釋出阿裡雲公測之後過來的，包括物流，金融，共享單車，新零售等等一百多個使用者。
GTS從2018年5月21日開始商用，首發第一個月内七折，按不同規格分，最高規格年付是六折。
下圖是GTS總體的功能架構，左邊是總體服務端的叢集，GTS一個标準的叢集有三個節點，三個節點之間是互備的。右邊是GTS用戶端，是以SDK的形式與應用內建在一起。用戶端負責全局事務的發起，全局事務的結束，全局事務的復原，分支事務的送出，分支事務的復原等操作。服務端是全局事務整個生命周期的管理，會記錄每個事務的運作狀态，每個事務有哪些分支事務，每個分支事務的運作狀态。GTS可以跟服務的架構內建，解決服務化事務問題，也可以跟資源對接，解決應用跨資源事務問題。
GTS事務模型非常簡單，全局事務包含若幹個分支事務。舉例來說，一個SQL裡面有若幹條SQL語句，每個SQL語句就是分支事務。全局事務辨別為xid，分支事務辨別為branchid，因為服務端會記錄每個分支事務的狀态，通過模型來組織事務的存儲。
下圖是用戶端和服務端互動的協定。這裡的用戶端包含兩部分，一個是GTS Client，還有一個是RM，也就是資料總管，通常跟服務內建在一起。首先用戶端會往Server端要一個事務的辨別xid，拿到之後把xid傳給RM，每個RM可能是一個或幾個事務分支。RM拿到xid之後會往Server端要分支事務的id，拿到id号代表它以及啟動一個分支事務了，這時它可能會送出本地的SQL語句，之後把送出的狀态彙報給Server。如果所有的RM執行完畢之後會傳回給Client端，Client端告訴Server要全局送出事務，這時整個全局事務就已經送出了。
下圖表示的是有一個業務應用需要調用三個微服務，業務應用通過Server端拿到xid之後，它會把xid傳到各個微服務做調用，，每個都做一些資料庫操作和資源的通路。如果在調用微服務C的時候失敗了，GTS需要復原前兩次操作，復原是GTS要做的，跟TCC不同。如果有個微服務失敗，傳到業務應用，業務應用告訴Server，Server會把跟GTS內建咋一起的SDK，SDK裡面有RM，RM會讓微服務A和B分别做復原。因為GTS在每次SQL操作之後會記錄SQL前後鏡像的資訊，也就是說之前的數值是知道的，避免幂等的問題，沒有必要做反向接口，而是直接復原就可以了。這一點非常重要，很多從事TCC開發的人員在這方面是非常頭疼的。
GTS在服務端，用戶端發生異常的時候都可以保證業務的連續性。比如下圖，GTS的服務端是個三節點的叢集，有三個應用。GTS有一些核心的資料資訊，包括鎖資訊。使用者如果牽扯到并發的修改鏡像記錄是需要有鎖的，GTS會把鎖資訊和各個事務的一些執行狀态記錄下來，這就是它的關鍵資訊。這些資訊是互備的，S1的備到S2上，S2的備到S3上，S3的備到S1上。如果APP正在發生復原操作的時候，S3挂掉了，APP的RM是知道S3的備用節點的，由備用節點去驅動，完成復原的操作。
還有一種情況是應用當機。GTS也可以保證業務的一緻性，當然前提是應用是負載均衡部署。
如果說在全局復原的時候，APP1挂掉了，GTS是知道跟APP1負載均衡在一起的其它APP。GTS可以驅動其它的APP來完成APP1沒有完成的復原的操作。可以完成的核心在于資料在下面的資料庫裡，隻不過找一個跟APP1操作相同，有權限操作相同資料的其它應用幹這件事情。
GTS可以支援應用的橫向擴充，如果說三個節點APP非常多，可以通過實體組将這些叢集映射到不同的GTS叢集。
GTS有兩個使用模式，AT和MT。AT是自動模式，可以完全自動復原，可以覆寫90%左右的業務場景，是以比較推薦使用AT模式，它對業務無侵入，高效，強一緻性。還有一種MT模式是GTS推出的相容TCC的模式，因為有一些情況下是無法避免的要使用TCC模式。而且GTS可以實作兩種模式的組合。
第一種GTS應用場景，支援跨資料庫的事務問題。應用有跨庫的操作，跨庫的一緻性都可以得到保證。
微服務調用如果有嵌套的場景，GTS可以保證這個調用鍊條中的事務，也可以保證調用的一緻性。
我們有一個放款應用，它需要調用本地金融系統的三個服務以及第三方系統的服務。用信用核心調使用者的信用，而且用風控中心的服務評估放款的風險，之後還需要調用額度中心生成使用者放款的額度，最後去銀行調銀行系統放款。整個調用鍊需要保證，如果放款失敗的話需要復原前三個服務，因為前三個服務都是由SQL寫入。這個場景複雜的點在于不可能復原第三方系統銀行的賬戶，是以這時候需要用到AT+MT混合的模式。在調用前三個服務的時候使用AT模式，那在調用支用和合法校驗的時候必須要使用MT模式，也就是銀行那邊給你提供一個反向接口，或者自己做一個補償的反向機制。
混合事務問題應用也很廣，我們有DRDS，MQ，EDAS的調用，隻要在一個調用鍊中，GTS都可以解決。
我們有一個公有雲使用者，是共享電動自行車的公司。它有很多的服務，是基于SpringCloud建構的微服務，裡面有很多訂單，優惠，支付，車輛，運維等很多應用子產品。有兩個典型的服務就是借車和還車。借車有車況檢測，生成訂單，變更狀态，推送訂單消息到MQ，這時候這個調用鍊中有服務，也有消息的場景。這個過程是通過GTS來保證事務的一緻性。還車的時候需要鎖車，結束訂單，推送消息到MQ，擷取優惠券資訊，扣款，也是典型的事務。使用者從3月份開始上公有雲，線上的系統也跑了一段時間，非常穩定，每天的事務量大概在幾百萬，非常飽和。
下面簡單介紹GTS的用法。阿裡雲的官方網站上有GTS的一些文檔和樣例工程，這裡截取樣例工程的案例來展示。下圖的案例是個非常簡單的轉賬操作，其中有兩個分支，一個是從db1的賬戶裡扣款，然後去另一個賬戶存款。在後面做一個檢測，看剛剛扣款的賬戶是不是小于零，如果小于零就是沒錢了，抛出異常。上面的紅色的一行是GTS注解，可以劃分事務的邊界，如果抛出異常，整個就可以復原。
使用EDAS用戶端也跟上面類似，上面是直接操作資料庫。這裡也是先加錢再減錢，使用Transaction注解開啟一個事務。
下圖是EDAS服務端扣款的操作，實際上沒有GTS的痕迹，純業務操作，GTS對服務端代碼是沒有侵入的。
下圖是EDAS的配置檔案，需要注意的是這個需要按照GTS的要求進行修改。首先資料源是GTS自己帶的txc.datasource，需要這個資料源主要是需要截取鏡像資訊做復原。還有一個是TxcTransactionScaner需要配置一下，有三個參數。第一個是邏輯事務分組，主要來辨別一個GTS使用者的，後面accessKey和SecretKey是阿裡雲帳号的資訊。
下圖是MT模式下的操作，在金融行業裡面TCC模式用的比較多。MT模式首先需要加注解界定事務的邊界，然後通過MtBranch注解告訴GTS第一階段的資源鎖定方法是哪個，然後送出的方法，第二階段rollback方法是哪個。實作這個接口之後GTS可以按照不同的方法調用。