1. 程式人生 > >微服務架構下分散式事務解決方案 —— 阿里GTS

微服務架構下分散式事務解決方案 —— 阿里GTS

原文地址:https://yq.aliyun.com/articles/542020

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傳播到服務端。

@TxcTransaction(timeout = 100010publicvoidBussiness(OrderService orderService, StockService stockService, String userId) { //獲取事務上下文String xid = TxcContext.getCurrentXid(); //通過RpcContext將xid傳到一個服務端RpcContext.getContext().setAttachment( "xid", xid); //執行自己的業務邏輯intproductId =newRandom().nextInt( 100); intproductNum = newRandom().nextInt( 100); OrderDO orderDO = newOrderDO(userId, productId, productNum, newTimestamp( newDate().getTime())); orderService.createOrder(orderDO); //通過RpcContext將xid傳到另一個服務端RpcContext.getContext().setAttachment( "xid",xid); stockService.updateStock(orderDO); }

4.5.2 服務提供者

更新庫存方法

publicintupdateStock(OrderDO orderDO) { //獲取全域性事務ID,並繫結到上下文String xid = RpcContext.getContext().getAttachment( "xid"); TxcContext.bind(xid, null); //執行自己的業務邏輯intret = jdbcTemplate.update( "update stock set amount = amount - ? where product_id = ?"newObject[]{orderDO.getNumber(), orderDO.getProductId()}); TxcContext.unbind();returnret; }

4.6 GTS的應用情況

GTS目前已經在淘寶、天貓、阿里影業、淘票票、阿里媽媽、1688等阿里各業務系統廣泛使用,經受了16年和17年兩年雙十一海量請求的考驗。某線上業務系統最高流量已達十萬TPS(每秒鐘10萬筆事務)。

GTS在公有云和專有云輸出後,已經有了100多個線上使用者,很多使用者通過GTS解決SpringCloud、Dubbo、Edas等服務框架的分散式事務問題。業務領域涉及電力、物流、ETC、菸草、金融、零售、電商、共享出行等十幾個行業,得到使用者的一致認可。

![](https://img .alicdn.com/tfs/TB1QpqNdFGWBuNjy0FbXXb4sXXa- 15301140.png)

上圖是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

5 總結

GTS已經在阿里內部廣泛使用,經過了雙十一流量高峰的考驗。內部成熟後,在專有云和公有云服務了很多使用者,很多使用者一天事務量在千萬/億級別,解決了業務服務化改造後的分散式事務棘手技術難題。

在整個世界範圍內,既滿足事務ACID特性,又具備高效能、高可用、業務侵入性低的分散式事務中介軟體在GTS前是不存在的。讓我們一起體驗GTS帶來的巨大變革吧!