定義微服務邊界

Question

我已經開始學習和構建基於微服務的項目，但我總是陷入范圍界定的情況並最終創建了一種單體應用程序。 在我下面的 foo-bar 示例中，請建議應該是什么范圍以及如何實現所需的 output。

服務或表格

• 雇員
• 部門
• 員工-部門-映射

假設

Employee或Department之間沒有任何交叉引用所有關系都在第三個表中維護Employee-Department-Mapping關系可以是One-To-Many或Many-To-Many基於企業對企業，在本例中是One-To-Many （有員工的部門）

要求

我想獲得部門支付的總工資。 類似於下面的查詢，這里我對 3 個表進行簡單的連接。 這只有在所有都在同一個數據庫和單個微服務中時才有可能。

Select d.DepartmentName, SUM(e.salary) 
from Employee e, Department d, Employee-Department-Mapping c 
where d.DepartmentName == c.DepartmentName 
AND e.Employee == c.Employee 
Group By c.DepatmentId 

約束

• 員工表有工資信息
• 員工部門關系由第三張表維護。

我不是在尋找確切的答案，而是在尋找解決此類問題的方法。 想知道如果您需要聚合輸出，您將如何設計您的微服務，您會將所有這些表放在單個微服務中嗎？ 我不想從每個微服務中提取數百萬條記錄並在 memory 中進行聚合。

Answer 1

微服務邊界——如果你沒有任何其他可擴展性原因——應該由業務定義。 在這種特殊情況下 - 在不知道任何其他要求的情況下 - 我會說你應該 go 用於管理這兩個實體的一個微服務。 話雖如此，我有足夠的經驗知道在現實世界中這個解決方案並不總是可行和可能的。 幸運的是，您可以遵循一些模式來解決您所描述的情況。 例如，CQRS 可以是解決方案https://dzone.com/articles/microservices-with-cqrs-and-event-sourcing 。

Answer 2

你必須在這里改變你對微服務的想法。 我可以在這里提出的是

• 您必須多次調用不同的微服務並返回一個結果，您可以使用API 網關模式。 您必須編寫一個聚合器服務來通過兩個 API 服務聚合兩個表的 output。

• 如果您不喜歡上述選項，您將不得不對數據庫進行非規范化並在您的員工表中包含部門名稱。 這就是我們在微服務中使用 NoSQL 的原因。