微服務下分佈式事務解決方案

摘抄並學習

 

1. 微服務的發展

　　微服務倡導將複雜的單體應用拆分紅若干個功能簡單、鬆耦合的服務，這樣能夠下降開發難度、加強擴展性。便於敏捷開發。當前微服務的開發框架很是多，比較著名的有 Dubbo、SpringCloud、thrift、grpc 等。

 

2. 微服務落地存在的問題

　　雖然如今微服務如火如荼，但對其實踐仍處於探索階段。不少中小型互聯網公司鑑於經驗技術實力等問題，微服務落地比較困難。主要有如下幾個方面：

　　1）單體應用拆分爲分佈式系統後，進程間的通信機制和故障處理措施變得更加複雜。

　　2）系統微服務化後，一個看似簡單的功能，內部可能須要調用多個服務並操做多個數據庫實現，服務調用的分佈式事務問題很是突出。

　　3）微服務數量衆多，其測試、部署、監控等都變得更加困難

 

　　隨着 RPC（遠程過程調用 Remote Procedure Call） 框架的成熟，第一個問題已經逐漸獲得解決。例如 dubbo 能夠支持多種通信協議，springcloud 能夠很是好的支持 restful 調用。對於第二個問題，如今尚未通用方案很好的解決微服務產生的事務問題。分佈式事務已經成爲微服務落地最大的阻礙，也是最具挑戰性的一個技術難題。

　　如下介紹分佈式事務的各類解決方案，重點解讀阿里巴巴提出的分佈式事務解決方案 —— GTS。

 

 

3. SOA分佈式事務解決方案

 

3.1 基於 XA 協議的兩階段提交方案

　　交易中間件與數據庫經過 XA 接口規範，使用兩階段提交來完成一個全局事務，XA 規範的基礎是兩階段提交協議。

　　第一階段是表決階段，全部參與者都將本事務可否成功的信息返回給協調者；第二階段是執行階段，協調者根據全部參與者的反饋，通知全部參與者，步調一致地在全部分支上提價或者回滾。

 

　　兩階段提交方案應用很是普遍，幾乎全部商業 OLTP 數據庫都支持 XA 協議。可是兩階段提交方案鎖定資源時間長，對性能影響很大，基本不適合解決微服務事務問題。

 

3.2 TCC 方案

　　TCC 方案在電商、金融領域落地較多，TCC 方案實際上是兩階段提交的一種改進。其將整個業務邏輯的每一個分支顯式的分紅了 Try、Confirm、Cancel 三個操做。Try 部分完成業務的準備工做，cinfirm 部分完成業務的提交，cancel 部分完成事務的回滾。基本原理以下

 

 　　事務開始時，業務應用會向事務協調器註冊啓動事務。以後業務應用會調用全部服務的 Try 接口，完成一階段準備，以後事務協調器會根據 Try 接口返回狀況，決定調用 confirm 接口或者 cancel 接口。若是接口調用失敗會進行重試。

　　TCC 方案讓應用本身定義數據庫操做的粒度，使得下降鎖衝突、提升吞吐量稱爲可能，固然 TCC 方案也有不足之處，集中表如今如下兩個方面：

• 對應用的侵入性強。業務邏輯的每一個分支都須要實現 try、confirm、cancel 三個操做，應用侵入性較強，改形成本高。
• 實現難度大。須要按照網絡狀態、系統故障等不一樣的失敗緣由實現不一樣的回滾策略。爲了知足一致性的要求，confirm 和 cancel 接口必須實現冪等（針對一個操做，無論作多少次，產生效果或返回的結果都是同樣的）。

　　上述緣由致使 TCC 方案大多被研發實力較強，有迫切需求的大公司所採用。微服務倡導服務的輕量化、易部署，而 TCC 方案中不少事物的處理邏輯須要應用本身的編碼實現，複雜且開發了大。

 

3.3 基於消息的最終一致性方案

 　　消息一致性方案是經過消息中間件保證上、下游應用數據操做的一致性。基本思路是將本地操做和發送消息放在一個事務中，保證本地操做和消息發送要麼二者都成功或者都失敗。下游應用向消息系統訂閱該消息，收到消息後執行相應操做。

　　消息方案從本質上是將分佈式事務轉換成兩個本地事務，而後依靠下游業務的重試機制達到最終一致性。基於消息的最終一致性方案對應用侵入性也很高，應用須要進行大量業務改造，成本較高。

 

4  GTS -- 分佈式事務解決方案

4.1 GTS的核心優點

• 性能超強：GTS經過大量創新，解決了事務ACID 特性與高性能、高可用、低侵入 不可兼得的問題。單事務分支的平均響應時間在 2ms 左右，3臺服務器組成的集羣能夠支撐3萬TPS以上的分佈式事務請求。
• 應用侵入性低：GTS對業務低侵入，業務代碼最少只需添加一行註解（@TxcTransaction）聲明事務便可。業務與事務分離，將微服務從事務中解放出來，微服務關注於業務自己，再也不須要考慮反向接口、冪等、回滾策略等複雜問題，極大下降了微服務開發的難度與工做量。
• 完整解決方案：GTS支持多種主流的服務框架，包括 EDAS、Dubbo、SpringCloud 等。有些狀況下，應用須要調用第三方系統的接口，而第三方系統沒有接入 GTS。此時須要用到 GTS 的 MT 模式。GTS 的 MT 模式能夠等價於 TCC 模式，用戶能夠根據自身業務需求自定義每一個事物階段的具體行爲。MT 模式提供了更多的靈活性、可能性，以達到特殊場景下的自定義優化及特殊功能的實現。
• 容錯能力強：GTS 解決了 XA 事務協調器單點問題，實現真正的高可用，可用保證各類異常狀況下的嚴格數據一致。

 

4.2 GTS 與微服務的集成

　　GTS 包括客戶端（GTS Client），資源管理器（GTS RM）和事務協調器（GTS Server）三個部分。GTS Client 主要用來界定事務邊界，完成事務的發起與結束。GTS RM 完成事務分支的建立、提交、回滾等操做。GTS Server 主要負責分佈式事務的總體推動，事務生命週期的管理。GTS 和微服務集成的結構圖以下所示，GTS Client 須要和業務應用集成部署，RM 與微服務集成部署。

 

 

4.3 GTS的輸出

　　GTS 目前有三種輸出形式：公有云輸出、公網輸出、專有云輸出

　　

4.3.1 公有云輸出

　　這種輸出形式面向阿里雲用戶。若是用戶的業務系統已經部署到阿里雲上，能夠申請開通公有云 GTS。開通後業務應用便可以經過 GTS 保證服務調用的一致性。這種使用場景下，業務系統和 GTS 間的網絡環境比較理想，達到很好的性能。

 

4.3.2 公網輸出

　　這種輸出形式面向於非阿里雲用戶，使用更加方便、靈活，業務系統只要能鏈接互聯網便可享受 GTS 提供的雲服務（與公有云輸出的差異在於客戶端部署在用戶本地，而不在雲上）

 

4.3.3 專有云輸出

　　這種形式主要面向於已建設了本身專有云平臺的大用戶，GTS 能夠直接部署到用戶的專有云上，爲專有云提供分佈式事務服務。目前已經有10多個特大型企業的專有云使用 GTS 解決分佈式事務難題，性能與穩定性通過了用戶的嚴格檢測。

 

 

 

摘抄自：https://www.cnblogs.com/jiangyu666/p/8522547.html