微服務的【資料庫管理】最佳實踐

0 概述

什麼是微服務資料管理模式?

微服務資料管理模式幫助管理軟體不同元件的資料。資料管理模式方便兩個或多個軟體元件的資料庫之間的通訊。

資料管理模式

1. Database per service pattern
2. Shared database pattern
3. API Composition pattern
4. Saga Pattern
5. CQRS Pattern
6. Event Sourcing Pattern
7. Database Sharding Pattern

1 每個服務一個DB

每個微服務都有其自己的私有資料庫，使服務松耦合。

每個服務一個資料庫模式易於使用，適用於新應用程式。微服務模式提供：

• 高可擴充套件性
• 資料庫之間的松耦合
• 簡單的影響分析

優點

隔離和獨立性

每個微服務都有專用資料庫,這確保了資料的完全隔離。這種隔離允許每個服務獨立執行,而不會干擾其他服務。一個微服務資料庫的更改和更新不會影響其他微服務。

自治開發和部署

微服務團隊可以自主地在各自的服務和資料庫上工作。這種自治性導致了更快的開發和部署週期,因為團隊可以在不與其他團隊協調的情況下發布更新。

技術靈活性

不同的微服務可以使用最適合其特定需求的資料庫技術。這種靈活性意味著您可以為一個微服務選擇關聯式資料庫,為另一個微服務選擇 NoSQL 資料庫,或者甚至根據要求選擇快取機制。

可擴充套件性

擴充套件簡化了,因為每個微服務可以根據其獨特的需求獨立擴充套件其資料庫。遭受高流量或資料負載的服務可以擴充套件其資料庫,而不會影響其他服務。

減少耦合

透過避免微服務之間的直接資料庫訪問,可以減少它們之間的耦合。微服務透過定義良好的 API 相互互動,這允許松耦合並更大的靈活性來更改服務。

顯著優勢,包括增加的敏捷性、可擴充套件性、獨立性和改進的資料管理。然而,也帶來挑戰,如確保資料一致性並實現微服務之間有效的通訊模式,需仔細考慮和實施。

2 共享DB（Shared Database Pattern）

建立單一的資料庫，該資料庫由不同的微服務共享。

建立一個單一的共享資料庫,每個服務使用本地ACID 事務訪問資料。但這與微服務的本質相矛盾，給應用程式的未來帶來嚴重問題。最後,我們將面臨開發大型單體應用程式而不是微服務的問題。

適用場景

在遺留應用程式中很有用,在讀負載高於寫負載的簡化應用程式中很有用，但當應用程式變大時，遷移到每個服務一個資料庫模式是可行的，因為共享資料庫模式可能導致服務之間緊耦合，在這裡我們不允許使用不同的技術，因為我們有共享資料庫，這可能導致缺乏可擴充套件性和單點故障。

3 API 組合（API Composition pattern）

將來自多個微服務的資料聚合和合併為對客戶端或另一個服務的單個響應。它允許向使用者提供資料的統一檢視，而無需他們對不同的微服務進行多次 API 呼叫。

這簡化客戶端開發，減少延遲並最大限度減少資料的過度獲取和獲取不足。

所以這裡客戶端向閘道器請求，需要由不同微服務處理的所有組合請求都由聚合器傳遞給不同的微服務，最後生成單個響應。

與向不同微服務發出多個請求相比，該模式可減少延遲，因為客戶端可以在一次請求中檢索所有必要的資料,從而減少往返時間。在這裡,客戶端不需要處理複雜的邏輯來從多個源中獲取和合並資料,這使得客戶端程式碼更簡單、更容易維護。

4 長事務（Saga Pattern）

管理分散式事務場景中微服務之間資料一致性的方法。Saga 是一系列更新每個服務併發布訊息或事件以觸發下一個事務步驟的事務。若某步失敗，saga 將執行補償事務來抵消前面事務的效果。

正如每個服務一個DB模式：每個微服務都有自己的DB，但不滿足ACID。

構建一個電商，客戶有一個信用限額。應用程式須確保新訂單不會超過客戶信用限額。由於訂單和客戶位於不同服務擁有的資料庫，應用程式無法簡單使用本地 ACID 事務。

為解決這問題，踢出 Saga 模式。

Saga 模式使用一系列本地事務提供事務管理。本地事務是 saga 參與者執行的原子工作量。每個本地事務更新資料庫併發布訊息或事件以觸發 saga 中的下一個本地事務。若本地事務失敗，saga 將執行一系列補償事務,這些事務將撤消先前本地事務所做的更改。

saga 實現方法

協調

一種協調 saga 的方法，其中參與者相互交換事件,沒有集中的控制點。

編排

一種協調 saga 的方式,其中集中控制器告訴 saga 參與者執行哪些本地事務。

5 CQRS

命令查詢職責隔離，軟體架構中常用的一種設計模式，特別適用於具有複雜資料處理需求的系統。CQRS 將：

• 處理命令(更改資料)
• 查詢(檢索資料)

的職責分離到不同的元件。對讀寫操作具有不同效能、擴充套件和最佳化要求的場景，這種模式尤有價值。

關鍵概念和元件

命令

表示修改資料或執行某種狀態更改操作的操作。示例包括建立、更新或刪除記錄。命令會傳送到命令處理程式,後者處理命令並可能對系統的資料進行更改。

命令處理程式

負責接收和處理命令。它包含驗證、執行和將更改應用於資料儲存的邏輯。處理命令後,它可能會生成事件來通知系統其他部分所做的更改。

事件

表示系統狀態更改的不可變事實。當它們成功處理命令時,由命令處理程式生成。事件捕獲更改背後的意圖,並且通常儲存在事件儲存中,以進行審計和作為系統狀態的真實來源。

事件儲存

用於事件的持久儲存系統。它保留了系統中發生的所有事件的歷史記錄。事件溯源是一種緊密相關的模式,它使用事件儲存透過重播事件來重建應用程式的狀態。

查詢

代表不更改其狀態的讀取操作。查詢處理程式負責處理查詢並將結果返回給客戶端。與命令處理程式不同,查詢處理程式不修改資料。

模型分離

CQRS 系統中,通常在用於寫入的模型(命令模型)和用於讀取的模型(查詢模型)之間進行分離。這些模型可以獨立最佳化以執行各自的任務。

工作方式

① 命令處理

• 客戶端向相應的命令處理程式傳送命令。
• 命令處理程式處理命令,驗證它,應用任何必要的業務邏輯,並可能因此生成事件。
• 生成的事件儲存在事件儲存中併發布以通知系統的其他部分。

②  事件處理

• 事件處理程式偵聽事件並更新查詢模型以及用於查詢處理的任何非規範化資料儲存(例如讀取資料庫或快取)。
• 這種分離允許對查詢模型進行最佳化以進行讀取,與命令模型相比,可能具有不同的資料結構和模式。

查詢處理

• 客戶端向查詢處理程式傳送查詢。
• 查詢處理程式從查詢模型中檢索資料並將結果返回給客戶端。

6 事件溯源（Event Sourcing Pattern）

事件溯源模式基本為累積事件提供了一種方法並將其聚合到資料庫中的事件序列中。

7 資料庫分片模式（Database Sharding Pattern）

資料分片模式將資料集分離為不同的分片或水平分割槽,以簡化訪問和儲存。微服務資料庫管理模式中的每個分片具有相同的模式,但保留資料的不同子集。

分片模式允許高可擴充套件性,因為在儲存需求增加時,您可以新增新分片。此外,透過減少每個服務的工作負載,還可以提高效能。

8 總結

有效的微服務資料庫管理是成功的微服務架構的關鍵組成部分。透過遵循這些技術和最佳實踐,您可以確保微服務保持可擴充套件、可維護和高效能,同時促進資料一致性和安全性。保持適應能力並持續監控和最佳化資料庫管理策略,以適應微服務生態系統的發展。

參考：