微服務(wù)架構(gòu)下分布式事務(wù)解決方案-阿里GTS

1、 微服務(wù)架構(gòu)下分布式事務(wù)解決方案 阿里GTS 微服務(wù)的發(fā)展微服務(wù)倡導(dǎo)將復(fù)雜的單體應(yīng)用拆分為若干個(gè)功能簡單、松耦合的服務(wù)，這樣可以降低開發(fā)難度、增強(qiáng)擴(kuò)展性、便于敏捷開發(fā)。當(dāng)前被越來越多的開發(fā)者推崇，很多互聯(lián)網(wǎng)行業(yè)巨頭、開源社區(qū)等都開始了微服務(wù)的討論和實(shí)踐。Hailo有160個(gè)不同服務(wù)構(gòu)成，NetFlix有大約600個(gè)服務(wù)。國內(nèi)方面，阿里巴巴、騰訊、360、京東、58同城等很多互聯(lián)網(wǎng)公司都進(jìn)行了微服務(wù)化實(shí)踐。當(dāng)前微服務(wù)的開發(fā)框架也非常多，比較著名的有Dubbo、SpringCloud、thrift 、grpc等。 # 2 微服務(wù)落地存在的問題雖然微服務(wù)現(xiàn)在如火如荼，但對(duì)其實(shí)踐其實(shí)仍處于探索階段。很

2、多中小型互聯(lián)網(wǎng)公司，鑒于經(jīng)驗(yàn)、技術(shù)實(shí)力等問題，微服務(wù)落地比較困難。如著名架構(gòu)師Chris Richardson所言，目前存在的主要困難有如下幾方面：1）單體應(yīng)用拆分為分布式系統(tǒng)后，進(jìn)程間的通訊機(jī)制和故障處理措施變的更加復(fù)雜。2）系統(tǒng)微服務(wù)化后，一個(gè)看似簡單的功能，內(nèi)部可能需要調(diào)用多個(gè)服務(wù)并操作多個(gè)數(shù)據(jù)庫實(shí)現(xiàn)，服務(wù)調(diào)用的分布式事務(wù)問題變的非常突出。3）微服務(wù)數(shù)量眾多，其測試、部署、監(jiān)控等都變的更加困難。隨著RPC框架的成熟，第一個(gè)問題已經(jīng)逐漸得到解決。例如dubbo可以支持多種通訊協(xié)議，springcloud可以非常好的支持restful調(diào)用。對(duì)于第三個(gè)問題，隨著docker、devops技術(shù)的

3、發(fā)展以及各公有云paas平臺(tái)自動(dòng)化運(yùn)維工具的推出，微服務(wù)的測試、部署與運(yùn)維會(huì)變得越來越容易。而對(duì)于第二個(gè)問題，現(xiàn)在還沒有通用方案很好的解決微服務(wù)產(chǎn)生的事務(wù)問題。分布式事務(wù)已經(jīng)成為微服務(wù)落地最大的阻礙，也是最具挑戰(zhàn)性的一個(gè)技術(shù)難題。為此，本文將深入和大家探討微服務(wù)架構(gòu)下，分布式事務(wù)的各種解決方案，并重點(diǎn)為大家解讀阿里巴巴提出的分布式事務(wù)解決方案-GTS。該方案中提到的GTS是全新一代解決微服務(wù)問題的分布式事務(wù)互聯(lián)網(wǎng)中間件。傳統(tǒng)分布式事務(wù)解決方案基于XA協(xié)議的兩階段提交方案交易中間件與數(shù)據(jù)庫通過 XA 接口規(guī)范，使用兩階段提交來完成一個(gè)全局事務(wù)， XA 規(guī)范的基礎(chǔ)是兩階段提交協(xié)議。第一階段是表決階

4、段，所有參與者都將本事務(wù)能否成功的信息反饋發(fā)給協(xié)調(diào)者；第二階段是執(zhí)行階段，協(xié)調(diào)者根據(jù)所有參與者的反饋，通知所有參與者，步調(diào)一致地在所有分支上提交或者回滾。兩階段提交方案應(yīng)用非常廣泛，幾乎所有商業(yè)OLTP數(shù)據(jù)庫都支持XA協(xié)議。但是兩階段提交方案鎖定資源時(shí)間長，對(duì)性能影響很大，基本不適合解決微服務(wù)事務(wù)問題。TCC方案TCC方案在電商、金融領(lǐng)域落地較多。TCC方案其實(shí)是兩階段提交的一種改進(jìn)。其將整個(gè)業(yè)務(wù)邏輯的每個(gè)分支顯式的分成了Try、Confirm、Cancel三個(gè)操作。Try部分完成業(yè)務(wù)的準(zhǔn)備工作，confirm部分完成業(yè)務(wù)的提交，cancel部分完成事務(wù)的回滾。基本原理如下圖所示。事務(wù)開始時(shí)，

5、業(yè)務(wù)應(yīng)用會(huì)向事務(wù)協(xié)調(diào)器注冊(cè)啟動(dòng)事務(wù)。之后業(yè)務(wù)應(yīng)用會(huì)調(diào)用所有服務(wù)的try接口，完成一階段準(zhǔn)備。之后事務(wù)協(xié)調(diào)器會(huì)根據(jù)try接口返回情況，決定調(diào)用confirm接口或者cancel接口。如果接口調(diào)用失敗，會(huì)進(jìn)行重試。TCC方案讓應(yīng)用自己定義數(shù)據(jù)庫操作的粒度，使得降低鎖沖突、提高吞吐量成為可能。當(dāng)然TCC方案也有不足之處，集中表現(xiàn)在以下兩個(gè)方面：對(duì)應(yīng)用的侵入性強(qiáng)。業(yè)務(wù)邏輯的每個(gè)分支都需要實(shí)現(xiàn)try、confirm、cancel三個(gè)操作，應(yīng)用侵入性較強(qiáng)，改造成本高。實(shí)現(xiàn)難度較大。需要按照網(wǎng)絡(luò)狀態(tài)、系統(tǒng)故障等不同的失敗原因?qū)崿F(xiàn)不同的回滾策略。為了滿足一致性的要求，confirm和cancel接口必須實(shí)現(xiàn)冪

6、等。上述原因?qū)е耇CC方案大多被研發(fā)實(shí)力較強(qiáng)、有迫切需求的大公司所采用。微服務(wù)倡導(dǎo)服務(wù)的輕量化、易部署，而TCC方案中很多事務(wù)的處理邏輯需要應(yīng)用自己編碼實(shí)現(xiàn)，復(fù)雜且開發(fā)量大?；谙⒌淖罱K一致性方案消息一致性方案是通過消息中間件保證上、下游應(yīng)用數(shù)據(jù)操作的一致性。基本思路是將本地操作和發(fā)送消息放在一個(gè)事務(wù)中，保證本地操作和消息發(fā)送要么兩者都成功或者都失敗。下游應(yīng)用向消息系統(tǒng)訂閱該消息，收到消息后執(zhí)行相應(yīng)操作。消息方案從本質(zhì)上講是將分布式事務(wù)轉(zhuǎn)換為兩個(gè)本地事務(wù)，然后依靠下游業(yè)務(wù)的重試機(jī)制達(dá)到最終一致性?；谙⒌淖罱K一致性方案對(duì)應(yīng)用侵入性也很高，應(yīng)用需要進(jìn)行大量業(yè)務(wù)改造，成本較高。GTS-分布式事

7、務(wù)解決方案GTS是一款分布式事務(wù)中間件，由阿里巴巴中間件部門研發(fā)，可以為微服務(wù)架構(gòu)中的分布式事務(wù)提供一站式解決方案。更多GTS資料請(qǐng)?jiān)L問研發(fā)團(tuán)隊(duì)微博。GTS的核心優(yōu)勢性能超強(qiáng)GTS通過大量創(chuàng)新，解決了事務(wù)ACID特性與高性能、高可用、低侵入不可兼得的問題。單事務(wù)分支的平均響應(yīng)時(shí)間在2ms左右，3臺(tái)服務(wù)器組成的集群可以支撐3萬TPS以上的分布式事務(wù)請(qǐng)求。應(yīng)用侵入性極低GTS對(duì)業(yè)務(wù)低侵入，業(yè)務(wù)代碼最少只需要添加一行注解（TxcTransaction）聲明事務(wù)即可。業(yè)務(wù)與事務(wù)分離，將微服務(wù)從事務(wù)中解放出來，微服務(wù)關(guān)注于業(yè)務(wù)本身，不再需要考慮反向接口、冪等、回滾策略等復(fù)雜問題，極大降低了微服務(wù)開發(fā)的難

8、度與工作量。完整解決方案GTS支持多種主流的服務(wù)框架，包括EDAS，Dubbo，Spring Cloud等。有些情況下，應(yīng)用需要調(diào)用第三方系統(tǒng)的接口，而第三方系統(tǒng)沒有接入GTS。此時(shí)需要用到GTS的MT模式。GTS的MT模式可以等價(jià)于TCC模式，用戶可以根據(jù)自身業(yè)務(wù)需求自定義每個(gè)事務(wù)階段的具體行為。MT模式提供了更多的靈活性，可能性，以達(dá)到特殊場景下的自定義優(yōu)化及特殊功能的實(shí)現(xiàn)。容錯(cuò)能力強(qiáng)GTS解決了XA事務(wù)協(xié)調(diào)器單點(diǎn)問題，典型配置是三臺(tái)服務(wù)器組成的事務(wù)協(xié)調(diào)器集群，實(shí)現(xiàn)服務(wù)高可用，可以保證異常情況（比如網(wǎng)絡(luò)斷開、服務(wù)器宕機(jī)、硬盤損壞不可恢復(fù)等）下的數(shù)據(jù)嚴(yán)格一致。在要求更高可用性的場景，比如電商

9、業(yè)務(wù)雙11大促，常用配置是六臺(tái)服務(wù)器組成的主、備集群（各三臺(tái)）。當(dāng)主集群有服務(wù)器不可用，自動(dòng)切換到備集群提供服務(wù)。GTS的應(yīng)用場景GTS可應(yīng)用在涉及服務(wù)調(diào)用的多個(gè)領(lǐng)域，包括但不限于金融支付、電信、電子商務(wù)、快遞物流、廣告營銷、社交、即時(shí)通信、手游、視頻、物聯(lián)網(wǎng)、車聯(lián)網(wǎng)等，詳細(xì)介紹可以閱讀 GTS-阿里巴巴分布式事務(wù)全新解決方案一文。對(duì)于GTS已經(jīng)支持的數(shù)據(jù)源（MySQL，DRDS，RDS，PetaData，Oracle，Oceanbase等）可以采用AT模式（自動(dòng)模式，加個(gè)注解界定事務(wù)范圍即可），對(duì)于目前不支持的數(shù)據(jù)源（HBase，Redis，DB2等）可以采用MT模式（手動(dòng)模式，等價(jià)于TCC

10、，需要手工實(shí)現(xiàn)接口）。具體使用方式參考官網(wǎng)樣例。GTS與微服務(wù)的集成GTS包括客戶端（GTSClient）、資源管理器（GTS RM）和事務(wù)協(xié)調(diào)器（GTS Server）三個(gè)部分。GTS Client主要用來界定事務(wù)邊界，完成事務(wù)的發(fā)起與結(jié)束。GTS RM完成事務(wù)分支的創(chuàng)建、提交、回滾等操作。GTS Server主要負(fù)責(zé)分布式事務(wù)的整體推進(jìn)，事務(wù)生命周期的管理。GTS和微服務(wù)集成的結(jié)構(gòu)圖如下所示，GTS Client需要和業(yè)務(wù)應(yīng)用集成部署，RM與微服務(wù)集成部署。GTS的輸出形式GTS目前有三種輸出形式：公有云輸出、公網(wǎng)輸出、專有云輸出。公有云輸出這種輸出形式面向阿里云用戶。如果用戶的業(yè)務(wù)系統(tǒng)已

11、經(jīng)部署到阿里云上，可以申請(qǐng)開通公有云GTS。開通后業(yè)務(wù)應(yīng)用即可通過GTS保證服務(wù)調(diào)用的一致性。這種使用場景下，業(yè)務(wù)系統(tǒng)和GTS間的網(wǎng)絡(luò)環(huán)境比較理想，達(dá)到很好性能。公網(wǎng)輸出這種輸出形式面向于非阿里云的用戶，使用更加方便、靈活，業(yè)務(wù)系統(tǒng)只要能連接互聯(lián)網(wǎng)即可享受GTS提供的云服務(wù)（與公有云輸出的差別在于客戶端部署于用戶本地，而不在云上）。在正常網(wǎng)絡(luò)環(huán)境下，以包含兩個(gè)本地事務(wù)的全局事務(wù)為例，事務(wù)完成時(shí)間在20ms左右，50個(gè)并發(fā)就可以輕松實(shí)現(xiàn)1000TPS以上分布式事務(wù)，對(duì)絕大多數(shù)業(yè)務(wù)來說性能是足夠的。在公網(wǎng)環(huán)境，網(wǎng)絡(luò)閃斷很難完全避免，這種情況下GTS仍能保證服務(wù)調(diào)用的數(shù)據(jù)一致性。具體使用樣例使用參見

12、4.7節(jié)GTS的工程樣例。專有云輸出這種形式主要面向于已建設(shè)了自己專有云平臺(tái)的大用戶，GTS可以直接部署到用戶的專有云上，為專有云提供分布式事務(wù)服務(wù)。目前已經(jīng)有10多個(gè)特大型企業(yè)的專有云使用GTS解決分布式事務(wù)難題，性能與穩(wěn)定性經(jīng)過了用戶的嚴(yán)格檢測。GTS的使用方式GTS使用請(qǐng)參考官網(wǎng)。GTS對(duì)應(yīng)用的侵入性非常低，使用也很簡單。下面以訂單存儲(chǔ)應(yīng)用為例說明。訂單業(yè)務(wù)應(yīng)用通過調(diào)用訂單服務(wù)和庫存服務(wù)完成訂單業(yè)務(wù)，服務(wù)開發(fā)框架為Dubbo。 #4.5.1 訂單業(yè)務(wù)應(yīng)用在業(yè)務(wù)函數(shù)外圍使用TxcTransaction注解即可開啟分布式事務(wù)。Dubbo應(yīng)用通過隱藏參數(shù)將GTS的事務(wù)xid傳播到服務(wù)端。Txc

13、Transaction(timeout =1000 * 10)public void Bussiness(OrderServiceorderService, StockService stockService, String userId) /獲取事務(wù)上下文String xid = TxcContext.getCurrentXid(); /通過RpcContext將xid傳到一個(gè)服務(wù)端RpcContext.getContext().setAttachment(xid, xid); /執(zhí)行自己的業(yè)務(wù)邏輯 intproductId = new Random().nextInt(100); intp

14、roductNum = new Random().nextInt(100);OrderDO orderDO = new OrderDO(userId, productId, productNum, newTimestamp(new Date().getTime();orderService.createOrder(orderDO); /通過RpcContext將xid傳到另一個(gè)服務(wù)端RpcContext.getContext().setAttachment(xid,xid);stockService.updateStock(orderDO);服務(wù)提供者更新庫存方法public intupdat

15、eStock(OrderDO orderDO) /獲取全局事務(wù)ID，并綁定到上下文String xid = RpcContext.getContext().getAttachment(xid);TxcContext.bind(xid,null); /執(zhí)行自己的業(yè)務(wù)邏輯 intret = jdbcTemplate.update(update stock set amount = amount - ? whereproduct_id = ?,new ObjectorderDO.getNumber(),orderDO.getProductId();TxcContext.unbind();return

16、 ret;GTS的應(yīng)用情況GTS目前已經(jīng)在淘寶、天貓、阿里影業(yè)、淘票票、阿里媽媽、1688等阿里各業(yè)務(wù)系統(tǒng)廣泛使用，經(jīng)受了16年和17年兩年雙十一海量請(qǐng)求的考驗(yàn)。某線上業(yè)務(wù)系統(tǒng)最高流量已達(dá)十萬TPS（每秒鐘10萬筆事務(wù)）。GTS在公有云和專有云輸出后，已經(jīng)有了100多個(gè)線上用戶，很多用戶通過GTS解決SpringCloud、Dubbo、Edas等服務(wù)框架的分布式事務(wù)問題。業(yè)務(wù)領(lǐng)域涉及電力、物流、ETC、煙草、金融、零售、電商、共享出行等十幾個(gè)行業(yè)，得到用戶的一致好評(píng)。上圖是GTS與SpringCloud集成，應(yīng)用于某共享出行系統(tǒng)。業(yè)務(wù)共享出行場景下，通過GTS支撐物聯(lián)網(wǎng)系統(tǒng)、訂單系統(tǒng)、支付系統(tǒng)

17、、運(yùn)維系統(tǒng)、分析系統(tǒng)等系各統(tǒng)應(yīng)用的數(shù)據(jù)一致性，保證海量訂單和數(shù)千萬流水的交易。GTS的工程樣例GTS的公有云樣例可參考阿里云網(wǎng)站。在公網(wǎng)環(huán)境下提供sample-txc-simple和sample-txc-dubbo兩個(gè)樣例工程。sample-txc-simple樣例1 樣例業(yè)務(wù)邏輯該樣例是GTS的入門sample，案例的業(yè)務(wù)邏輯是從A賬戶轉(zhuǎn)賬給B賬戶，其中A和B分別位于兩個(gè)MySQL數(shù)據(jù)庫中，使用GTS事務(wù)保證A和B賬戶錢的總數(shù)始終不變。 #4.7.1.2 樣例搭建方法 1) 準(zhǔn)備數(shù)據(jù)庫環(huán)境安裝MySQL，創(chuàng)建兩個(gè)數(shù)據(jù)庫db1和db2。在db1和db2中分別創(chuàng)建txc_undo_log表（SQ

18、L腳本見4.7.3）。在db1庫中創(chuàng)建user_money_a表，在db2庫中創(chuàng)建user_money_b表。2.下載樣例將sample-txc-simple文件下載到本地，樣例中已經(jīng)包含了GTS的SDK。3.修改配置打開sample-txc-simple/src/main/resources目錄下的txc-client-context.xml，將數(shù)據(jù)源的url、username、password修改為實(shí)際值。4.運(yùn)行樣例在sample-txc-simple目錄下執(zhí)行build.sh編譯本工程。編譯完成后執(zhí)行run.sh。sample-txc-dubbo 樣例1.樣例業(yè)務(wù)邏輯本案例模擬了用戶下

19、訂單、減庫存的業(yè)務(wù)邏輯?？蛻舳耍–lient）通過調(diào)用訂單服務(wù)（OrderService）創(chuàng)建訂單，之后通過調(diào)用庫存服務(wù)（StockService）扣庫存。其中訂單服務(wù)讀寫訂單數(shù)據(jù)庫，庫存服務(wù)讀寫庫存數(shù)據(jù)庫。由 GTS 保證跨服務(wù)事務(wù)的一致性。準(zhǔn)備數(shù)據(jù)庫環(huán)境安裝MySQL，創(chuàng)建兩個(gè)數(shù)據(jù)庫db1和db2。在db1和db2中分別創(chuàng)建txc_undo_log表。在db1庫中創(chuàng)建orders表，在db2庫中創(chuàng)建stock表。2. 下載樣例將樣例文件sample-txc-dubbo下載到本地機(jī)器，樣例中已經(jīng)包含了GTS的SDK。3. 修改配置打開sample-txc-dubbo/src/main/res

20、ources目錄，將dubbo-order-service.xml、dubbo-stock-service.xml兩個(gè)文件中數(shù)據(jù)源的url、username、password修改為實(shí)際值。4. 運(yùn)行樣例a. 編譯程序在工程根目錄執(zhí)行 build.sh 命令，編譯工程。編譯后會(huì)在 sample-txc-dubbo/client/bin 目錄下生成order_run.sh、stock_run.sh、client_run.sh 三個(gè)運(yùn)行腳本對(duì)應(yīng)訂單服務(wù)、庫存服務(wù)以及客戶端。b.運(yùn)行程序在根目錄執(zhí)行run.sh，該腳本會(huì)依次啟動(dòng)order_run.sh(訂單服務(wù))、stock_run.sh(庫存服務(wù))

21、和client_run.sh(客戶端程序)。其他說明樣例使用Multicast注冊(cè)中心的聲明方式。如果本機(jī)使用無線網(wǎng)絡(luò)，dubbo服務(wù)在綁定地址時(shí)有可能獲取ipv6地址，可以通過jvm啟動(dòng)參數(shù)禁用。方法是配置jvm啟動(dòng)參數(shù) -D.preferIPv4Stack=true。建表 txc_undo_log CREATE TABLE txc_undo_log (id bigint(20)NOT NULL AUTO_INCREMENT COMMENT 主鍵,gmt_createdatetime NOT NULL COMMENT 創(chuàng)建時(shí)間,gmt_modifieddatetime NOT NULL CO

22、MMENT 修改時(shí)間,xid varchar(100)NOT NULL COMMENT 全局事務(wù)ID,branch_idbigint(20) NOT NULL COMMENT 分支事務(wù)ID,rollback_infolongblob NOT NULL COMMENT LOG,status int(11)NOT NULL COMMENT 狀態(tài),servervarchar(32) NOT NULL COMMENT 分支所在DB IP,PRIMARY KEY (id),KEY unionkey (xid,branch_id) ENGINE=InnoDB AUTO_INCREMENT=211225994DEFAULT CHARSET=utf8 COMMENT=事務(wù)日志表;4.7.3.2 建表 user_money_aCREATE TABLE user_money_a (id int(11) NOTNULL AUTO_INCREMENT,money int(11)DEFAULT NULL,PRIMARY KEY (id) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULTCHARSET=utf8;建表 user_money_bCREATE TABLE user_money_b (id int(11) NOTNULL