由於Microservices中缺乏ACID交易屬性，跨多個Microservices API管理交易的數據完整性是一個巨大的挑戰。本文分享了解決此問題的方法。
在單體應用程序中，單個數據庫由各種應用程序模塊共享。所以，通過ACID交易管理，數據完整性很容易維護。
以Microservices的方式對單體應用進行再造，將它們分解成許多單個且獨立的服務。每個服務都有自己的數據庫。這使得數據完整性管理異常困難。
有幾種方法可以解決這個問題。其中一種方法是在Kafka, RibbitMQ或ActiveMQ等消息代理中使用發布和訂閱模型。
在這裏，我們將討論這種方法如何解決基於Microservices的應用程序中的分布式交易管理及其優缺點。
只讀交易
當API"X"收到讀取請求時，它會將同步的讀取事件推送到消息隊列中。訂閱事件的API會從隊列中檢索消息，從自己的數據庫中讀取相應的數據，然後將結果推送到返回隊列中。
由於這是一個同步調用，API「X」將等待直到收到所有返回消息，然後它將整體結果返回給它的使用者。如果在收到所有返回消息之前超時，它將向使用者返回帶有部分結果的錯誤。
該方法的優點是可擴展性。通過啟動更多的讀取API實例，您可以在高負載環境下保持系統吞吐量。缺點是解決方案的復雜性和成本。
CRUD交易
CURD (創建、更新、讀取、刪除) 交易類似於只讀交易。當API"X"收到CRUD請求時，它會將同步或異步的CRUD交易推送到消息隊列中。那些訂閱事件的API將檢索消息並在他們自己的數據庫中執行CRUD交易。
對於同步的CRUD交易，這些下遊API通過返回隊列將結果推送回API"X"。API"X"將等待所有事件狀態直到超時，並向其使用者返回成功或失敗的狀態。
對於異步CRUD交易，API"X"不會等待交易完成，一旦它將所有CRUD事件推送到消息隊列中，它就會向其使用者返回完成狀態。
這種方法的優點是實現簡單，可擴展性強。但是，它的缺點是可能由於服務故障而導致數據完整性問題。
最終一致性
顯然，當任何CRUD服務失敗時，所描述的方法可能會導致數據完整性問題。因此，我們需要一個錯誤恢復過程來維護最終一致性。
基本的恢復解決方案是定期跨不同數據庫運行的數據協調過程。核對過程將標記出所有存在數據完整性問題的記錄和字段。
另一種解決方案是日誌掃描和分析。這個解決方案需要分布式日誌和監控機製，我們在上一篇文章中已經討論過。通過掃描和分析日誌，我們可以識別所有失敗的事務。
有了失敗的交易信息或存在數據完整性問題的記錄，我們可以手動或自動糾正數據。
最終一致性的優點是簡單，而缺點是會存在數據不一致的時間窗口，這對於需要高度數據一致性的系統（例如匯款）是不能接受的。
在接下來的文章中，我們將討論如何為需要高度數據一致性的系統處理分布式交易。敬請關註。
緯泓是香港、新加坡和中國的頂級金融科技企業。自1998年以來，我們一直在幫助金融機構實施全球銀行解決方案
Copyright © 2021 緯泓 版權所有，不得轉載