如何實現微服務架構下的分佈式事務？

摘要：微服務架構下，如何克服分佈式事務難題？

什麼是微服務？微服務有什麼優點和困難？

什麼是微服務架構？

簡而言之，微服務架構的系統是一個分佈式的系統，按業務進行劃分爲獨立的服務單元，解決單體系統的不足，同時也知足愈來愈複雜的業務需求。每一個微服務僅關注於完成一件任務並很好地完成該任務。

微服務架構的優點

1. 將複雜的業務拆分紅多個小的業務，每一個業務拆分紅一個服務，將複雜的問題簡單化。利於分工，下降新人的學習成本。
2. 微服務系統是分佈式系統，業務與業務之間徹底解耦，隨着業務的增長能夠根據業務再拆分，具備極強的橫向擴展能力。
3. 服務間採用 HTTP 協議通訊，服務與服務之間徹底獨立。每一個服務能夠根據業務場景選取合適的編程語言和數據庫。
4. 服務獨立部署，每一個服務的修改和部署對其餘服務沒有影響。

雖然微服務有以上的優點，可是微服務實踐仍處於探索階段，不少中小型互聯網公司，鑑於經驗、技術實力等問題，微服務落地比較困難。著名架構師Chris Richardson指出，目前微服務主要存以下幾方面困難：

1. 單體應用拆分爲分佈式系統後，進程間的通信機制和故障處理措施變的更加複雜。
2. 系統微服務化後，一個看似簡單的功能，內部可能須要調用多個服務並操做多個數據庫實現，服務調用的分佈式事務問題變的很是突出。
3. 微服務數量衆多，其測試、部署、監控等都變的更加困難。

隨着RPC框架的成熟，第一個問題已經逐漸獲得解決。例如Dubbo能夠支持多種通信協議，Spring Cloud能夠很是好的支持restful調用。對於第三個問題，隨着Docker、DevOps技術的發展以及各公有云PaaS平臺自動化運維工具的推出，微服務的測試、部署與運維會變得愈來愈容易。

而對於第二個問題，如今尚未通用方案很好的解決微服務產生的事務問題。分佈式事務已經成爲微服務落地最大的阻礙，也是最具挑戰性的一個技術難題。下面將深刻和你們探討微服務架構下，分佈式事務的各類解決方案。

微服務架構下，如何克服分佈式事務難題？

什麼是事務

事務是由一組SQL語句組成的邏輯處理單元，事務具備如下4個屬性，一般簡稱爲事務的ACID屬性：

原子性（Atomicity）：事務是一個原子操做單元，其對數據的修改，要麼全都執行，要麼全都不執行。

一致性（Consistent）：在事務開始和完成時，數據都必須保持一致狀態。這意味着全部相關的數據規則都必須應用於事務的修改，以保持數據的完整性。

隔離性（Isolation）：數據庫系統提供必定的隔離機制，保證事務在不受外部併發操做影響的「獨立」環境執行。數據庫事務隔離級別由低到高依次爲Read uncommitted、Read committed、Repeatable 、Serializable。

持久性（Durability）：事務完成以後，它對於數據的修改是永久性的，即便出現系統故障也可以保持。

分佈式事務典型場景：

銀行轉帳業務是一個典型分佈式事務場景，一般包括如下三種狀況：

A. 支行內轉帳：同一銀行的相同支行內轉帳

B. 行內轉帳：同一銀行的不一樣支行間轉帳

C. 跨行轉帳：不一樣銀行的系統進行轉帳

對於傳統集中式架構，A、B一般爲本地事務，C爲分佈式事務。業務微服務改造後，轉入、轉出一般爲不一樣的微服務，同一個微服務也一般運行於不一樣實例中。A可能變成一個分佈式事務，也可能經過一些方法規避，在本地事務內完成。B和C很難規避，只能是分佈式事務。

微服務最佳實踐建議儘可能規避分佈式事務，可是在不少業務場景（好比上面的B、C轉帳場景），分佈式事務是一個繞不開的技術問題。

分佈式事務經常使用解決方案

爲了解決分佈式系統一致性問題，前人在性能和數據一致性的反反覆覆權衡過程當中總結了許多典型的協議和算法。其中，最經常使用的是兩階提交協議（2 Phase Commitment Protocol）。

兩階段提交方案

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

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

兩階段提交方案應用很是普遍，典型商用軟件包括Oracle Tuxedo和IBM CICS。它的優勢是對業務代碼侵入較低，但缺點也很明顯：

性能低下：因爲 XA 協議自身的特色，它會形成事務資源長時間得不到釋放，鎖定週期長，並且在應用層上面沒法干預，數據併發衝突高的場景性能不好。

單點問題：協調者在整個兩階段提交過程當中扮演着舉足輕重的做用，一旦協調者所在服務器宕機，就會影響整個數據庫集羣的正常運行。好比在第二階段中，若是協調者由於故障不能正常發送事務提交或回滾通知，那麼參與者們將一直處於阻塞狀態。

同步阻塞：兩階段提交執行過程當中，全部的參與者都須要遵從協調者的統一調度，期間處於阻塞狀態而不能從事其餘操做，效率及其低下。

所以，兩階段提交方案在互聯網業務中不多使用，沒法知足高併發需求。

爲了這個彌補這種方案帶來性能低的問題，你們又想出了不少種方案來解決，經過在應用層作文章，即入侵業務的方式，比較典型的是TCC 方案和基於可靠消息的最終一致性方案。

TCC事務方案

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

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

TCC方案讓應用本身定義數據庫操做的粒度，使得下降鎖衝突、提升吞吐量成爲可能，好比華爲分佈式事務中間件DTM性能極高，普通配置服務器能夠支持全局事務1萬+ TPS，分支事務3萬+ TPS。 固然TCC方案也有不足之處，集中表如今如下兩個方面：

業務侵入性強。業務邏輯的每一個分支都須要實現try、confirm、cancel三個操做，應用侵入性較強，改形成本高。

實現難度較大。爲了知足一致性的要求，要充分考慮冪等操做，容許重複執行，也要防止資源懸掛，作好併發訪問控制和數據可見性控制等。

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

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

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

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

入侵代碼的方案是基於現有情形「無可奈何」才推出的解決方案，實際上它們實現起來很是不優雅，好比TCC，一個事務的調用一般伴隨而來的是對該事務接口增長一系列的反向操做，提交邏輯必然伴隨着回滾的邏輯，這樣的代碼會使得項目很是臃腫，維護成本高。

針對上面所說的分佈式事務解決方案的痛點，很顯然，咱們理想的分佈式事務解決方案確定是性能要好並且要對業務無侵入，業務層無需關心分佈式事務機制的約束，作到事務與業務分離，也就是本文所重點推薦的非侵入事務。

非侵入事務方案

a. 典型架構

非侵入事務典型架構以下圖所示：

事務核心組件包括：

Transaction Coordinator (TC)： 事務協調器，分佈式事務大腦，產生和維護全局事務、分支事務，推動事務提交與回滾的二階段處理。TC Server以集羣形式提供事務協調能力。

Transaction Manager (TM)： 定義全局事務的邊界，與事務協調器通訊以開啓、提交或回滾全局事務。

Resource Manager (RM)： 資源管理器，管理分支事務處理的資源，與事務協調器通訊以開啓、結束事務分支，並接收事務協調器指令完成二階段分支事務提交或回滾。

Lock Server （LS）： 分佈式鎖服務器，能夠經過它對進行中的分佈式事務所操做的資源查詢、加鎖、放鎖。

一個分佈式事務稱爲一個全局事務，下面掛若干個分支事務，一個分支事務是一個知足 ACID 的本地事務。非侵入事務的核心思想是資源管理器攔截業務SQL，對其解析並作額外的一些數據處理，產生undo log並保存，一旦發生全局事務回滾，經過各個分支事務對應的undo log完成全部分支事務回滾。

你們很容易想到，兩個全局事務並行修改了相同數據，可能會形成根據undo log完成回滾產生數據錯誤。解決的方法是經過Lock Server對事務所修改數據加鎖，全局事務提交後當即放鎖，全局事務回滾則等待分支事務回滾完成放鎖。

b. 典型流程

典型分佈式事務主要執行步驟以下：

1.TM請求TC開始新的全局事務，TC建立全局事務並返回全局事務ID（XID）。

2.根據XID構建事務上下文，經過微服務的調用鏈傳播。

3.RM發現本身處於事務上下文，獲得全局事務ID並解析SQL，產生undo log和分佈式事務鎖數據，請求TC建立分支事務。

4.TC 經過LS加鎖，加鎖成功後建立分支事務ID並返回。

5.RM 把分支事務ID與undo log關聯，與業務原始SQL在一個本地事務內提交。

6.重複3~5，爲全局事務範圍內的每一個本地事務建立一個分支事務。

7.若是全局事務邊界內沒有任何異常，則TM請求TC提交全局事務；若是有異常，則TM請求TC回滾全局事務。

1. TC標記全局事務狀態，若是爲提交則當即經過LS放鎖。推動XID所對應全局事務下的全部分支事務進行二階段處理，發送請求到RM。

9.RM完成分支事務的提交或回滾，並返回狀態到TC。

10.TC對完成回滾的分支經過LS放鎖。全部分支完成後，返回全局事務處理結果到TM。

二階段事務處理比較關鍵，在此重點說明一下。

c. 分支事務提交

若是全局事務狀態爲提交，則對每一個分支發起分支提交，流程以下圖所示：

RM收到分支事務提交請求，先保存分支事務的ID在隊列中並返回。一個線程定時從隊列中取出一批分支事務ID，構建SQL批量刪除所對應的undo log日誌。分支事務提交能夠異步批量處理，是由於全局事務已經提交，undo log做爲中間狀態已經再也不重要，只要按期清理便可。

d. 分支事務回滾

若是全局事務狀態爲回滾或超時，則對每一個分支發起分支回滾，流程以下圖所示：

RM收到分支事務回滾請求，開啓一個本地事務，經過分支ID找到對應的undo log，構建回滾SQL語句並執行，刪除undo log，而後提交本地事務。若是順利完成，TC收到響應後經過LS清理該分支所佔用資源。

e. 性能分析

非侵入事務相比XA兩階段提交一個重要性能優點在於鎖定資源時間更短。實際業務中，咱們知道絕大多數事務狀態爲提交，不多比例爲回滾。對於XA來講，不管是提交仍是回滾，資源都是在二階段釋放。對本文所介紹的非侵入事務來講，提交狀態的全局事務，二階段沒有必要拿鎖，只有少比例的回滾狀態的全局事務，才須要在二階段放鎖。

非侵入事務不受限於數據庫XA接口，實現徹底可控。TC、RM、LS這些關鍵組件對性能影響很大，良好的設計、實現能夠取得很是高的性能。非侵入式事務實踐證實，它能夠輕鬆知足絕大多數高併發業務場景的性能需求。

典型核心業務系統分佈式事務改造實例

華爲雲Stack爲某運營商核心業務系統分佈式事務改造，該客戶業務在月初充值、扣費業務高峯期等常見的併發場景時，對分佈式系統提出挑戰：

• 高併發的分佈式事務訪問帳戶表，XA兩階段提交因爲加鎖時間長，嚴重影響業務。總體性能要求達1000+ TPS，傳統或開源分佈式事務難以知足高可用性與高性能要求。
• XA事務與其餘數據庫操做的一致性問題。須要把XA事務做爲DTM TCC事務的一個分支，將別的數據庫操做是另外的分支。

華爲雲Stack混合雲解決方案分佈式事務中間件DTM經過一系列創新技術，提供高性能、高可用、高可靠、高安全、低侵入、易使用的分佈式事務服務，支持TCC事務和非侵入事務兩種模型，助力企業微服務化改造，優雅地解決分佈式系統下數據一致性難題。

點擊關注，第一時間瞭解華爲雲新鮮技術~