微服務架構：跨業務的數據共享

Question

考慮以下微服務的在線商店項目：
用戶服務保留有關商店的用戶帳戶數據（包括姓，名，電子郵件地址等「）

採購服務跟蹤用戶購買的細節。

每項服務都提供了用於查看和管理相關實體的UI。 購買服務索引頁面列出購買。每個採購項目應具有以下字段：
id，採購用戶全名，採購項目標題和價格。
此外，作爲索引頁面的一部分，我希望有一個搜索框讓商店經理通過購買用戶名來搜索購物。

我不清楚如何找回購買服務不支持的數據 - 例如：用戶的全名。 當嘗試通過購買用戶名執行更復雜的事情（如搜索購買）時，問題變得更糟。

我想通過在用戶創建時廣播某種事件並在購買服務端只保存相關用戶屬性，我可以明顯解決這個問題。在我看來，這遠非理想。當你有數百萬用戶時，你如何處理這個問題？你會在每個使用用戶數據的服務中創建數百萬條記錄嗎？

另一個顯而易見的選擇是在用戶服務端公開一個API，該API根據給定的ID返回用戶詳細信息。這意味着購買服務中的每個頁面加載，我都必須撥打用戶服務以獲取正確的用戶名稱。不理想，但我可以忍受它。

如何根據用戶名實現購買搜索？那麼我總是可以在接收查詢條件的用戶服務端公開另一個API端點，在用戶服務中對用戶名執行文本搜索，然後返回符合條件的所有用戶詳細信息。在採購服務中，將相關ID映射回正確的名稱並在頁面中顯示。這種方法也不理想。

我錯過了什麼嗎？是否有另一種方法來實現上述？也許我面臨這個問題的事實是一種代碼味道？很想聽聽其他解決方案。

Answer 1

將適當的數據保存在不同的數據庫中是完全正常的，它被稱爲Polyglot Persistence。是的，您希望分開保存關於購買的用戶數據和數據，並使用消息隊列進行同步。數百萬用戶對我來說似乎很好，它的可擴展性，而不是設計問題;-)

在搜索的情況下 - 你可能想搜索更多的用戶名，對嗎？因此，例如，如果您使用消息隊列更新服務之間的數據，則還可以輕鬆地將此數據路由到ElasticSearch。從ElasticSearch的角度來看，索引什麼字段 - 用戶名或產品標題並不重要。

Answer 2

當進入微服務時，這似乎是一個非常常見的問題。我希望有一個很好的答案:-)

關於這裏已經提到的建議模式，我會使用術語數據非規範化而不是多邊形持久性，因爲它不一定需要在不同的持久性技術中。重點是每個服務處理自己的數據。是的，你有數據重複，你通常需要某種事件總線來跨服務共享數據。

還有另一種選擇，這是一種第一種 - 將搜索本身作爲單獨的服務使用。

因此，在您的示例中，您擁有用於管理用戶的用戶服務。採購服務管理採購。每個處理它自己的數據並僅處理它需要的數據（所以，例如，購買服務並不需要用戶名，只需要ID）。而且你有第三項服務 - 搜索服務 - 消耗其他服務產生的數據，並從組合數據創建搜索「視圖」。

Answer 3

我通常使用這兩種方法。有時候我有另一種服務在x其他服務上排在前列，並將數據結合在一起。我不太喜歡這種方法，因爲它會導致服務之間的依賴關係和耦合。所以一般來說，在我最後的項目中，我們試圖堅持多邊形持久性。

另外想一想，如果您需要在某種中間件服務中使用x sub http請求來組合數據，則會導致更高的延遲。我們總是儘量減少一個任務的請求數量，並通過異步隊列處理所有可能的事情。 （特別是數據同步）