無狀態微服務和數據庫

Question

我們需要構建無狀態微服務，這些服務依賴於數據庫集群來持久化數據。

使用數據庫集群建議的冗余無狀態微服務（用於高可用性和可伸縮性）的方法是什么。 例如：運行1.0版支付服務的多個副本。

是否所有冗余微服務都使用通用的共享數據庫模式，或者它們應該有自己的模式？ 在獨立DB模式的情況下，可能存在冗余服務之間的不一致。

在常見的數據庫模式的情況下，如何處理模式升級？

Answer 1

這是一個超級廣泛的主題，而且一般來說很難回答。

然而...

微服務架構的關鍵要求是每個服務應獨立於其他服務。 您應該能夠獨立於其他服務部署，修改，改進，擴展您的微服務。

這意味着您不希望共享API定義以外的任何內容。 你當然不想共享架構; 每個服務都應該能夠定義自己的模式，發布新版本，更改數據類型等，而無需檢查其他服務。 使用共享模式幾乎是不可能的。

您可能不想共享物理服務器。 共享服務器意味着您無法在可伸縮性和正常運行時間方面做出獨立承諾; 微服務方法的很大一部分意味着構建它的團隊也負責運行它。 你真的想避免“好吧，它在開發中工作，所以如果它不能在生產上擴展，那就是運營團隊的問題”的態度。 數據庫 - 尤其是集群冗余數據庫 - 可能很昂貴，因此如果您確實需要， 可能會對此有所妥協。

由於大多數微服務解決方案都使用容器化和雲托管，因此您不太可能擁有“一個數據庫服務器來統治它們”。 您可能會發現讓每個微服務運行自己的持久性服務而不是共享更好。

處理不一致的常用方法是接受它們 - 但是使用CQRS在微服務之間分配數據，並確保微服務處理其內部一致性要求。

這也涉及“我在發布新版本時應該升級數據庫嗎？” 題。 如果您的觀察者了解每條消息的版本，他們可以決定如何存儲它們。 例如，如果版本1.0使用1.1版的不同屬性集，則偵聽器可以執行映射。

在評論中，您詢問一致性。 這是一個非常復雜的主題 - 尤其是在微服務架構中。

例如，如果您有“客戶”服務和“訂單”服務，則必須確保所有訂單都有有效客戶。 在單個應用程序中，使用單個數據庫和專門的同步交互，這很容易在數據庫級別強制執行。

在微服務架構中，您可能擁有大量數據存儲，彼此之間沒有依賴關系，以及同步和異步調用的組合，這真的很難。 這是減少微服務之間依賴性的不可避免的副作用。

最常見的方法是“ 最終一致性 ”。 這通常需要稍微不同的應用程序設計。 例如，在“訂單”屏幕上，您將首先調用客戶端微服務（以獲取客戶端數據），然后調用“訂單”服務（以獲取訂單詳細信息），而不是單個（大）服務調用來檢索一切。