在開發或軟件架構的過程中，經常會遇到數據一致性的問題。尤其是在微服務架構下，每個微服務都有自己的數據庫，導致微服務架構的系統不能簡單地滿足 ACID，我們就需要尋找微服務架構下的數據一致性解決方案。
傳統情況下，當一個事務要跨越多個分佈式服務時，開發者想到的第一個方案就是兩階段提交——2PC。在這個過程中，事務協調者（事務管理器）給每個參與者（資源管理器）發送 Prepare 消息，如果參與者有可用資源，對數據加鎖，如果所有參與者都返回成功，就執行第二階段，否則，執行回滾操作。
由於數據庫通常比業務服務更難擴容，而兩階段提交需要依賴於數據庫實現，並且對數據加鎖，所以性能較低，應用並不是十分廣泛。
那麼，如何保證微服務架構中的數據一致性？華爲雲 PaaS 團隊架構師王啓軍老師提到了幾個方面：
1. 可靠事件通知模式
該模式下，一種通知模式是同步事件，即主服務完成後將結果通過事件（以消息隊列爲主）傳遞給服務，進而完成業務流程，達到主服務與服務間的消息一致性。另一種是異步事件，即業務服務和事件服務解耦，需要將提交失敗的事件進行重試，目前業界多數採用本地消息表 +MQ 的方式來進行重試，但也因此對數據庫產生壓力。
2. 使用 Saga 保證微服務的最終一致性
Saga 將一個跨服務的事務拆分成多個事務，每個子事務都需要定義一個對應的補償操作。通過異步的模式來完成整個 Saga 流程。具體操作是將項目創建流程拆分成多個 Saga，併爲 Saga 分配一個事務管理器。當服務啓動時，會將服務中所有的 SagaTask 註冊到管理器中。在業務執行時，執行狀態可以通過事務管理器進行查看。
3. TCC/Try Confirm Cancel 模式
在 TCC 模式下，當一個服務提交失敗時，可以做到完全補償，且在補償後不留下補償記錄。這樣可以在業務層處理時，平衡數據庫的壓力。但其代價也在於增加了業務的複雜度，需要提供相應的 Try、Confirm、Cancel 接口等。
4. 華爲雲分佈式事務服務—DTM
DTM 是華爲雲分佈式事務管理中間件，它的具體步驟是，先由實物發起者向 DTM 集羣申請註冊一個全局事務的 ID，並透傳到所調用的事務參與者中，事務參與者利用得到的 ID 向 DTM 集羣註冊申請一個分事務 ID，在事務參與者完成自身業務邏輯後，將結果上傳至 DTM 集羣，並示意分支事務結束，在後續完成 TCC 二階段後，DTM 集羣通稿事務發起者全局事務結束。具體流程如下圖所示：
最後，王啓軍老師總結：不是所有的地方對一致性要求都這麼高，要根據自己的業務需求來選擇一致性的模型。一致性沒有絕對的，更嚴格的一致性只是降低概率而已，更高的一致性需要更高的成本，需要企業綜合考慮。
除了一致性話題之外，王老師將在 12 月 7 日北京 ArchSummit 全球架構師峯會上分享《反應式微服務框架 Apache ServiceComb 設計思想》的話題，介紹 Reactive 編程模型帶來的好處，以及在微服務架構下，如何快速建立 Reactive 架構。
感興趣可以點擊 https://archsummit.infoq.cn/2019/beijing/track 查看官網瞭解更多議題內容。9 折倒計時20天，團購更優惠哦～詳情聯繫票務經理灰灰：15600537884（同微信）