一行代码，保障分布式事务一致性—GTS:微服务架构下分布式事务解决方案
微服務倡導將復雜的單體應用拆分為若干個功能簡單的、松耦合的服務，這樣可以降低開發(fā)難度、增強擴展性、便于敏捷開發(fā)。概念2012年提出迅速火遍全球，被越來越多的開發(fā)者推崇，很多互聯(lián)網(wǎng)行業(yè)巨頭、開源社區(qū)等都開始了微服務的討論和實踐。根據(jù)Netflix云架構總監(jiān)Adrian Cockcrof，Hailo有160個不同服務構成，NetFlix有大約600個服務。國內方面，阿里巴巴、騰訊、360、京東、58等很多互聯(lián)網(wǎng)公司都進行了微服務化改造。當前微服務的開發(fā)框架也有幾十種之多，比較著名的有Dubbo、SpringCloud、thrift 、grpc等。
1 分布式事務解決方案及其弊端
雖然微服務現(xiàn)在如火如荼，但對其實踐其實仍處于初級階段。即使互聯(lián)網(wǎng)巨頭的實踐也大多是試驗層面，鮮有核心業(yè)務系統(tǒng)微服務化的案例。而對于很多中小型互聯(lián)網(wǎng)公司，鑒于經(jīng)驗、技術實力等問題，微服務落地更加困難。世界著名的軟件架構大師Chris Richardson在《Introduction to Microservices》一文中也直接了當?shù)闹赋隽宋⒎债斍按嬖诘膯栴}：
- 從單體應用拆分為分布式系統(tǒng)帶來的復雜性。開發(fā)者需要選擇或實現(xiàn)基于消息或者RPC模式的進程間通訊機制，另外開發(fā)者也要寫額外的代碼去處理對于目的服務請求可能存在的請求緩慢或者請求不可用導致的局部故障問題。
- 單體應用拆分所導致的數(shù)據(jù)庫架構的拆分。應用更新多個業(yè)務記錄非常常見，單體應用實現(xiàn)也比較簡單。然而在微服務架構下，應用不得不調用多個微服務去更新多個數(shù)據(jù)庫。一般很難使用分布式事務解決，不僅僅是因為CAP理論，還因為一些流行的NoSQL數(shù)據(jù)庫和Message Queue系統(tǒng)壓根也不支持（攤手）。最后還得繞回最終一致性方案，這個方案對開發(fā)者來講也是非常有挑戰(zhàn)性。
- 測試微服務架構的應用也是更加復雜的。因為服務之間可能有諸多調用，測試一個服務將不得不啟動其他服務。
- 部署、運維一個微服務架構的應用變的更加困難。微服務一般由大量的服務組成，每個服務還有多個運行實例！將會有更多變化的部分需要去配置、部署、擴展、監(jiān)控。此外還需要實現(xiàn)一個服務發(fā)現(xiàn)機制讓其他服務找到它需要通信的服務的地址。
對于第一和第三個問題，筆者認為隨著RPC框架的成熟，已經(jīng)逐漸得到解決。例如dubbo可以支持rmi、hessian、http、webservice、thrift、redis等多種通訊協(xié)議，springcloud可以非常好的支持restful調用。spring體系下應用的測試也變的越來越簡單。對于第四個問題，隨著docker、devops技術的發(fā)展以及各公有云paas平臺自動化運維工具的推出，微服務的部署與運維會變得越來越容易。
而對于Chris Richardson提到的第二個問題，現(xiàn)在還沒有通用方案很好的解決微服務產(chǎn)生的事務問題。分布式事務已經(jīng)成為微服務落地最大的阻礙，也是最具挑戰(zhàn)性的一個技術難題。 為此，本文將深入和大家探討微服務架構下，分布式事務的各種解決方案，并重點為大家解讀阿里巴巴提出的分布式事務解決方案----GTS。該方案中提到的GTS是目前業(yè)界第一款，也是唯一的一款通用的解決微服務分布式事務問題的中間件，而且可以保證數(shù)據(jù)的強一致性。
2 SOA分布式事務解決方案
在微服務之前，信息系統(tǒng)中的服務大多基于SOA的理念設計（SOA與微服務的區(qū)別），服務相對比較重。對于服務調用產(chǎn)生的分布式事務問題，在SOA時代，就有一些解決方案。比較著名的有基于XA協(xié)議的方案、TCC方案、消息最終一致性方案。
2.1基于XA協(xié)議的方案
該方案最早由oracle提出用于解決跨數(shù)據(jù)訪問的事務問題，是一種強一致性的解決方案，由事務協(xié)調器和本地資源管理器共同完成。事務協(xié)調器和資源管理器間通過XA協(xié)議進行通信。XA協(xié)議實現(xiàn)的原理入下圖所示，共分為兩個階段，也就是我們常說的兩階段協(xié)議。
兩階段方案在解決數(shù)據(jù)庫分布式事務問題方面應用非常廣泛，oracle、Mysql等主流關系數(shù)據(jù)庫均支持XA協(xié)議，而且ocenbase、DCDB等著名的分布式數(shù)據(jù)庫也都基于兩階段協(xié)議。在解決服務事務問題上，其實 XA協(xié)議不是只能作用于單個服務內部的多資源場景，跨服務的多資源場景也是可以的，只不過需要額外的事務傳遞機制。但其都有致命的缺點，性能不理想。由于需要等到各分支事務都就緒后全局事務才開始提交，所以每個事務鎖定數(shù)據(jù)的時間較長，XA方案因此很難滿足高并發(fā)場景。而且在解決微服務問題時XA方案的性能問題將會被放大。因為應用在訪問服務的調用方式、網(wǎng)絡環(huán)境等要比訪問數(shù)據(jù)庫復雜的多。例如，應用和其訪問的數(shù)據(jù)庫通常在一個局域網(wǎng)中，而其通過rpc調用的服務則可能屬于另一個網(wǎng)絡或者在公網(wǎng)上，其時延更長、出故障的概率更高。這將導致數(shù)據(jù)鎖定時間和系統(tǒng)并發(fā)度進一步降低。所以XA方案基本不適合解決微服務的事務問題。
2.2TCC方案
TCC方案應用是目前呼聲最高，也是落地最多的一個方案。當前也有一些開源的TCC框架實現(xiàn)，如TCC-Transaction、ByteTCC。TCC方案其實是兩階段方案的一種改進，其將本地資源管理器的功能融入到了業(yè)務實現(xiàn)中。其將整個業(yè)務邏輯顯示的分成了Try、Confirm、Cancel三部分。try部分完成業(yè)務的準備工作，confirm部分完成業(yè)務的提交，cancel部分完成事務的回滾。基本原理如下圖所示。
事務開始時，業(yè)務應用會向事務協(xié)調器注冊啟動事務。之后業(yè)務應用會調用所有服務的try接口，相當于XA的第一階段。如果有任何一個服務的try接口調用失敗會向事務協(xié)調器發(fā)送事務回滾請求，否則發(fā)送事務提交請求。事務協(xié)調器收到事務回滾請求后會依次調用事務的confirm接口，否則調用cancel接口回滾，這相當于XA的第二階段。如果第二階段接口調用失敗，會進行重試。
TCC方案通過通過三個接口很好的規(guī)避了長時間數(shù)據(jù)加鎖的問題，業(yè)務表在每個接口調用完畢即可釋放，這很大程度上提高了業(yè)務的并發(fā)度，這也是TCC方案最大的優(yōu)勢。所以在SOA時期，TCC方案被很多金融、電商的業(yè)務系統(tǒng)大量使用。
當然TCC方案也有不足之處，集中表現(xiàn)在以下兩個方面：
- 開發(fā)工作量大。它將部分資源管理器的功能融入到每個服務的開發(fā)中，導致服務的每個接口都需要實現(xiàn)try、confirm、cancle，還需要實現(xiàn)事務協(xié)調器，開發(fā)量不只翻了一倍。
- 實現(xiàn)難度大。系統(tǒng)需要記錄每個應用的服務調用鏈路。我前面講過rpc調用情況比較復雜，由于網(wǎng)絡狀況、系統(tǒng)故障等調用失敗被視為常態(tài)，必須按照不同的失敗原因實現(xiàn)不同策略的回滾。為了滿足一致性的要求，二階段不管調用confirm還是cancle都必須調用成功，如果一次調用不成功，事務協(xié)調器必須嘗試重試。這就要求confirm和cancle接口必須實現(xiàn)冪等。
上述原因導致TCC方案大多是被研發(fā)實力較強、有迫切需求的大公司所采用。其將分布式事務變成一種所謂的“貴族技術”，中小型企業(yè)由于人員有限、技術實力薄弱，很難落地。而且筆者認為微服務倡導的是服務的輕量化、易部署，而TCC方案將很多事務的處理功能融入到業(yè)務中，對業(yè)務侵入性太高，導致服務邏輯復雜，比較適合比較重的服務。
2.3 消息事務一致性方案
消息一致性方案是通過消息中間件保證上、下游應用數(shù)據(jù)操作的一致性?；舅悸肥菍⒈镜夭僮骱桶l(fā)送消息放在一個事務中，保證本地操作和消息發(fā)送要么兩者都成功或者都失敗。下游應用向消息系統(tǒng)訂閱該消息，收到消息后執(zhí)行相應操作。
以下單業(yè)務為例進行說明，下單基本流程是先存儲訂單信息，然后扣相應商品的庫存，兩個操作必須在一個事務中。如下圖，業(yè)務應用首先調用訂單服務，訂單存儲成功后，訂單服務會通過消息處理服務投遞訂單消息到MQ。庫存服務從MQ收到消息后進行扣庫存操作，如果執(zhí)行成功會向消息處理服務發(fā)送通知。消息處理服務會實時監(jiān)測訂單消息是否超時，如果超時會重新投遞到MQ中，以驅動庫存服務進行扣庫存操作。如果扣庫存操作執(zhí)行失敗后，庫存服務后續(xù)還會從MQ接收到相同的訂單消息，需要多次重復執(zhí)行，直到成功或者進行人工干預。庫存服務需要實現(xiàn)冪等。
消息方案從本質上講是將分布式事務轉換為兩個本地事務，然后依靠下游業(yè)務的重試機制達到最終一致性。相對TCC方案來講，消息方案技術難度相對低，落地較容易,如果對一致性不敏感的應用也是一個不錯的選擇。美國著名電商e-bay以及國內的蘑菇街都做過嘗試。消息一致性方案的不足之處是其對應用侵入性較高，應用需要基于消息接口進行改造，而且需要建設專門的消息系統(tǒng)，成本較高。
3 GTS--微服務分布式事務解決方案
GTS是一款分布式事務中間件，由阿里巴巴中間件部門研發(fā)，可以為微服務架構中的分布式事務提供一站式解決方案。GTS方案的基本思路是：將分布式事務與具體業(yè)務分離，在平臺層面開發(fā)通用的事務中間件GTS，由事務中間件協(xié)調各服務的調用一致性，負責分布式事務的生命周期管理、服務調用失敗的自動回滾。
GTS方案有三方面的優(yōu)勢，首先它將微服務從分布式事務中解放出來，微服務的實現(xiàn)不需要再考慮反向接口、冪等、回滾策略等復雜問題，只需要業(yè)務自己的接口即可，大大降低了微服務開發(fā)的難度與工作量。將分布式事務從所謂的“貴族技術”變?yōu)榇蠹叶寄苁褂玫摹捌矫窦夹g ”，有利于微服務的落地與推廣。 其次，GTS對業(yè)務代碼幾乎沒有侵入，只需要通過注解@TxcTransaction界定事務邊界即可，微服務接入GTS的成本非常低。第三，性能方面GTS也非常優(yōu)秀，是傳統(tǒng)XA方案的8～10倍。
3.1 基本原理
GTS中間件主要包括客戶端（GTS Client）、資源管理器（GTS RM）和事務協(xié)調器（GTS Server）三部分。GTS Client主要完成事務的發(fā)起與結束。GTS RM完成分支事務的開啟、提交、回滾等操作。GTS Server主要負責分布式事務的整體推進，事務生命周期的管理。
GTS和微服務集成后的結構圖如上圖所示。GTS Client需要和業(yè)務應用集成部署，RM與微服務集成部署。當業(yè)務應用發(fā)起服務調用時，首先會通過GTS Client向TC注冊新的全局事務。之后GTS Server會給業(yè)務應用返回全局唯一的事務編號xid。業(yè)務應用調用服務時會將xid傳播到服務端。微服務在執(zhí)行數(shù)據(jù)庫操作時會通過GTS RM向GTS Server注冊分支事務，并完成分支事務的提交。如果A、B、C三個服務均調用成功，GTS Client會通知GTS Server結束事務。假設C調用失敗，GTS Client會要求GTS Server發(fā)起全局回滾。然后由各自的RM完成回滾工作。
3.2 GTS的關鍵機制
- 可用性
GTS服務也是由多個節(jié)點構成的高可用集群，可以彈性擴張，可以接收高并發(fā)的客戶端請求。可以支持跨機房部署，支持同城容災和兩地三中心容災。任何異常情況下的保證高可用。 - 自動回滾策略
當有微服務調用失敗時，GTS服務可以驅動各微服務的RM替微服務完成調用的回滾工作。舉個轉賬的例子，轉賬應用通常調用存款服務和扣款服務完成轉賬功能。先調用扣款服務從A賬戶扣掉100元，然后調用存款服務向B賬戶中存款100元。如果轉賬應用在調用存款服務失敗時，GTS Client會要求GTS Server發(fā)起回滾，然后通知扣款服務對應的RM，RM會直接在A賬戶增加100元。然后GTS Server通知轉賬應用回滾成功。從這個過程可以看到，在調用服務失敗后，其實微服務不用做任何工作，而是由RM替微服務執(zhí)行反向操作，也很自然的避免了冪等操作。TCC方案中，事務協(xié)調器需要顯示調用微服務的反向向接口，如果反向接口調用失敗還需要不斷重試。 - 可擴展性
有些情況下，應用需要調用第三方系統(tǒng)的接口或者不是基于GTS開發(fā)的微服，GTS無法接入到這些服務的實現(xiàn)中。此時需要用到GTS的MT模式。GTS的MT模式可以等價于TCC模式。
MT模式預留了一階段和二階段的提交接口，允許應用介入GTS的兩階段提交。應用將提交及回滾接口注冊后，GTS會自動完成調用。
- 隔離級別
GTS目前支持讀未提交和讀已提交兩種隔離級別。
3.3 GTS與其他方案的對比
1. 和XA方案對比
相比XA方案，GTS更加通用，可以對上層業(yè)務屏蔽底層實現(xiàn)細節(jié)，對業(yè)務幾乎沒有侵入。這一點在微服務時代特別有用，微服務面對的是大量的中小企業(yè)，甚至是個人開發(fā)者，業(yè)務訴求不盡相同，普適、標準的分布式事務產(chǎn)品是非常有必要的，可以讓開發(fā)者從底層技術細節(jié)中脫離出來，更專注于業(yè)務邏輯的實現(xiàn)，從而獲得更高效、快速的業(yè)務發(fā)展。兩個方案都可以遵循ACID特性，都可以實現(xiàn)事務的強一致性。GTS性能要比XA方案高。
2. 和TCC方案對比
GTS方案和TCC方案最大的區(qū)別是實現(xiàn)分布式事務實現(xiàn)的層面不同。TCC方案選擇從業(yè)務層面實現(xiàn)分布式事務功能，將事務的回滾、重試等功能在微服務中實現(xiàn)。而GTS選擇從中間件層面解決分布式事務問題，對微服務幾乎無侵入。兩個方案都可以獲得比較好的性能，都可以保證調用的一致性。TCC方案實現(xiàn)難度比較大，適合技術實力較強的團隊。GTS方案可以實現(xiàn)事務的強一致性，另外采用GTS方案后微服務會更簡單，耦合性也非常低。TCC主要提供開發(fā)框架，實現(xiàn)需要依賴業(yè)務方，而GTS是完整的分布式事務解決方案，所有分布式事務問題不需要業(yè)務方介入。
3. 和消息最終一致性對比
相比消息方案，GTS方案侵入性非常低，可以實現(xiàn)數(shù)據(jù)的強一致性。采用消息方案，上下游服務之間有很強的耦合性，測試、部署都不是很方便，需要單獨建設消息系統(tǒng)。不過消息方案實現(xiàn)相對簡單，如果對一致性要求不高，也是一個選擇。
3.4 GTS的應用場景
GTS可應用在涉及服務調用的多個領域，包括但不限于金融支付、電信、電子商務、快遞物流、廣告營銷、社交、即時通信、手游、視頻、物聯(lián)網(wǎng)、車聯(lián)網(wǎng)等，詳細介紹可以閱讀 《GTS--阿里巴巴分布式事務全新解決方案》一文。
3.5 GTS的輸出形式
GTS目前有三種輸出形式：通過公有云平臺輸出、通過公網(wǎng)云服務輸出、通過專有云平臺輸出。
- 1 通過公有云平臺輸出
這種輸出形式主要面向阿里云用戶。如果用戶的業(yè)務系統(tǒng)已經(jīng)部署到阿里云上，可以直接申請開通公有云GTS。開通后業(yè)務應用即可通過GTS保證服務調用的一致行。這種使用場景下，業(yè)務系統(tǒng)和GTS間的網(wǎng)絡環(huán)境比較理想，GTS能提供更低的響應時間。
公有云提供了比較豐富的與dubbo、SpringCloud等集成的樣例，可以點擊查看。
- 2 通過公網(wǎng)云服務輸出
這種輸出形式主要面向于非阿里云的用戶，使用更加方便、靈活，業(yè)務系統(tǒng)只要能連接互聯(lián)網(wǎng)即可享受GTS提供的云服務。在網(wǎng)絡抖動和閃斷的情況下，GTS仍能保證服務調用的一致性。在正常網(wǎng)絡環(huán)境下，以包含兩個本地事務的全局事務為例，事務完成時間在20ms左右，業(yè)務可以輕松實現(xiàn)1000TPS以上分布式事務，可以滿足絕大多數(shù)業(yè)務系統(tǒng)的需要。也可以用于本地的開發(fā)和測試 。
現(xiàn)在提供了sample-txc-simple和sample-txc-sample兩個樣例，sample-txc-simple是GTS的入門的基礎樣例，點擊下載后，搭建好本地的數(shù)據(jù)庫環(huán)境就可以直接運行樣例。sample-txc-dubbo是GTS和dubbo框架集成的樣例，也可以直接在本地機器運行。
- 3 通過專有云平臺輸出
這種形式主要面向于已建設了自己專有云平臺的大用戶，GTS可以直接部署到用戶的專有云平臺上，為專有云提供分布式事務服務。目前國家電網(wǎng)公司、中國郵政、浙江煙草等特大型企業(yè)的專有云都使用GTS，保證數(shù)據(jù)一致性。
3.6 GTS的使用方式
GTS對應用的侵入性非常低，使用也非常簡單。下面以訂單存儲應用為例說明。訂單業(yè)務應用通過調用訂單服務和庫存服務完成訂單業(yè)務，服務開發(fā)框架為dubbo。
1 訂單業(yè)務應用
在業(yè)務函數(shù)外圍使用@TxcTransaction注解即可開啟分布式事務。dubbo應用通過隱藏參數(shù)將GTS的事務xid傳播到服務端。
2 服務端使用方式
庫存服務
public int setStock(Stock sk) { //通過dubbo上下文獲取xid String xid = RpcContext.getContext().getAttachment("xid"); //將事務id綁定到服務端txc的上下文 TxcContext.bind(xid,null); //執(zhí)行扣庫存操作 ret = jdbcTemplate2.update("update stock set number = number -? where pid = ?",new Object[]{sk.getPnum(),sk.getPid()}); return ret; }復制代碼3.7 GTS的應用情況
GTS在滿足事務ACID的前提下，普通配置的單服務器可以達到15000 TPS以上的超強性能（兩個小時完成1億多筆業(yè)務）。目前已經(jīng)在淘寶、天貓、阿里影業(yè)、淘票票、阿里媽媽、1688等阿里各業(yè)務系統(tǒng)廣泛使用，經(jīng)受了16年和17年兩年雙十一海量請求的考驗。某線上業(yè)務系統(tǒng)最高流量已達十萬TPS（每秒鐘10萬筆事務）。GTS在阿里云及專有云上輸出后，有很多用戶通過GTS解決SpringCloud、Dubbo、Edas等微服務的分布式事務問題，包括國家電網(wǎng)、中國郵政、中國煙草、特步、浙江公安、德邦快遞、一步共享科技等，涉及電力、物流、ETC、煙草、金融、零售、電商、共享出行等十幾個行業(yè)，得到用戶的一致認可。
上圖是GTS與SpringCloud集成，應用于某共享出行系統(tǒng)。業(yè)務共享出行場景下，通過GTS支撐物聯(lián)網(wǎng)系統(tǒng)、訂單系統(tǒng)、支付系統(tǒng)、運維系統(tǒng)、分析系統(tǒng)等系各統(tǒng)應用事務一致性，保證海量訂單和數(shù)千萬流水的交易。
原文鏈接
總結
以上是生活随笔為你收集整理的一行代码，保障分布式事务一致性—GTS:微服务架构下分布式事务解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： global与nonlocal关键字
- 下一篇： open-falcon的邮件报警