在微服務架構中的數據一致性
當從傳統的單體應用架構轉移到微服務架構時，特別是涉及數據一致性時，數據一致性是微服務架構中最困難的部分。傳統的單體應用中，一個共享的關係型數據庫負責處理數據一致性。在微服務架構中，如果使用 “每個服務一個數據庫” 的模式，那麼每個微服務都有自己的數據存儲。因此，數據庫在應用程序之間是分佈式的。如果每個應用程序使用不同的技術來管理它們的數據，比如非關係型數據庫，這種分佈式架構雖然在數據管理方面有許多好處，比如可伸縮性、高可用性、靈活性等，但在數據管理方面也存在一些關鍵問題，比如事務管理、數據一致性 / 完整性等方面。
問題：分佈式系統中的數據一致性
對於單體應用程序，通過 ACID 事務，一個共享的關係型數據庫處理並保證數據的一致性。ACID 是一個縮寫，具體含義如下：
•A 原子性：事務的所有步驟要麼全部成功，要麼全部失敗，沒有部分狀態，全有或全無。•C 一致性：事務結束時數據庫中的所有數據都是一致的。•I 隔離性：同一時間只有一個事務可以訪問數據，其他事務必須等待當前事務完成。•D 持久性：數據在事務結束時被持久化到數據庫中。
爲了保持強數據一致性，關係型數據庫管理系統支持 ACID 特性。
但在微服務架構中，每個微服務都有自己的數據存儲，並採用不同的技術。因此，沒有中央數據庫，也沒有單一的工作單元。業務邏輯被跨越到多個本地事務中。這意味着你不能在微服務架構中的數據庫之間使用單一的事務工作單元。但你仍然需要在你的應用程序中使用 ACID 特性。
讓我們用一個簡單的樣例場景來解釋。在一個訂單管理系統中，可能存在庫存管理、支付和訂單管理等服務。假設這些服務都按照微服務架構設計，並應用了 “每個服務一個數據庫” 的模式。爲了完成訂單流程，訂單服務首先調用庫存管理服務進行庫存控制和預留，訂單中的相關產品被預留，以防止賣給其他客戶。第二步是支付步驟。支付服務負責支付業務。訂單服務調用支付服務，從客戶的信用卡中完成支付。由於每個服務都是獨立的，對分離的數據庫的更新在服務範圍內被提交。最後一步是創建訂單記錄。在這一步中，假設發生了技術錯誤，訂單記錄無法創建，訂單號無法發送給客戶，但已從客戶那裏收到了付款。這裏出現了數據一致性問題。接下來我會在文章的 “可能的解決方案” 部分討論在這一點之後可以做些什麼。
可能的解決方案
首先，沒有一種單一的解決方案適用於所有情況。根據具體情況，可以採用不同的解決方案。
解決問題有兩種主要方法：
• 分佈式事務 • 最終一致性
分佈式事務
在分佈式事務中，事務在兩個或多個資源上執行（例如數據庫、消息隊列）。通過分佈式事務管理器或協調器，跨多個數據庫保證數據的完整性。
分佈式事務是一個非常複雜的過程，因爲涉及多個資源。
兩階段提交（2PC） 是一種阻塞協議，用於保證在分佈式事務中所有事務要麼全部成功，要麼全部失敗。
XA 標準 是 2PC 分佈式事務的規範。JTA 包括 Xtandard API。符合 JTA 標準的應用服務器支持 Xtandard API。但所有資源必須部署到單個 JTA 平臺才能運行 2PC。對於微服務架構來說，這不太合適。
分佈式事務的優點
• 強的數據一致性 • 支持 ACID 特性
分佈式事務的缺點
• 維護起來非常複雜 • 由於是阻塞過程（不適合高負載場景），高延遲和低吞吐量 • 事務之間可能出現死鎖 • 事務協調器是一個單點故障
最終一致性
最終一致性是分佈式系統中用於實現高可用性
的模型。在一個最終一致性的系統中，允許一段時間的不一致，直到解決分佈式數據的問題。
這個模型不適用於跨多個微服務的分佈式 ACID 事務。最終一致性使用 BASE 數據庫模型。
雖然 ACID 模型提供了一個一致的系統，但 BASE 模型提供了高可用性。
BASE 這個縮寫代表：
•Basically Available：通過在數據庫集羣的節點之間複製數據來確保數據的可用性 •Soft-state：由於缺乏強一致性，數據可能隨時間變化。一致性責任委託給開發人員。•Eventual consistency：BASE 不可能立即提供一致性，但最終會提供一致性（在短時間內）。
SAGA 是一種操作最終一致性模型的常見模式。
• 基於協同的 SAGA：在這種情況下，不存在中央協調器。每個服務在其任務完成後產生一個事件，並且每個服務監聽事件以採取行動。這種模式需要一個成熟的事件驅動架構。• 事件溯源：使用事件存儲來存儲事件變化狀態的方法。事件存儲是充當事件數據庫的消息代理。通過重新播放來自事件存儲的事件來重建狀態。• 基於協同的 SAGA 模式在事務中步驟較少時可以很好地工作（例如 2 到 4 個步驟）。當事務中的步驟數量增加時，很難跟蹤哪些服務監聽哪些事件。• 基於編排的 SAGA：協調器服務（Saga 執行編排器，SEG）負責根據業務邏輯對事務進行排序。編排器決定應執行哪些操作。如果某個操作失敗，編排器會撤銷先前的步驟。這稱爲補償操作。補償是在系統保持一致狀態時發生故障時要執行的操作。• 當數據已被不同的事務更改時，撤銷更改可能已經不可能。• 補償必須是冪等的，因爲在重試機制中可能會被調用多次。• 必須小心設計補償。
有一些可用的框架可以實現 Saga 編排模式，例如 Camunda、Apache Camel。
SAGA 的優點
• 在本地原子事務中執行非阻塞操作 • 事務之間沒有死鎖 • 沒有單點故障
SAGA 的缺點
• 最終的數據一致性 • 沒有讀隔離，需要額外的努力（例如，用戶可能會看到操作已完成，但在幾秒鐘後由於補償事務被取消）• 當參與服務數量增加時，調試困難 • 開發成本增加（需要實際服務開發以及補償服務開發）• 設計複雜
在維護分佈式數據存儲之間的數據一致性可能非常困難。在設計新應用程序時需要有不同的思維方式。我們可以說，數據一致性的責任從數據庫轉移到了應用程序級別。
選擇哪種解決方案
解決方案取決於使用案例和一致性要求。總的來說，應考慮以下設計考慮因素。
- 儘可能避免在微服務之間使用分佈式事務。使用分佈式事務會帶來更復雜的問題。2. 設計你的系統，儘可能不要求分佈式一致性。爲了實現這一點，識別事務邊界；• 識別必須在同一工作單元中工作的操作。對於這種類型的操作使用強一致性 • 識別可以容忍一致性方面的可能延遲的操作。對於這種類型的操作使用最終一致性 3. 考慮使用事件驅動架構進行異步非阻塞服務調用 4. 通過補償和協調過程設計容錯系統，以保持系統的一致性 5. 最終一致性模式需要在設計和開發方面進行思維方式的轉變
結論
微服務架構具有諸如高可用性、可伸縮性、自動化、自治團隊等很多優點。爲了最大程度地發揮微服務架構風格的效率，傳統方法需要進行一些改變。數據和一致性管理是需要仔細設計的。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/mJaURcj-KM6RHR67zFdbJg