何時發送消息（基於JMS的代理/隊列）過度消耗？根據經紀人

Question

JMS是解耦系統一個非常有用的工具。然而，架構和膨脹之間的細線總是跨越。作爲一個理論上了解經紀人，但沒有實踐經驗的人，我可以給予什麼建議以避免「膨脹」。應該注意哪些性能因素，設計考慮因素和系統特徵，以便經紀人不會被誤用。例如使用經紀人推動事件到日誌服務似乎是一個矯枉過正的事情（我的一個朋友實際上幾乎暗示了這一點）。另一個例子 - 創建審計服務（審計多個後端系統）時，（異步）消息傳遞是一個很好的解決方案。優點和缺點？

Answer 1

它的規模的所有問題。

只要你有一些服務項目，都在同一機器上運行，或者也許幾箱，但所有通信只是一個數據庫，然後消息並不能解決任何實際問題，只會增加複雜性。

一旦你有很多的服務，在多個服務器上（也可能是多個數據中心）運行，這種需要（只是一個數據庫，而不是），相互溝通，信息成爲必要。

另一種情況是，當你的服務有不同的發佈時間表，尤其是當有許多和他們由不同的團隊開發的。它達到了釋放同步的程度，以確保兼容性並將停機時間降至最低。異步消息傳遞是解決方案的一部分。

最後，推異步事件的日誌記錄服務有一定道理，因爲上述條件。如果您使用某些公司範圍的日誌記錄服務在多臺服務器上運行多個服務，則日誌隊列非常合理。