導讀：
本文就微服務事務一致性問題產生根源、業界常用方案優缺點進行了分析對比，在此基礎上提出了用友微服務事務一致性解決方案，詳細介紹了用友CC事務模型及原理，以及此方案解決的場景。
一致性問題的產生
在傳統巨石應用架構模式下，架構特點主要是mvc模式，由controller層負責對外提供服務接口，所有功能集中在一個服務實例中，通過增減服務實例來擴展集羣的處理能力，但數據持久化集中在一個數據庫存儲，數據一致性主要依靠傳統數據庫本地事務機制保證，這種架構模式特點是簡單、快捷，方便業務規模不大，業務功能單一的場景，隨着業務增長，無論是業務規模還是業務範圍都在快速變化，這種巨石架構模式就顯得力不從心，不易於開發協調，因此，微服務架構模式應運而生，所謂微服務通俗來說就是對服務進行垂直拆分，將一個整體服務拆分成功能相對獨立的單元服務，各單元服務之間通過rpc進行同步或異步調用。微服務架構模式下各個服務單元各自有獨立的數據持久層，一個業務請求需要多個微服務單元共同協作，要求各服務單元要麼同時成功或同時失敗，但微服務實例分別部署在不同的進程或主機節點上，每個服務實例的狀態、網絡等情況是不可預知的，因此，如何保證一個業務請求中各單元服務數據保持一致性成爲微服務架構中一個關鍵的問題。
常見解決方案
兩階段提交
兩階段提交屬於剛性事務，兩階段分爲準備階段和提交階段，在準備階段，由事務協調器向各個參與者發送Prepare消息，參與者收到消息後，要麼返回失敗，要麼執行本地事務，並寫本地redo和undo日誌，但是並不commit事務，此時，本地事務資源是被鎖定狀態，其它服務或應用是不能使用此資源的。在提交階段，事務協調者在接收到所有參與者事務消息通知之後，根據所有參與者提交階段返回的狀態確定在提交階段是回滾還是提交事務，只要有一個參與者超時或者失敗，協調者就向所有參與者發送回滾請求，否則就向參與者發送提交請求。
二階段提交的優點
1）實現了事務的隔離，確保了強一致性，即本地事務未提交的數據對其它事務不可見，事務要麼都提交成功要麼都失敗
2）業務編程簡單，由於事務管理是由事務協調者及本地事務資源管理器實現，開發者必須要介入太多事務相關的工作
二階段提交缺點
1）同步阻塞調用，在事務執行過程中，所有參與者同步鎖定資源以實現隔離，被鎖定的資源不能被其他事務訪問
2）需要本地事務支持，即本地數據庫需要支持xa協議
3）需要事務協調者，協調者存在單點問題
4）事務會出現無法確認的狀態。當協調者發出commit請求後，然後協調者宕機，而參與者可能只有一個已提交，其它參與者尚未提交，此時如果唯一的參與者也宕機，整個事務狀態將無法確認
5）主要解決的單JVM跨庫的事務一致性
TCC事務
TCC事務即Try-Confirm-cancel三個階段，是柔性事務的一種，實現的是最終一致性，適合於同步調用過程。TCC是應用層的兩階段提交，不需要事務本地數據庫對XA協議的支持。TCC事務模型有三個部分組成
·主業務服務
主業務服務爲整個業務活動的發起方，通常是服務聚合應用，比如商城系統的下單系統，下單時需要調用庫存系統減庫存，支付系統付款及積分系統給用戶積分以及購物車系統清理購物車內容。
·從業務服務
從業務服務負責提供TCC業務操作，是整個業務活動的操作方。從業務服務必須實現Try、Confirm和Cancel三個接口，供主業務服務調用。由於Confirm和Cancel操作可能被重複調用，故要求Confirm和Cancel兩個接口必須是冪等的。
·業務活動管理器
業務活動管理器管理控制整個業務活動，包括記錄維護TCC全局事務的事務狀態和每個從業務服務的子事務狀態，並在業務活動提交時確認所有的TCC型操作的confirm操作，在業務活動取消時調用所有TCC型操作的cancel操作。
1）Try：嘗試執行業務
完成所有業務檢查（一致性）
預留必須業務資源（準隔離性）
2）Confirm：確認執行業務
真正執行業務
不做任何業務檢查
只使用Try階段預留的業務資源
只要Try階段執行成功，需要確保Confirm一定成功，可以不斷重試
3）Cancel：取消執行業務
釋放Try階段預留的業務資源
只要try階段失敗，必須確保Cancel最終一定成功
TCC模式優點
1）解決了跨應用的事務問題
2）把數據庫層面的兩階段提交提到應用層來實現，不需要數據庫層面來支持XA協議，規避了數據庫的XA支持的缺陷
TCC模式缺點
1）需要從業務的角度來設計業務接口，確保業務可分解成Try、Confirm、Cancel三個階段，增加了業務編程的複雜性
2）由於每個應用的網絡不一定可靠，可能會多次調用業務接口，需要業務層面考慮冪等性操作
3）由於三個階段都是同步調用過程，因此隨着參與者增多，對主業務響應速度有影響
基於消息隊列的最終一致性
基於消息隊列的最終一致性考慮的場景是業務之間通過異步調用來實現，即作爲服務調用方發起方異步調用之後立即返回，不必等待被調用服務實際返回結果，這樣就可以基於消息隊列來實現業務之間的解耦，由各業務來確保最終一致性。
基於消息隊列的最終一致性方案的優點
1）各業務之間完全解耦，單個業務性能不會影響整體服務
2）有助於提升服務的整體性能和吞吐量
3）實現起來簡單，只需要參與事務的各方在收到消息後確保本地事務一致性、冪等性
基於消息隊列的最終一致性方案的缺點
1）需要業務調用方來確保本地事務和發送消息的原子性，雖然像ActiveMq支持事務消息，但是事務消息對性能影響較大，可以在本地建立消息表的方式來確保本地事務與發送消息同時成功或失敗
2）當出現不一致時，需要人工介入處理各個業務的執行狀態
用友微服務事務一致性解決方案
用友微服務治理中的事務一致性解決方案綜合了TCC與基於消息隊列的最終一致性，CC事務模型，即Confirm 和Cancel模型。該模型將分佈式事務邊界劃以異步調用爲邊界，只要在調用鏈中加入事務的同步調用，都屬於一個全局事務，在這個全局事務中，保證事務的最終一致性，如圖：
在此圖中一個完整的調用鏈從A服務開始，在左邊方框內是rpc同步調用，而右邊也是一個rpc同步調用，兩個方框之間的服務C是通過異步調用框架EOS基於可靠消息隊列對服務E發起調用，CC事務模型將此次調用當做兩個事務處理。
CC事務模型事務狀態變化時序圖，rpc調用鏈關係爲A->B，B->C，B->D，C->E，時序圖如下：
CC事務模型過程，A同步調用B服務，事務框架在A服務內部數據庫記錄對B的調用上下文及事務記錄，事務狀態爲Confirming狀態，同時，rpc框架將事務上下文傳遞給B，B服務接收到rpc調用請求，B服務記錄事務，同時事務爲Confirming狀態，同理，B調用C，C調用E，B調用D.此時，如果B調用D異常，則B本地事務回滾，同時B服務捕捉到異常後根據B服務記錄的調用關係上下文，通過EOS框架向C和D發起異步補償方法調用，所有方法補償方法調用成功，則B事務狀態爲Cancelled，C服務補償調用成功後繼續向E服務發起異步補償調用。同時，B向A拋出異常，A捕捉異常後執行補償異步調用，同時本地事務回滾，最終AB事務狀態爲Cancelled或者Confirming狀態，C、D、E已提交事務執行補償方法後狀態爲Cancelled.最終，所有的事務狀態都會confirmed時，則事務成功，或者所有狀態都爲Cancelled時，回退成功，如果有節點處於Confirming狀態，說明整個事務發生了不一致狀態，需要人工介入處理。
CC事務模型優點
1）沒有事務管理器的概念，每個事務節點都是對等的
2）模型簡單，代碼侵入少，開發者只需要在業務接口上方法上使用@CCTransaction（cancel='異常時補償事務方法'）標識此方法納入事務管理，同時，補償方法上加入@CCTransCancel
3）異步消息補償機制。事務補償機制通過EOS可靠消息投遞，減少事務補償回調對業務系統性能的影響
CC事務模型缺點
1）該事務模型與自研rpc框架iris綁定，不支持其它rpc框架
2）沒有Try階段鎖定資源，一進入事務本地事務就已實際提交，不具備事務隔離能力，業務需要考慮如何實現Cancel才能符合業務實際回滾需求。