微服務的其他服務

Question

等待回答，我最近遇到一個問題，當一個人問我，你會在以下情況下做到：

你有服務A，服務B和C業務彼此互動。如果服務A收到來自B和C的響應，它只能執行其全部功能。但是，C有很多請求排隊，並且需要很長時間才能響應。服務A將如何處理這種情況？服務A會等待，等到C收到B的迴應後再回應？你將如何使這個架構更快？

Answer 1

您的C服務是您系統的瓶頸。解決方案如下：

1. Scale C服務。你應該有一個負載平衡器和更多的C服務節點。
2. 將緩存用於C服務結果。
3. 通過將C邏輯拆分爲2個微服務來更改您的體系結構。

Answer 2

有解決這個問題的方法很多，但也許是最簡單的一個是這樣的：

確保服務A已經從C業務需要在 它需要它時的數據。這樣它就不必在 的第一位。

這將要求在過去的某個時候，服務C不得不對其自己的狀態發生變化，以便其他服務可以使用這些更改。這種安排促進了服務的自主性，這是一種說服務不依賴於其他服務的當前狀態的方式。

實現此目的的常用方法是讓服務C在發生內部狀態更改時發佈事件消息。

Answer 3

我看到一個根本性的問題有這樣的說法：如果它收到來自B和C

響應

服務A只能執行其全部功能。如果您的組件（服務）不自主在初始設計中你有一個嚴重的缺陷。分解系統時，您希望最終形成一個邏輯邊界，允許每個「服務」/「組件」自治並明確指定它擁有的系統部分的技術權限。

所以Service A將做的工作並公佈事件Service B訂閱並會做它的位，然後B將發佈一個事件，C將認購的DDO它是業務流程的一部分。

如果他們可以並行完成工作，那麼創建者（發送帶有數據的初始命令的客戶端）可以直接將命令發送給每個組件，並且您可能有一個組件通過訂閱事件來跟蹤業務流程狀態該組件將在完成其工作單元時發佈。

實際的設計是非常依賴於上下文的，所以如果沒有特定的細節就很難分解域。

這有道理嗎？