最近參與公司項目研發(fā)，在其中發(fā)現(xiàn)對于數(shù)據(jù)的管理存在一些小問題，根據(jù)以往經(jīng)驗，在這里記錄下微服務(wù)數(shù)據(jù)設(shè)計模式。

微服務(wù)架構(gòu)中的服務(wù)是松耦合的，可以獨立開發(fā)、部署和擴展。每個微服務(wù)都需要不同類型的數(shù)據(jù)和存儲方式，也因為這樣每個微服務(wù)都有自己的數(shù)據(jù)庫。

一、每個服務(wù)的數(shù)據(jù)庫

每個微服務(wù)都有自己的數(shù)據(jù)庫，可以自由選擇如何管理數(shù)據(jù)。

1、每個服務(wù)都有一個數(shù)據(jù)庫的好處

• 松耦合，各自服務(wù)可以更加專注自己的專業(yè)領(lǐng)域
• 自由選擇數(shù)據(jù)庫類型，如 MySQL 等 RDBMS、Cassandra 等寬列數(shù)據(jù)庫、MongoDB 等文檔數(shù)據(jù)庫、Redis 等鍵值存儲和 Neo4J 等圖形數(shù)據(jù)庫。

是否需要為每個服務(wù)使用不同的數(shù)據(jù)庫服務(wù)器？這不是一個硬性要求。讓我們看看我們能做些什么。

2、如果您使用的是 RDMS，那么就包括以下特性：

• 專用表—每個服務(wù)擁有一組表，只能由該服務(wù)訪問。
• 專用數(shù)據(jù)庫架構(gòu)—每個服務(wù)都有一個私有的數(shù)據(jù)庫架構(gòu)。
• 專用數(shù)據(jù)庫服務(wù)器—每個服務(wù)都有自己的數(shù)據(jù)庫服務(wù)器。

3、每個服務(wù)都有一個數(shù)據(jù)庫的挑戰(zhàn)

需要連接多個數(shù)據(jù)庫的查詢?—以下數(shù)據(jù)模式可以克服這一挑戰(zhàn)。

• 事件溯源
• API 組成
• 命令查詢職責分離 (CQRS)

跨多個數(shù)據(jù)庫事務(wù)?—為了解決這個問題，我們可以使用Saga 模式。

二、事件溯源

通過事件溯源，業(yè)務(wù)實體的狀態(tài)由一系列狀態(tài)變化的事件跟蹤。每當業(yè)務(wù)實體的狀態(tài)發(fā)生變化時，都會將新事件添加到事件列表中。由于保存事件是一個單一的操作，它本質(zhì)上是原子的。通過重放事件，應(yīng)用程序重建實體的當前狀態(tài)。

應(yīng)用程序?qū)⑹录４嬖谑录鎯χ?，事件存儲是事件?shù)據(jù)庫?？梢允褂闷?API 從存儲中添加和檢索事件。事件存儲也充當消息代理。服務(wù)可以通過其 API 訂閱事件。當服務(wù)在事件存儲中保存一個事件時，它會發(fā)送給所有感興趣的訂閱者。當實體有大量事件時，應(yīng)用程序可以定期保存實體當前狀態(tài)的快照以優(yōu)化加載。應(yīng)用程序查找最近的快照以及自該快照以來發(fā)生的事件以重建當前狀態(tài)。這減少了要重播的事件的數(shù)量。

1、事件溯源的好處

1. 使用它解決了事件驅(qū)動架構(gòu)的關(guān)鍵挑戰(zhàn)之一，并使得在狀態(tài)變化時可靠地發(fā)布事件。
2. 避免了對象關(guān)系阻抗不匹配問題，持久化事件而不是域?qū)ο蟆?/li>
3. 對實體提供 100% 可靠的審計日志。
4. 允許執(zhí)行確定實體在任何時間點的狀態(tài)的時間查詢。
5. 基于事件溯源的業(yè)務(wù)邏輯涉及交換事件的松散耦合實體。使從單體應(yīng)用程序遷移到微服務(wù)架構(gòu)變得容易得多。

2、事件溯源的缺點

1. 有一定學習成本，目前還是一種不太成熟的技術(shù)。
2. 查詢事件存儲很困難，需要一個典型的查詢來重建實體狀態(tài)。可能會導致低效和復雜的查詢。因此，應(yīng)用程序必須使用命令查詢職責分離 (CQRS) 來實現(xiàn)查詢。反過來，這意味著應(yīng)用程序必須處理最終一致的數(shù)據(jù)。

三、API 組成

您可以使用 API 組合模式實現(xiàn)從多個服務(wù)中檢索數(shù)據(jù)的查詢操作。在這個模式中，通過調(diào)用擁有數(shù)據(jù)的服務(wù)然后組合結(jié)果來實現(xiàn)查詢操作。

1、API 組合的好處

在微服務(wù)架構(gòu)中查詢數(shù)據(jù)的一種便捷方式。

2、API組合的缺點

有時，查詢會導致大型數(shù)據(jù)集的低效內(nèi)存連接。

四、命令查詢職責分離 (CQRS)

RDBMS 通常用作記錄事務(wù)系統(tǒng)和文本搜索數(shù)據(jù)庫，例如用于文本搜索查詢的 Elasticsearch 或 Solr。一些應(yīng)用程序通過同時寫入兩者來保持數(shù)據(jù)庫同步。其他人定期將數(shù)據(jù)從 RDBMS 復制到文本搜索引擎?；诖思軜?gòu)構(gòu)建的應(yīng)用程序利用了多個數(shù)據(jù)庫的優(yōu)勢、RDBMS 的事務(wù)屬性以及文本數(shù)據(jù)庫的查詢能力。CQRS 概括了這種架構(gòu)。

微服務(wù)架構(gòu)在實現(xiàn)查詢時面臨三個常見挑戰(zhàn)。

1. 使用 API 組合模式檢索分散在多個服務(wù)中的數(shù)據(jù)，從而導致成本高昂且效率低下的內(nèi)存連接。
2. 數(shù)據(jù)以不能有效支持擁有數(shù)據(jù)的服務(wù)所需查詢的格式或數(shù)據(jù)庫中存儲。
3. 分離關(guān)注點意味著擁有數(shù)據(jù)的服務(wù)不應(yīng)該負責實現(xiàn)查詢操作。

這三個問題都可以通過使用 CQRS 模式來解決。

CQRS 的主要目標是分離或分離關(guān)注點。因此，持久數(shù)據(jù)模型分為兩部分：命令端和查詢端。

創(chuàng)建、更新和刪除操作由命令端模塊和數(shù)據(jù)模型實現(xiàn)。查詢由查詢端模塊和數(shù)據(jù)模型實現(xiàn)。通過訂閱命令行發(fā)布的事件，查詢端保持其數(shù)據(jù)模型與命令端同步

1、CQRS 的好處

1. 實現(xiàn)高效查詢實現(xiàn)—如果您使用 API 組合模式來實現(xiàn)查詢，您可能會遇到大型數(shù)據(jù)集的高成本、低效的內(nèi)存連接。對于這些查詢，使用預(yù)先來自連接兩個或更多服務(wù)數(shù)據(jù)的CQRS 視圖更有效。
2. 能夠有效實現(xiàn)多種查詢—通常很難使用單一持久數(shù)據(jù)模型來支持所有查詢。在CQRS 中，定義一個或多個視圖有效地實現(xiàn)特定查詢，消除了單個數(shù)據(jù)存儲的限制。
3. 實現(xiàn)基于事件溯源的應(yīng)用程序中查詢—CQRS 還克服了事件溯源的一個重要限制。事件存儲僅支持基于主鍵的查詢。CQRS 模式通過定義一個或多個聚合視圖來解決此限制，這些視圖通過訂閱由事件源聚合發(fā)布的事件流來保持最新。
4. 關(guān)注點分離改進—域模型和持久數(shù)據(jù)模型不支持命令和查詢。CQRS 將服務(wù)的命令和查詢端分離為單獨的代碼模塊和數(shù)據(jù)庫模式。

2、CQRS 的缺點

1. 更復雜的架構(gòu)—為了更新和查詢視圖，開發(fā)者需要編寫查詢端服務(wù)。應(yīng)用程序可能使用不同類型的數(shù)據(jù)庫，這增加了開發(fā)人員和 DevOps 的復雜性。
2. 處理復制延遲—在從命令端發(fā)布事件到由查詢端處理事件以及更新視圖之間存在延遲。

五、Saga模式

使用 sagas，您可以在不使用分布式事務(wù)的情況下保持微服務(wù)架構(gòu)中數(shù)據(jù)的一致性。您為跨多個服務(wù)更新數(shù)據(jù)的每個命令定義一個 saga。saga 是一系列本地事務(wù)。本地事務(wù)使用ACID事務(wù)框架更新單個服務(wù)中的數(shù)據(jù)。

Sagas 利用補償事務(wù)來回滾更改。假設(shè)saga的第n個交易失敗。必須撤消前 (n-1) 個事務(wù)。結(jié)果，總共 (n-1) 個補償事務(wù)將被啟動以以相反的順序回滾更改。

1、Saga協(xié)調(diào)

為了實現(xiàn)一個 saga，它需要邏輯來協(xié)調(diào)其步驟。一旦系統(tǒng)命令啟動了一個 saga，協(xié)調(diào)邏輯必須選擇并指示第一個 saga 執(zhí)行本地事務(wù)。一旦該事務(wù)完成，編排協(xié)調(diào)就會選擇并調(diào)用下一個 saga 參與者。這個過程一直持續(xù)到傳奇完成。如果本地事務(wù)失敗，saga 必須以相反的順序執(zhí)行補償事務(wù)。

2、有幾種方法可以構(gòu)建 saga 的協(xié)調(diào)邏輯：

編排?：在saga的參與者之間分配決策和排序。他們主要通過交換事件進行通信。

（1）基于編排的saga優(yōu)勢

1. 簡單性—當創(chuàng)建、更新或刪除業(yè)務(wù)對象時，服務(wù)會發(fā)布事件。
2. 簡單依賴關(guān)系—不引入循環(huán)依賴關(guān)系。
3. 松耦合—服務(wù)實現(xiàn)由編排器調(diào)用的 API，因此它不需要知道 saga 參與者發(fā)布的事件。
4. 簡化業(yè)務(wù)邏輯—在 saga 編排器中，saga 協(xié)調(diào)邏輯是本地化的。領(lǐng)域?qū)ο蟛恢浪鼈兯婕暗?sagas。

（2）基于編排的缺點

1. 更難理解—編排將 saga 的實現(xiàn)分布在服務(wù)之間，每個服務(wù)都是獨立的這就需要每個管理對每個服務(wù)都需要了解。
2. 服務(wù)之間的循環(huán)依賴—saga 參與者訂閱彼此的事件，這通常會產(chǎn)生循環(huán)依賴。
3. 緊密耦合的風險—saga的參與者必須訂閱所有影響他們的事件。

編排?—一個 saga 的協(xié)調(diào)邏輯應(yīng)該集中在一個 saga 編排器類中。在 saga 期間，編排器向參與者發(fā)送命令消息，告訴他們應(yīng)該執(zhí)行哪些操作。