為什麼說傳統分散式事務不再適用於微服務架構？
傳統應用使用本地事務和分散式事務保證資料一致性，但是在微服務架構中資料都是服務私有的，需要通過服務提供的API來訪問，所以分散式事務不再適用微服務架構。那麼微服務架構又該如何保證資料一致性呢？本文就來談談這個話題。
-
傳統分散式事務不是微服務中資料一致性的最佳選擇
-
微服務架構中應滿足資料最終一致性原則
-
微服務架構實現最終一致性的三種模式
-
對賬是最後的終極防線
傳統分散式事務
我們先來看下第一部分，傳統使用本地事務和分散式事務保證一致性。
傳統單機應用一般都會使用一個關係型資料庫，好處是應用可以使用ACID。為保證一致性我們只需要：開始一個事務，改變（插入，刪除，更新）很多行，然後提交事務（如果有異常時回滾事務）。更進一步，藉助開發平臺中的資料訪問技術和框架（如 Spring），我們需要做的事情更少，只需要關注資料本身的改變。
隨著組織規模不斷擴大，業務量不斷增長，單機應用和資料庫已經不足以支援龐大的業務量和資料量，這個時候需要對應用和資料庫進行拆分，這就出現了一個應用需要同時訪問兩個或兩個以上的資料庫情況。開始我們用分散式事務來保證一致性，也就是我們常說的兩階段提交協議（2PC）。
本地事務和分散式事務現在已經非常成熟，相關介紹很豐富，此處不再討論。我們下面來談談為什麼分散式事務不適用於微服務架構。
首先，對於微服務架構來說，資料訪問變得更加複雜，這是因為資料都是微服務私有的，唯一可訪問的方式就是通過 API。這種打包資料訪問方式使得微服務之間鬆耦合，並且彼此之間獨立，更容易進行效能擴充套件。
其次，不同的微服務經常使用不同的資料庫。應用會產生各種不同型別的資料，關係型資料庫並不一定是最佳選擇。
例如，某個產生和查詢字串的應用採用 Elasticsearch 的字元搜尋引擎；某個產生社交圖片資料的應用可以採用圖資料庫，例如Neo4j。
基於微服務的應用一般都使用 SQL 和 NoSQL 結合的模式。但是這些非關係型資料大多數並不支援 2PC。
可見在微服務架構中已經不能選擇分散式事務了。
最終一致性原則
依據 CAP 理論，必須在可用性（availability）和一致性（consistency）之間做出選擇。如果選擇提供一致性需要付出在滿足一致性之前阻塞其他併發訪問的代價。這可能持續一個不確定的時間，尤其是在系統已經表現出高延遲時或者網路故障導致失去連線時。
依據目前的成功經驗，可用性一般是更好的選擇，但是在服務和資料庫之間維護資料一致性是非常根本的需求，微服務架構中應選擇滿足最終一致性。
最終一致性是指系統中的所有資料副本經過一定時間後，最終能夠達到一致的狀態。
當然選擇了最終一致性，就要保證到最終的這段時間要在使用者可接受的範圍之內。那麼我們怎麼實現最終一致性呢？
從一致性的本質來看，是要保證在一個業務邏輯中包含的服務要麼都成功，要麼都失敗。那我們怎麼選擇方向呢？保證成功還是保證失敗呢？
我們說業務模式決定了我們的選擇。實現最終一致性有三種模式：可靠事件模式、業務補償模式、TCC 模式。
可靠事件模式
可靠事件模式屬於事件驅動架構，當某件重要事情發生時，例如更新一個業務實體，微服務會向訊息代理髮佈一個事件。訊息代理會向訂閱事件的微服務推送事件，當訂閱這些事件的微服務接收此事件時，就可以完成自己的業務，也可能會引發更多的事件釋出。
1. 如訂單服務建立一個待支付的訂單，釋出一個“建立訂單”的事件。
2. 支付服務消費“建立訂單”事件，支付完成後釋出一個“支付完成”事件。
3. 訂單服務消費“支付完成”事件，訂單狀態更新為待出庫。
從而就實現了完成的業務流程。但是這並不是一個完美的流程。
這個過程可能導致出現不一致的地方在於：某個微服務在更新了業務實體後釋出事件卻失敗；雖然微服務釋出事件成功，但是訊息代理未能正確推送事件到訂閱的微服務；接受事件的微服務重複消費了事件。
可靠事件模式在於保證可靠事件投遞和避免重複消費，可靠事件投遞定義為：
-
每個服務原子性的業務操作和釋出事件。
-
訊息代理確保事件傳遞至少一次。
避免重複消費要求服務實現冪等性，如支付服務不能因為重複收到事件而多次支付。
因為現在流行的訊息佇列都實現了事件的持久化和 at least once 的投遞模式，『訊息代理確保事件投遞至少一次』已經滿足，今天不做展開。
下面分享的內容主要從可靠事件投遞和實現冪等性兩方面來討論，我們先來看可靠事件投遞。
首先我們來看一個實現的程式碼片段，這是從某生產系統上擷取下來的。
根據上述程式碼及註釋，初看可能出現 3 種情況：
-
操作資料庫成功，向訊息代理投遞事件也成功。
-
操作資料庫失敗，不會向訊息代理中投遞事件了。
-
操作資料庫成功，但是向訊息代理中投遞事件時失敗，向外丟擲了異常，剛剛執行的更新資料庫的操作將被回滾。
從上面分析的幾種情況來看，貌似沒有問題。但是仔細分析不難發現缺陷所在，在上面的處理過程中存在一段隱患時間視窗。
-
微服務 A 投遞事件的時候可能訊息代理已經處理成功，但是返回響應的時候網路異常，導致 append 操作丟擲異常。最終結果是事件被投遞，資料庫卻被回滾。
-
在投遞完成後到資料庫 commit 操作之間如果微服務 A 宕機也將造成資料庫操作因為連線異常關閉而被回滾。最終結果還是事件被投遞，資料庫卻被回滾。這個實現往往執行很長時間都沒有出過問題，但是一旦出現了將會讓人感覺莫名，很難發現問題所在。
下面給出兩種可靠事件投遞的實現方式。
1. 本地事件表
本地事件表方法將事件和業務資料儲存在同一個資料庫中，使用一個額外的“事件恢復”服務來恢復事件，由本地事務保證更新業務和釋出事件的原子性。考慮到事件恢復可能會有一定的延時，服務在完成本地事務後可立即向訊息代理髮佈一個事件。
-
微服務在同一個本地事務中記錄業務資料和事件。
-
微服務實時釋出一個事件立即通知關聯的業務服務，如果事件釋出成功立即刪除記錄的事件。
-
事件恢復服務定時從事件表中恢復未釋出成功的事件，重新發布，重新發布成功才刪除記錄的事件。
其中第Ⅱ條的操作主要是為了增加發布事件的實時性，由第三條保證事件一定被髮布。
本地事件表方式業務系統和事件系統耦合比較緊密，額外的事件資料庫操作也會給資料庫帶來額外的壓力，可能成為瓶頸。
2. 外部事件表
外部事件表方法將事件持久化到外部的事件系統，事件系統需提供實時事件服務以接受微服務釋出事件，同時事件系統還需要提供事件恢復服務來確認和恢復事件。
-
業務服務在事務提交前，通過實時事件服務向事件系統請求傳送事件，事件系統只記錄事件並不真正傳送。
-
業務服務在提交後，通過實時事件服務向事件系統確認傳送，事件得到確認後事件系統才真正釋出事件到訊息代理。
-
業務服務在業務回滾時，通過實時事件向事件系統取消事件。
-
如果業務服務在傳送確認或取消之前停止服務了怎麼辦呢？事件系統的事件恢復服務會定期找到未確認傳送的事件向業務服務查詢狀態，根據業務服務返回的狀態決定事件是要釋出還是取消。
該方式將業務系統和事件系統獨立解耦，都可以獨立伸縮。但是這種方式需要一次額外的傳送操作，並且需要釋出者提供額外的查詢介面。
介紹完了可靠事件投遞再來說一說冪等性的實現，有些事件本身是冪等的，有些事件卻不是。
本身具有冪等性的事件需要考慮執行順序
如果事件本身描述的是某個時間點的固定值（如賬戶餘額為 100），而不是描述一條轉換指令（如餘額增加 10），那麼這個事件是冪等的。
我們要意識到事件可能出現的次數和順序是不可預測的，需要保證冪等事件的順序執行，否則結果往往不是我們想要的。
如果我們先後收到兩條事件，（1）賬戶餘額更新為100，（2）賬戶餘額更新為120。
1. 微服務收到事件（1）
2. 微服務收到事件（2）
3. 微服務再次收到事件（1）
顯然結果是錯誤的，所以我們需要保證事件（2）一旦執行事件（1）就不能再處理，否則賬戶餘額仍不是我們想要的結果。
為保證事件的順序一個簡單的做法是在事件中新增時間戳，微服務記錄每型別的事件最後處理的時間戳，如果收到的事件的時間戳早於我們記錄的，丟棄該事件。如果事件不是在同一個伺服器上發出的，那麼伺服器之間的時間同步是個難題，更穩妥的做法是使用一個全域性遞增序列號替換時間戳。
對於本身不具有冪等性的操作，主要思想是為每條事件儲存執行結果，當收到一條事件時我們需要根據事件的 ID 查詢該事件是否已經執行過，如果執行過直接返回上一次的執行結果，否則排程執行事件。
在這個思想下我們需要考慮重複執行一條事件和查詢儲存結果的開銷。
重複處理開銷小的事件
如果重複處理一條事件開銷很小，或者可預見只有非常少的事件會被重複接收，可以選擇重複處理一次事件，在將事件資料持久化時由資料庫丟擲唯一性約束異常。
重複處理開銷大事件使用事件儲存過濾重複事件
如果重複處理一條事件的開銷相比額外一次查詢的開銷要高很多，使用一個過濾服務來過濾重複的事件，過濾服務使用事件儲存儲存已經處理過的事件和結果。
當收到一條事件時，過濾服務首先查詢事件儲存，確定該條事件是否已經被處理過，如果事件已經被處理過，直接返回儲存的結果；否則排程業務服務執行處理，並將處理完的結果儲存到事件儲存中。
一般情況下上面的方法能夠執行得很好，如果我們的微服務是 RPC 類的服務我們需要更加小心，可能出現的問題在於，（1）過濾服務在業務處理完成後才將事件結果儲存到事件儲存中，但是在業務處理完成前有可能就已經收到重複事件，由於是 RPC 服務也不能依賴資料庫的唯一性約束；（2）業務服務的處理結果可能出現位置狀態，一般出現在正常提交請求但是沒有收到響應的時候。
對於問題（1）可以按步驟記錄事件處理過程，比如事件的記錄事件的處理過程為“接收”、“傳送請求”、“收到應答”、“處理完成”。好處是過濾服務能及時的發現重複事件，進一步還能根據事件狀態作不同的處理。
對於問題（2）可以通過一次額外的查詢請求來確定事件的實際處理狀態，要注意額外的查詢會帶來更長時間的延時，更進一步可能某些 RPC 服務根本不提供查詢介面。此時只能選擇接收暫時的不一致，時候採用對賬和人工接入的方式來保證一致性。
補償模式
為了描述方便，這裡先定義兩個概念：
-
業務異常：業務邏輯產生錯誤的情況，比如賬戶餘額不足、商品庫存不足等。
-
技術異常：非業務邏輯產生的異常，如網路連線異常、網路超時等。
補償模式使用一個額外的協調服務來協調各個需要保證一致性的微服務，協調服務按順序呼叫各個微服務，如果某個微服務呼叫異常（包括業務異常和技術異常）就取消之前所有已經呼叫成功的微服務。
補償模式建議僅用於不能避免出現業務異常的情況，如果有可能應該優化業務模式，以避免要求補償事務。如賬戶餘額不足的業務異常可通過預先凍結金額的方式避免，商品庫存不足可要求商家準備額外的庫存等。
我們通過一個例項來說明補償模式，一家旅行公司提供預訂行程的業務，可以通過公司的網站提前預訂飛機票、火車票、酒店等。
假設一位客戶規劃的行程是:
-
上海-北京6月19日9點的某某航班。
-
某某酒店住宿3晚。
-
北京-上海6月22日17點火車。
在客戶提交行程後，旅行公司的預訂行程業務按順序序列的呼叫航班預訂服務、酒店預訂服務、火車預訂服務。最後的火車預訂服務成功後整個預訂業務才算完成。
如果火車票預訂服務沒有呼叫成功，那麼之前預訂的航班、酒店都得取消。取消之前預訂的酒店、航班即為補償過程。
為了降低開發的複雜性和提高效率，協調服務實現為一個通用的補償框架。補償框架提供服務編排和自動完成補償的能力。
要實現補償過程，我們需要做到兩點：
首先要確定失敗的步驟和狀態，從而確定需要補償的範圍。
在上面的例子中我們不僅要知道第 3 個步驟（預訂火車）失敗，還要知道失敗的原因。如果是因為預訂火車服務返回無票，那麼補償過程只需要取消前兩個步驟就可以了；但是如果失敗的原因是因為網路超時，那麼補償過程除前兩個步驟之外還需要包括第 3 個步驟。
其次要能提供補償操作使用到的業務資料。
比如一個支付微服務的補償操作要求引數包括支付時的業務流水 id、賬號和金額。理論上說實際完成補償操作可以根據唯一的業務流水 id 就可以，但是提供更多的要素有益於微服務的健壯性，微服務在收到補償操作的時候可以做業務的檢查，比如檢查賬戶是否相等，金額是否一致等等。
做到上面兩點的辦法是記錄完整的業務流水，可以通過業務流水的狀態來確定需要補償的步驟，同時業務流水為補償操作提供需要的業務資料。
當客戶的一個預訂請求達到時，協調服務（補償框架）為請求生成一個全域性唯一的業務流水號，並在呼叫各個工作服務的同時記錄完整的狀態。
-
記錄呼叫 bookFlight 的業務流水，呼叫 bookFlight 服務，更新業務流水狀態。
-
記錄呼叫 bookHotel 的業務流水，呼叫 bookHotel 服務，更新業務流水狀態。
-
記錄呼叫 bookTrain 的業務流水，呼叫 bookTrain 服務，更新業務流水狀態。
當呼叫某個服務出現異常時，比如第 3 步驟（預訂火車）異常。
協調服務（補償框架）同樣會記錄第 3 步的狀態，同時會另外記錄一條事件，說明業務出現了異常。然後就是執行補償過程了，可以從業務流水的狀態中知道補償的範圍，補償過程中需要的業務資料從記錄的業務流水中獲取。
對於一個通用的補償框架來說，預先知道微服務需要記錄的業務要素是不可能的。那麼就需要一種方法來保證業務流水的可擴充套件性，這裡介紹兩種方法：大表和關聯表。
大表顧明思議就是設計時除必須的欄位外，還需要預留大量的備用欄位，框架可以提供輔助工具來幫助將業務資料對映到備用欄位中。
關聯表，分為框架表和業務表，技術表中儲存為實現補償操作所需要的技術資料，業務表儲存業務資料，通過在技術表中增加業務表名和業務表主鍵來建立和業務資料的關聯。
大表對於框架層實現起來簡單，但是也有一些難點，比如預留多少欄位合適，每個欄位又需要預留多少長度。另外一個難點是如果向從資料層面來查詢資料，很難看出備用欄位的業務含義，維護過程不友好。
關聯表在業務要素上更靈活，能支援不同的業務型別記錄不同的業務要素；但是對於框架實現上難度更高，另外每次查詢都需要複雜的關聯動作，效能方面會受影響。
有了上面的完整的流水記錄，協調服務就可以根據工作服務的狀態在異常時完成補償過程。但是補償由於網路等原因，補償操作並不一定能保證 100%成功，這時候我們還要做更多一點。
補償過程作為一個服務呼叫過程同樣存在呼叫不成功的情況，這個時候需要通過重試的機制來保證補償的成功率。當然這也就要求補償操作本身具備冪等性。
關於冪等性的實現在前面做過討論。
如果只是一味的失敗就立即重試會給工作服務造成不必要的壓力，我們要根據服務執行失敗的原因來選擇不同的重試策略。
1) 如果失敗的原因不是暫時性的，由於業務因素導致（如業務要素檢查失敗）的業務錯誤，這類錯誤是不會重發就能自動恢復的，那麼應該立即終止重試。
2) 如果錯誤的原因是一些罕見的異常，比如因為網路傳輸過程出現數據丟失或者錯誤，應該立即再次重試，因為類似的錯誤一般很少會再次發生。
3) 如果錯誤的原因是系統繁忙（比如 HTTP 協議返回的 500 或者另外約定的返回碼）或者超時，這個時候需要等待一些時間再重試。
重試操作一般會指定重試次數上線，如果重試次數達到了上限就不再進行重試了。這個時候應該通過一種手段通知相關人員進行處理。
對於等待重試的策略如果重試時仍然錯誤，可逐漸增加等待的時間，直到達到一個上限後，以上限作為等待時間。
如果某個時刻聚集了大量需要重試的操作，補償框架需要控制請求的流量，以防止對工作服務造成過大的壓力。
另外關於補償模式還有幾點補充說明。
-
微服務實現補償操作不是簡單的回退到業務發生時的狀態，因為可能還有其他的併發的請求同時更改了狀態。一般都使用逆操作的方式完成補償。
-
補償過程不需要嚴格按照與業務發生的相反順序執行，可以依據工作服務的重用程度優先執行，甚至是可以併發的執行。
-
有些服務的補償過程是有依賴關係的，被依賴服務的補償操作沒有成功就要及時終止補償過程。
-
如果在一個業務中包含的工作服務不是都提供了補償操作，那我們編排服務時應該把提供補償操作的服務放在前面，這樣當後面的工作服務錯誤時還有機會補償。
-
設計工作服務的補償介面時應該以協調服務請求的業務要素作為條件，不要以工作服務的應答要素作為條件。因為還存在超時需要補償的情況，這時補償框架就沒法提供補償需要的業務要素。
TCC模式（Try-Confirm-Cancel）
一個完整的 TCC 業務由一個主業務服務和若干個從業務服務組成，主業務服務發起並完成整個業務活動，TCC 模式要求從服務提供三個介面：Try、Confirm、Cancel。
1. Try
完成所有業務檢查
預留必須業務資源
2. Confirm
真正執行業務
不作任何業務檢查
只使用 Try 階段預留的業務資源
Confirm 操作滿足冪等性
3. Cancel：
釋放 Try 階段預留的業務資源
Cancel 操作滿足冪等性
整個 TCC 業務分成兩個階段完成。
第一階段：主業務服務分別呼叫所有從業務的 try 操作，並在活動管理器中登記所有從業務服務。當所有從業務服務的 try 操作都呼叫成功或者某個從業務服務的 try 操作失敗，進入第二階段。
第二階段：活動管理器根據第一階段的執行結果來執行 confirm 或 cancel 操作。
如果第一階段所有 try 操作都成功，則活動管理器呼叫所有從業務活動的 confirm操作。否則呼叫所有從業務服務的 cancel 操作。
需要注意的是第二階段 confirm 或 cancel 操作本身也是滿足最終一致性的過程，在呼叫 confirm 或 cancel 的時候也可能因為某種原因（比如網路）導致呼叫失敗，所以需要活動管理支援重試的能力，同時這也就要求 confirm 和 cancel 操作具有冪等性。
在補償模式中一個比較明顯的缺陷是，沒有隔離性。從第一個工作服務步驟開始一直到所有工作服務完成（或者補償過程完成），不一致是對其他服務可見的。另外最終一致性的保證還充分的依賴了協調服務的健壯性，如果協調服務異常，就沒法達到一致性。
TCC模式在一定程度上彌補了上述的缺陷，在TCC模式中直到明確的confirm動作，所有的業務操作都是隔離的（由業務層面保證）。另外工作服務可以通過指定 try 操作的超時時間，主動的 cancel 預留的業務資源，從而實現自治的微服務。
TCC模式和補償模式一樣需要需要有協調服務和工作服務，協調服務也可以作為通用服務一般實現為框架。與補償模式不同的是 TCC 服務框架不需要記錄詳細的業務流水，完成 confirm 和 cancel 操作的業務要素由業務服務提供。
在第4步確認預訂之前，訂單只是pending狀態，只有等到明確的confirm之後訂單才生效。
如果3個服務中某個服務try操作失敗，那麼可以向TCC服務框架提交cancel，或者什麼也不做由工作服務自己超時處理。
TCC 模式也不能百分百保證一致性，如果業務服務向 TCC 服務框架提交 confirm後，TCC 服務框架向某個工作服務提交 confirm 失敗（比如網路故障），那麼就會出現不一致，一般稱為 heuristic exception。
需要說明的是為保證業務成功率，業務服務向 TCC 服務框架提交 confirm 以及TCC 服務框架向工作服務提交 confirm/cancel 時都要支援重試，這也就要confirm/cancel 的實現必須具有冪等性。如果業務服務向 TCC 服務框架提交confirm/cancel 失敗，不會導致不一致，因為服務最後都會超時而取消。
另外 heuristic exception 是不可杜絕的，但是可以通過設定合適的超時時間，以及重試頻率和監控措施使得出現這個異常的可能性降低到很小。如果出現了heuristic exception 是可以通過人工的手段補救的。
對賬是最後的終極防線
如果有些業務由於瞬時的網路故障或呼叫超時等問題，通過上文所講的 3 種模式一般都能得到很好的解決。但是在當今雲端計算環境下，很多服務是依賴於外部系統的可用性情況，在一些重要的業務場景下還需要週期性的對賬來保證真實的一致性。比如支付系統和銀行之間每天日終是都會有對賬過程。
作者介紹
朱江，普元解決方案中心總經理。2003 年畢業於河海大學，2007 年加入普元資訊科技股份有限公司，長期致力於金融軟體平臺建設實踐。主持完成多個金融行業平臺產品及解決方案的研發工作，包括業務整合平臺、集中監控平臺、統一渠道接入平臺等。對金融行業技術架構有較深刻理解，曾主持中國工商銀行、建設銀行、中信銀行、國開銀行等多家大型企業的技術平臺規劃與落地，目前負責普元解決方案中心，負責基於普元標準產品打造行業解決方案。