架構模式: 共享數據庫

上下文

讓我們假設您正在使用微服務架構模式開發在線商店應用程序。大多數服務需要在某種數據庫中保存數據。例如，訂單服務存儲有關訂單的信息，而客戶服務存儲有關客戶的信息。

問題

微服務應用程序中的數據庫體系結構是什么？
 

要點

• 服務必須松散耦合，以便可以獨立開發，部署和擴展

• 某些業務事務必須強制執行跨多個服務的不變量。例如，下訂單用例必須驗證新訂單不會超過客戶的信用額度。其他業務事務，必須更新多個服務所擁有的數據。

• 某些業務事務需要查詢由多個服務擁有的數據。例如，查看可用信用使用必須查詢客戶以查找creditLimit和Orders以計算未結訂單的總金額。

• 某些查詢必須連接由多個服務擁有的數據。例如，查找特定區域中的客戶及其最近的訂單需要客戶和訂單之間的聯接。

• 有時必須復制和分割數據庫才能擴展。請參閱比例立方體。

• 不同的服務有不同的數據存儲要求。對於某些服務，關系數據庫是最佳選擇。其他服務可能需要NoSQL數據庫，例如MongoDB，它擅長存儲復雜的非結構化數據，或Neo4J，用於高效存儲和查詢圖形數據。

結論

使用由多個服務共享的（單個）數據庫。每個服務使用本地ACID事務自由訪問其他服務擁有的數據。

例子

OrderService和CustomerService可以自由訪問彼此的表。例如，OrderService可以使用以下ACID交易，確保新訂單不會違反客戶的信用額度。

BEGIN TRANSACTION
…
SELECT ORDER_TOTAL
 FROM ORDERS WHERE CUSTOMER_ID = ?
…
SELECT CREDIT_LIMIT
FROM CUSTOMERS WHERE CUSTOMER_ID = ?
…
INSERT INTO ORDERS …
…
COMMIT TRANSACTION

即使同時交易試圖為同一客戶創建訂單，數據庫也將保證不會超過信用額度。

結果上下文

這種模式的好處是：

• 開發人員使用熟悉且直接的ACID事務來強制數據一致性
• 單個數據庫操作起來更簡單

這種模式的缺點是：

• 開發時間耦合 - 例如，處理OrderService的開發人員需要與訪問相同表的其他服務的開發人員協調模式更改。這種耦合和額外的協調將減緩發展。

• 運行時耦合 - 因為所有服務都訪問同一個數據庫，所以它們可能會相互干擾。例如，如果長時間運行的CustomerService事務在ORDER表上保持鎖定，則OrderService將被阻止。

• 單個數據庫可能無法滿足所有服務的數據存儲和訪問要求。

關聯模式

• 每個服務數據庫是一種替代方法