摘要： 本文將深入和大家探討微服務架構(gòu)下，分布式事務的各種解決方案爬泥，并重點為大家解讀阿里巴巴提出的分布式事務解決方案----GTS。該方案中提到的GTS是全新一代解決微服務問題的分布式事務互聯(lián)網(wǎng)中間件崩瓤。
1 微服務的發(fā)展
微服務倡導將復雜的單體應用拆分為若干個功能簡單袍啡、松耦合的服務，這樣可以降低開發(fā)難度却桶、增強擴展性境输、便于敏捷開發(fā)。當前被越來越多的開發(fā)者推崇颖系，很多互聯(lián)網(wǎng)行業(yè)巨頭嗅剖、開源社區(qū)等都開始了微服務的討論和實踐。Hailo有160個不同服務構(gòu)成集晚，NetFlix有大約600個服務窗悯。國內(nèi)方面，阿里巴巴偷拔、騰訊蒋院、360、京東莲绰、58同城等很多互聯(lián)網(wǎng)公司都進行了微服務化實踐欺旧。當前微服務的開發(fā)框架也非常多，比較著名的有Dubbo蛤签、SpringCloud辞友、thrift 、grpc等震肮。
2 微服務落地存在的問題
雖然微服務現(xiàn)在如火如荼称龙，但對其實踐其實仍處于探索階段。很多中小型互聯(lián)網(wǎng)公司戳晌，鑒于經(jīng)驗鲫尊、技術(shù)實力等問題，微服務落地比較困難沦偎。如著名架構(gòu)師Chris Richardson所言疫向，目前存在的主要困難有如下幾方面：
1）單體應用拆分為分布式系統(tǒng)后，進程間的通訊機制和故障處理措施變的更加復雜豪嚎。
2）系統(tǒng)微服務化后搔驼，一個看似簡單的功能，內(nèi)部可能需要調(diào)用多個服務并操作多個數(shù)據(jù)庫實現(xiàn)侈询，服務調(diào)用的分布式事務問題變的非常突出舌涨。
3）微服務數(shù)量眾多，其測試扔字、部署泼菌、監(jiān)控等都變的更加困難谍肤。
隨著RPC框架的成熟，第一個問題已經(jīng)逐漸得到解決哗伯。例如dubbo可以支持多種通訊協(xié)議荒揣，springcloud可以非常好的支持restful調(diào)用。對于第三個問題焊刹，隨著docker系任、devops技術(shù)的發(fā)展以及各公有云paas平臺自動化運維工具的推出，微服務的測試虐块、部署與運維會變得越來越容易俩滥。
而對于第二個問題，現(xiàn)在還沒有通用方案很好的解決微服務產(chǎn)生的事務問題贺奠。分布式事務已經(jīng)成為微服務落地最大的阻礙霜旧，也是最具挑戰(zhàn)性的一個技術(shù)難題。 為此儡率，本文將深入和大家探討微服務架構(gòu)下挂据，分布式事務的各種解決方案，并重點為大家解讀阿里巴巴提出的分布式事務解決方案----GTS儿普。該方案中提到的GTS是全新一代解決微服務問題的分布式事務互聯(lián)網(wǎng)中間件崎逃。
3 傳統(tǒng)分布式事務解決方案
3.1 基于XA協(xié)議的兩階段提交方案
交易中間件與數(shù)據(jù)庫通過 XA 接口規(guī)范，使用兩階段提交來完成一個全局事務眉孩， XA 規(guī)范的基礎(chǔ)是兩階段提交協(xié)議个绍。
第一階段是表決階段，所有參與者都將本事務能否成功的信息反饋發(fā)給協(xié)調(diào)者浪汪；第二階段是執(zhí)行階段巴柿，協(xié)調(diào)者根據(jù)所有參與者的反饋，通知所有參與者死遭，步調(diào)一致地在所有分支上提交或者回滾篮洁。
兩階段提交方案應用非常廣泛，幾乎所有商業(yè)OLTP數(shù)據(jù)庫都支持XA協(xié)議殃姓。但是兩階段提交方案鎖定資源時間長，對性能影響很大瓦阐，基本不適合解決微服務事務問題蜗侈。
3.2 TCC方案
TCC方案在電商、金融領(lǐng)域落地較多睡蟋。TCC方案其實是兩階段提交的一種改進踏幻。其將整個業(yè)務邏輯的每個分支顯式的分成了Try、Confirm戳杀、Cancel三個操作该面。Try部分完成業(yè)務的準備工作夭苗，confirm部分完成業(yè)務的提交，cancel部分完成事務的回滾隔缀√庠欤基本原理如下圖所示。
事務開始時猾瘸，業(yè)務應用會向事務協(xié)調(diào)器注冊啟動事務界赔。之后業(yè)務應用會調(diào)用所有服務的try接口，完成一階段準備牵触。之后事務協(xié)調(diào)器會根據(jù)try接口返回情況淮悼，決定調(diào)用confirm接口或者cancel接口。如果接口調(diào)用失敗揽思，會進行重試袜腥。
TCC方案讓應用自己定義數(shù)據(jù)庫操作的粒度，使得降低鎖沖突钉汗、提高吞吐量成為可能羹令。 當然TCC方案也有不足之處，集中表現(xiàn)在以下兩個方面：
- 對應用的侵入性強儡湾。業(yè)務邏輯的每個分支都需要實現(xiàn)try特恬、confirm、cancel三個操作徐钠，應用侵入性較強癌刽，改造成本高。
- 實現(xiàn)難度較大尝丐。需要按照網(wǎng)絡狀態(tài)显拜、系統(tǒng)故障等不同的失敗原因?qū)崿F(xiàn)不同的回滾策略。為了滿足一致性的要求爹袁，confirm和cancel接口必須實現(xiàn)冪等远荠。
上述原因?qū)е耇CC方案大多被研發(fā)實力較強、有迫切需求的大公司所采用失息。微服務倡導服務的輕量化譬淳、易部署，而TCC方案中很多事務的處理邏輯需要應用自己編碼實現(xiàn)盹兢，復雜且開發(fā)量大邻梆。
3.3 基于消息的最終一致性方案
消息一致性方案是通過消息中間件保證上、下游應用數(shù)據(jù)操作的一致性绎秒∑滞基本思路是將本地操作和發(fā)送消息放在一個事務中，保證本地操作和消息發(fā)送要么兩者都成功或者都失敗。下游應用向消息系統(tǒng)訂閱該消息剂娄，收到消息后執(zhí)行相應操作蠢涝。
消息方案從本質(zhì)上講是將分布式事務轉(zhuǎn)換為兩個本地事務，然后依靠下游業(yè)務的重試機制達到最終一致性阅懦『投基于消息的最終一致性方案對應用侵入性也很高，應用需要進行大量業(yè)務改造故黑，成本較高儿咱。
4 GTS--分布式事務解決方案
GTS是一款分布式事務中間件，由阿里巴巴中間件部門研發(fā)场晶，可以為微服務架構(gòu)中的分布式事務提供一站式解決方案混埠。
更多GTS資料請訪問研發(fā)團隊微博。
4.1 GTS的核心優(yōu)勢
- 性能超強
GTS通過大量創(chuàng)新诗轻，解決了事務ACID特性與高性能钳宪、高可用、低侵入不可兼得的問題扳炬。單事務分支的平均響應時間在2ms左右吏颖，3臺服務器組成的集群可以支撐3萬TPS以上的分布式事務請求。
- 應用侵入性極低
GTS對業(yè)務低侵入恨樟，業(yè)務代碼最少只需要添加一行注解（@TxcTransaction）聲明事務即可半醉。業(yè)務與事務分離，將微服務從事務中解放出來劝术，微服務關(guān)注于業(yè)務本身缩多，不再需要考慮反向接口、冪等养晋、回滾策略等復雜問題衬吆，極大降低了微服務開發(fā)的難度與工作量。
- 完整解決方案
GTS支持多種主流的服務框架绳泉，包括EDAS逊抡，Dubbo，Spring Cloud等零酪。
有些情況下冒嫡，應用需要調(diào)用第三方系統(tǒng)的接口，而第三方系統(tǒng)沒有接入GTS四苇。此時需要用到GTS的MT模式孝凌。GTS的MT模式可以等價于TCC模式，用戶可以根據(jù)自身業(yè)務需求自定義每個事務階段的具體行為蛔琅。MT模式提供了更多的靈活性，可能性，以達到特殊場景下的自定義優(yōu)化及特殊功能的實現(xiàn)罗售。
- 容錯能力強
GTS解決了XA事務協(xié)調(diào)器單點問題辜窑，實現(xiàn)真正的高可用，可以保證各種異常情況下的嚴格數(shù)據(jù)一致寨躁。
4.2 GTS的應用場景
GTS可應用在涉及服務調(diào)用的多個領(lǐng)域穆碎，包括但不限于金融支付、電信职恳、電子商務所禀、快遞物流、廣告營銷放钦、社交色徘、即時通信、手游操禀、視頻褂策、物聯(lián)網(wǎng)、車聯(lián)網(wǎng)等颓屑，詳細介紹可以閱讀 《GTS--阿里巴巴分布式事務全新解決方案》一文斤寂。
4.3 GTS與微服務的集成
GTS包括客戶端（GTS Client）、資源管理器（GTS RM）和事務協(xié)調(diào)器（GTS Server）三個部分揪惦。GTS Client主要用來界定事務邊界遍搞，完成事務的發(fā)起與結(jié)束。GTS RM完成事務分支的創(chuàng)建器腋、提交溪猿、回滾等操作。GTS Server主要負責分布式事務的整體推進蒂培，事務生命周期的管理再愈。GTS和微服務集成的結(jié)構(gòu)圖如下所示，GTS Client需要和業(yè)務應用集成部署护戳，RM與微服務集成部署翎冲。
