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