導讀：
本文就微服務事務一致性問題產生根源、業界常用方案優缺點進行了分析對比，在此基礎上提出了用友微服務事務一致性解決方案，詳細介紹了用友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才能符合業務實際回滾需求。