微服務架構：查詢服務或數據備份

Question

TL; DR服務是否應該選擇將數據保存在本地數據庫中，或者每次從數據源發出的服務請求數據？

讓我們來看一個網絡商店/訂購應用程序的一般示例。服務A是用戶會話管理服務。它處理用戶正在做什麼的業務邏輯，他可以做什麼等等。用戶可以創建自己的襯衫以供購買。服務B是一個數據聚合器，包含大量的庫存和可用的數據。

用戶開始創建一件襯衫，因此服務來自服務B的請求，可用的樣式/顏色。服務B發送服務A然後顯示給用戶的可能選擇的列表。用戶然後選擇一個，定製它並移動到新的襯衫上。再次，服務A必須從服務B請求什麼樣式/顏色可用。

現在讓我們假設在用戶會話的生命週期內，這些樣式/顏色不會改變，我們知道這將是一次又一次檢索的相同數據。不僅僅是這個用戶，而是所有的用戶。因此，在這種情況下，由於樣式/顏色實際上是服務B的域的一部分，所以他們應該呆在那裏並住在那裏，或者建議防止所有這些不必要的呼叫，並且在第一次請求（暫時）保存在服務A中用於會話生命週期的數據以防止聊天服務。

這是一個過分簡化的例子，但問題仍然是現實世界。哪個更適合架構這種設計？ 這通常適用於某些相當靜態的數據正在通過某些服務時，並且此服務將在這些事務的生命週期內再次需要此數據幾次。所以我不確定服務是否應該在生命週期中臨時保存它，以知道數據不會改變，或者不關心它是否在生命週期內發生變化，或者選擇更多健談的服務並且每次都要求提供請求。

Answer 1

有一個不同的解決方案，「副作用」這種權衡。

您的問題表明您正在考慮採用「舊」「面向服務」方式。也就是說，服務基本上是提供數據的面向數據的服務。如「庫存」，「會話」，「客戶」等。

另一種方法是，根據業務領域分解應用程序，這與DDD有界上下文非常相似。這導致了一個完全不同的體系結構，其中數據不會與其上運行的函數分離。有點像面向對象。

這會導致Shirt-Configurator擁有自己的數據庫，其中包含會話，庫存等所有相關信息。還包括UI。

另一個應用程序可能是結帳。結帳可以是一個完全獨立的應用程序，只需將URL返回到襯衫配置器即可獲得適當的展示。 Checkout應用程序不需要打電話甚至不知道襯衫配置器。

等等......

更多關於這種風格的架構：http://scs-architecture.org/

Answer 2

我必須讚揚你的精心撰寫的問題，但當然，答案在很大程度上取決於你處理的業務邏輯。這個問題與最終一致性（一些非sql數據庫提供的屬性 - 如Couchbase）有關。

最終，它是一個折中的問題：檢索最新數據的「成本」與使用一些容易獲得的陳舊數據的成本。

幾件事因素：

• 多久數據更新？

• 更重要的是，當您使用陳舊的數據時會發生什麼（商業邏輯）。您的用戶/應用程序甚至可以接受嗎？

• 每次獲取新數據會對系統產生什麼影響？這樣做的基礎設施成本是多少（以機器/貨幣計算），它會產生什麼樣的延遲？

Answer 3

TL; DR應該在服務選擇在它需要偶爾，或者從該數據源於服務每次請求數據的本地數據庫中保存的數據？

我不想說這個，但它取決於。這取決於您的業務需求。這取決於你是否想要有一個rezilient系統。如果service B不可用，您希望service A的行爲如何？你有兩個，選項：

1. 你想Service A拒絕工作，因爲它不能從service B獲得新的數據。如果數據變化很大，或者在service A中使用的數據必須始終保持超新，您可以這樣做。

2. 您希望Service A繼續工作，可能是通過通知用戶數據可能不新鮮。在這種情況下，您應該通過監聽事件或緩存，將數據從service B複製到service A。