關於Azure Service Fabric應用程序設計的問題

Question

我對微服務架構設計有以下要求。 我的項目是Dot Net Core中的Azure Service Fabric無狀態服務和有狀態服務類型。

該項目中共有3個無狀態服務和3個有狀態服務。

對於每個有狀態服務，我們都創建了一個無狀態服務作為該服務的網關。

我們將數據存儲在有狀態服務中，而通過無狀態我們將發送數據並檢索數據。

出於通信目的，我們將使用服務代理（即IService實現的接口）。

我可以輕松地從stateless1調用stateful1的方法，但是我有一些要求，例如我需要來自stateful1的數據，該數據取決於有狀態2和有狀態3。

在每個有狀態服務之間我都有一些業務邏輯，

目前，我正在statful1上創建Service Proxy，並收集有狀態2和3的所有數據，並且在對所有數據進行計算后將發送給無狀態。

我的問題是，是否最好再有一層稱為存儲庫（無狀態使用的類庫項目），它將與每個有狀態服務聯系並補充業務邏輯？

或者，如果在狀態中使用反邏輯業務邏輯將影響性能，而不是在狀態中使用業務邏輯。

我以3個無狀態和3個有狀態的簡單示例為例，但是實際上我的項目包含50多個服務，每個服務都具有網關和有狀態服務。 在每個有狀態服務之間，我需要編寫更多的業務。

請為我建議執行此要求的更好方法。

Answer 1

您的問題似乎有很多背景，對於讀者而言，並非所有這些背景都是顯而易見的。

在我看來，微服務架構就像拉出工具箱的“大錘”，除非您嘗試通過創建的系統解決的問題無法通過任何其他方式適當解決。

當我聽到您談論50多種服務時，每種服務實際上都有對應的100多種服務，我的第一個懷疑是您的這種體系結構是否設計過度？ 但是話又說回來，正如我已經指出的，缺少很多背景信息，因此我很難真正進行評估。

也許您應該考慮合並有狀態的服務1、2和3是否對您有好處？

您所處的情況可能是這些服務緊密相關的征兆，並且可能會因為合並在一起而受益。

最近我處於類似的情況，其中2個微服務（我認為應該是1個）處理緊密相關的數據，一個是案例服務，另一個是客戶背景檢查服務，該業務要求將數據導出到csv -file，其中所需的輸出csv文件中的每一行都包含案例和客戶背景檢查數據的組合。 實現此目的的唯一方法是遍歷所有案例，並針對每種情況致電客戶后台檢查微服務，這當然是可怕的。 1000例意味着1000次http調用。 但是，如果在一個SQL數據庫中有2個表，那么您可以輕松地想象到用單個聯接查詢可以簡單地解決這個問題。

有時少即是多。