1 微服務的發展 微服務倡導將複雜的單體應用拆分為若幹個功能簡單、松耦合的服務，這樣可以降低開發難度、增強擴展性、便於敏捷開發。當前被越來越多的開發者推崇，很多互聯網行業巨頭、開源社區等都開始了微服務的討論和實踐。Hailo有160個不同服務構成，NetFlix有大約600個服務。國內方面，阿裡巴巴 ...
1 微服務的發展
微服務倡導將複雜的單體應用拆分為若幹個功能簡單、松耦合的服務，這樣可以降低開發難度、增強擴展性、便於敏捷開發。當前被越來越多的開發者推崇，很多互聯網行業巨頭、開源社區等都開始了微服務的討論和實踐。Hailo有160個不同服務構成，NetFlix有大約600個服務。國內方面，阿裡巴巴、騰訊、360、京東、58同城等很多互聯網公司都進行了微服務化實踐。當前微服務的開發框架也非常多，比較著名的有Dubbo、SpringCloud、thrift 、grpc等。
2 微服務落地存在的問題
雖然微服務現在如火如荼，但對其實踐其實仍處於探索階段。很多中小型互聯網公司，鑒於經驗、技術實力等問題，微服務落地比較困難。如著名架構師Chris Richardson所言，目前存在的主要困難有如下幾方面：
1）單體應用拆分為分散式系統後，進程間的通訊機制和故障處理措施變的更加複雜。
2）系統微服務化後，一個看似簡單的功能，內部可能需要調用多個服務並操作多個資料庫實現，服務調用的分散式事務問題變的非常突出。
3）微服務數量眾多，其測試、部署、監控等都變的更加困難。
隨著RPC框架的成熟，第一個問題已經逐漸得到解決。例如dubbo可以支持多種通訊協議，springcloud可以非常好的支持restful調用。對於第三個問題，隨著docker、devops技術的發展以及各公有雲paas平臺自動化運維工具的推出，微服務的測試、部署與運維會變得越來越容易。
而對於第二個問題，現在還沒有通用方案很好的解決微服務產生的事務問題。分散式事務已經成為微服務落地最大的阻礙，也是最具挑戰性的一個技術難題。 為此，本文將深入和大家探討微服務架構下，分散式事務的各種解決方案，並重點為大家解讀阿裡巴巴提出的分散式事務解決方案----GTS。該方案中提到的GTS是全新一代解決微服務問題的分散式事務互聯網中間件。
3 傳統分散式事務解決方案
3.1 基於XA協議的兩階段提交方案
交易中間件與資料庫通過 XA 介面規範，使用兩階段提交來完成一個全局事務， XA 規範的基礎是兩階段提交協議。
第一階段是表決階段，所有參與者都將本事務能否成功的信息反饋發給協調者；第二階段是執行階段，協調者根據所有參與者的反饋，通知所有參與者，步調一致地在所有分支上提交或者回滾。
兩階段提交方案應用非常廣泛，幾乎所有商業OLTP資料庫都支持XA協議。但是兩階段提交方案鎖定資源時間長，對性能影響很大，基本不適合解決微服務事務問題。
3.2 TCC方案
TCC方案在電商、金融領域落地較多。TCC方案其實是兩階段提交的一種改進。其將整個業務邏輯的每個分支顯式的分成了Try、Confirm、Cancel三個操作。Try部分完成業務的準備工作，confirm部分完成業務的提交，cancel部分完成事務的回滾。基本原理如下圖所示。
事務開始時，業務應用會向事務協調器註冊啟動事務。之後業務應用會調用所有服務的try介面，完成一階段準備。之後事務協調器會根據try介面返回情況，決定調用confirm介面或者cancel介面。如果介面調用失敗，會進行重試。
TCC方案讓應用自己定義資料庫操作的粒度，使得降低鎖衝突、提高吞吐量成為可能。 當然TCC方案也有不足之處，集中表現在以下兩個方面：
對應用的侵入性強。業務邏輯的每個分支都需要實現try、confirm、cancel三個操作，應用侵入性較強，改造成本高。
實現難度較大。需要按照網路狀態、系統故障等不同的失敗原因實現不同的回滾策略。為了滿足一致性的要求，confirm和cancel介面必須實現冪等。
上述原因導致TCC方案大多被研發實力較強、有迫切需求的大公司所採用。微服務倡導服務的輕量化、易部署，而TCC方案中很多事務的處理邏輯需要應用自己編碼實現，複雜且開發量大。
3.3 基於消息的最終一致性方案
消息一致性方案是通過消息中間件保證上、下游應用數據操作的一致性。基本思路是將本地操作和發送消息放在一個事務中，保證本地操作和消息發送要麼兩者都成功或者都失敗。下游應用向消息系統訂閱該消息，收到消息後執行相應操作。
消息方案從本質上講是將分散式事務轉換為兩個本地事務，然後依靠下游業務的重試機制達到最終一致性。基於消息的最終一致性方案對應用侵入性也很高，應用需要進行大量業務改造，成本較高。
4 GTS--分散式事務解決方案
GTS是一款分散式事務中間件，由阿裡巴巴中間件部門研發，可以為微服務架構中的分散式事務提供一站式解決方案。
更多GTS資料請訪問研發團隊微博。
4.1 GTS的核心優勢
性能超強
GTS通過大量創新，解決了事務ACID特性與高性能、高可用、低侵入不可兼得的問題。單事務分支的平均響應時間在2ms左右，3台伺服器組成的集群可以支撐3萬TPS以上的分散式事務請求。
應用侵入性極低
GTS對業務低侵入，業務代碼最少只需要添加一行註解（@TxcTransaction）聲明事務即可。業務與事務分離，將微服務從事務中解放出來，微服務關註於業務本身，不再需要考慮反向介面、冪等、回滾策略等複雜問題，極大降低了微服務開發的難度與工作量。
完整解決方案
GTS支持多種主流的服務框架，包括EDAS，Dubbo，Spring Cloud等。
有些情況下，應用需要調用第三方系統的介面，而第三方系統沒有接入GTS。此時需要用到GTS的MT模式。GTS的MT模式可以等價於TCC模式，用戶可以根據自身業務需求自定義每個事務階段的具體行為。MT模式提供了更多的靈活性，可能性，以達到特殊場景下的自定義優化及特殊功能的實現。
容錯能力強
GTS解決了XA事務協調器單點問題，實現真正的高可用，可以保證各種異常情況下的嚴格數據一致。
4.2 GTS的應用場景
GTS可應用在涉及服務調用的多個領域，包括但不限於金融支付、電信、電子商務、快遞物流、廣告營銷、社交、即時通信、手游、視頻、物聯網、車聯網等，詳細介紹可以閱讀 《GTS--阿裡巴巴分散式事務全新解決方案》一文。
4.3 GTS與微服務的集成
GTS包括客戶端（GTS Client）、資源管理器（GTS RM）和事務協調器（GTS Server）三個部分。GTS Client主要用來界定事務邊界，完成事務的發起與結束。GTS RM完成事務分支的創建、提交、回滾等操作。GTS Server主要負責分散式事務的整體推進，事務生命周期的管理。GTS和微服務集成的結構圖如下所示，GTS Client需要和業務應用集成部署，RM與微服務集成部署。
4.4 GTS的輸出形式
GTS目前有三種輸出形式：公有雲輸出、公網輸出、專有雲輸出。
4.4.1 公有雲輸出
這種輸出形式面向阿裡雲用戶。如果用戶的業務系統已經部署到阿裡雲上，可以申請開通公有雲GTS。開通後業務應用即可通過GTS保證服務調用的一致性。這種使用場景下，業務系統和GTS間的網路環境比較理想，達到很好性能。
4.4.2 公網輸出
這種輸出形式面向於非阿裡雲的用戶，使用更加方便、靈活，業務系統只要能連接互聯網即可享受GTS提供的雲服務（與公有雲輸出的差別在於客戶端部署於用戶本地，而不在雲上）。
在正常網路環境下，以包含兩個本地事務的全局事務為例，事務完成時間在20ms左右，50個併發就可以輕鬆實現1000TPS以上分散式事務，對絕大多數業務來說性能是足夠的。在公網環境，網路閃斷很難完全避免，這種情況下GTS仍能保證服務調用的數據一致性。
具體使用樣例使用參見4.7節GTS的工程樣例。
4.4.3 專有雲輸出
這種形式主要面向於已建設了自己專有雲平臺的大用戶，GTS可以直接部署到用戶的專有雲上，為專有雲提供分散式事務服務。目前已經有10多個特大型企業的專有雲使用GTS解決分散式事務難題，性能與穩定性經過了用戶的嚴格檢測。
4.5 GTS的使用方式
GTS對應用的侵入性非常低，使用也很簡單。下麵以訂單存儲應用為例說明。訂單業務應用通過調用訂單服務和庫存服務完成訂單業務，服務開發框架為Dubbo。
4.5.1 訂單業務應用
在業務函數外圍使用@TxcTransaction註解即可開啟分散式事務。Dubbo應用通過隱藏參數將GTS的事務xid傳播到服務端。
4.5.2 服務提供者
更新庫存方法
4.6 GTS的應用情況
GTS目前已經在淘寶、天貓、阿裡影業、淘票票、阿裡媽媽、1688等阿裡各業務系統廣泛使用，經受了16年和17年兩年雙十一海量請求的考驗。某線上業務系統最高流量已達十萬TPS（每秒鐘10萬筆事務）。
GTS在公有雲和專有雲輸出後，已經有了100多個線上用戶，很多用戶通過GTS解決SpringCloud、Dubbo、Edas等服務框架的分散式事務問題。業務領域涉及電力、物流、ETC、煙草、金融、零售、電商、共用出行等十幾個行業，得到用戶的一致認可。
上圖是GTS與SpringCloud集成，應用於某共用出行系統。業務共用出行場景下，通過GTS支撐物聯網系統、訂單系統、支付系統、運維繫統、分析系統等系各統應用的數據一致性，保證海量訂單和數千萬流水的交易。
4.7 GTS的工程樣例
GTS的公有雲樣例可參考阿裡雲網站。在公網環境下提供sample-txc-simple和sample-txc-dubbo兩個樣例工程。
4.7.1 sample-txc-simple樣例
4.7.1.1 樣例業務邏輯
該樣例是GTS的入門sample，案例的業務邏輯是從A賬戶轉賬給B賬戶，其中A和B分別位於兩個MySQL資料庫中，使用GTS事務保證A和B賬戶錢的總數始終不變。
4.7.1.2 樣例搭建方法
1) 準備資料庫環境
安裝MySQL，創建兩個資料庫db1和db2。在db1和db2中分別創建txc_undo_log表（SQL腳本見4.7.3）。在db1庫中創建user_money_a表，在db2庫中創建user_money_b表。
2) 下載樣例
將sample-txc-simple文件下載到本地，樣例中已經包含了GTS的SDK。
3) 修改配置
打開sample-txc-simple/src/main/resources目錄下的txc-client-context.xml，將數據源的url、username、password修改為實際值。
4) 運行樣例
在sample-txc-simple目錄下執行build.sh編譯本工程。編譯完成後執行run.sh。
4.7.2 sample-txc-dubbo 樣例
4.7.2.1 樣例業務邏輯
本案例模擬了用戶下訂單、減庫存的業務邏輯。客戶端（Client）通過調用訂單服務（OrderService）創建訂單，之後通過調用庫存服務（StockService）扣庫存。其中訂單服務讀寫訂單資料庫，庫存服務讀寫庫存資料庫。由 GTS 保證跨服務事務的一致性。
4.7.2.2 樣例搭建方法
1) 準備資料庫環境
安裝MySQL，創建兩個資料庫db1和db2。在db1和db2中分別創建txc_undo_log表。在db1庫中創建orders表，在db2庫中創建stock表。
2) 下載樣例
將樣例文件sample-txc-dubbo下載到本地機器，樣例中已經包含了GTS的SDK。
3) 修改配置
打開sample-txc-dubbo/src/main/resources目錄，將dubbo-order-service.xml、dubbo-stock-service.xml兩個文件中數據源的url、username、password修改為實際值。
4) 運行樣例
編譯程式
在工程根目錄執行 build.sh 命令，編譯工程。編譯後會在 sample-txc-dubbo/client/bin 目錄下生成 order_run.sh、stock_run.sh、client_run.sh 三個運行腳本對應訂單服務、庫存服務以及客戶端。
運行程式
在根目錄執行run.sh，該腳本會依次啟動order_run.sh(訂單服務)、stock_run.sh(庫存服務)和client_run.sh(客戶端程式)。
4.7.2.3 其他說明
樣例使用Multicast註冊中心的聲明方式。如果本機使用無線網路，dubbo服務在綁定地址時有可能獲取ipv6地址，可以通過jvm啟動參數禁用。
方法是配置jvm啟動參數?-Djava.net.preferIPv4Stack=true。
4.7.3 SQL
4.7.3.1 建表 txc_undo_log
CREATE TABLE txc_undo_log (
id bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
gmt_create datetime NOT NULL COMMENT '創建時間',
gmt_modified datetime NOT NULL COMMENT '修改時間',
xid varchar(100) NOT NULL COMMENT '全局事務ID',
branch_id bigint(20) NOT NULL COMMENT '分支事務ID',
rollback_info longblob NOT NULL COMMENT 'LOG',
status int(11) NOT NULL COMMENT '狀態',
server varchar(32) NOT NULL COMMENT '分支所在DB IP',
PRIMARY KEY (id),
KEY?unionkey(xid,branch_id)
) ENGINE=InnoDB AUTO_INCREMENT=211225994 DEFAULT CHARSET=utf8 COMMENT='事務日誌表';
4.7.3.2 建表 user_money_a
CREATE TABLE user_money_a(
id int(11) NOT NULL AUTO_INCREMENT,
money int(11) DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
4.7.3.3 建表 user_money_b
CREATE TABLE user_money_b (
id int(11) NOT NULL AUTO_INCREMENT,
money int(11) DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
4.7.3.4 建表 orders
CREATE TABLE orders (
id bigint(20) NOT NULL AUTO_INCREMENT,
user_id varchar(255) NOT NULL,
product_id int(11) NOT NULL,
number int(11) NOT NULL,
gmt_create timestamp NOT NULL,
PRIMARY KEY (id)
) ENGINE=MyISAM AUTO_INCREMENT=351 DEFAULT CHARSET=utf8
4.7.3.5 建表 stock
CREATE TABLE stock(
product_id?int(11) NOT NULL,
price float NOT NULL,
amount int(11) NOT NULL,
PRIMARY KEY (product_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
想要瞭解更多分散式知識點的，可以關註我一下，我後續也會整理更多關於分散式架構這一塊的知識點分享出來，另外順便給大家推薦一個交流學習群：650385180，裡面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分散式、微服務架構的原理，JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多，以下的課程體系圖也是在群里獲取。
5 總結
GTS已經在阿裡內部廣泛使用，經過了雙十一流量高峰的考驗。內部成熟後，在專有雲和公有雲服務了很多用戶，很多用戶一天事務量在千萬/億級別，解決了業務服務化改造後的分散式事務棘手技術難題。
在整個世界範圍內，既滿足事務ACID特性，又具備高性能、高可用、業務侵入性低的分散式事務中間件在GTS前是不存在的。讓我們一起體驗GTS帶來的巨大變革吧！
