何時適合實現了系統中的「脊樑」？

Question

據我所知，一些軟件系統實現消息總線或「刺」。對於哪些應用程序適合這種技術，爲什麼？

Answer 1

那麼這一切都取決於你的需要。

例如，如果您有客戶端/服務器應用程序，並且想要提供Pub/Sub語義的實時更新。那麼消息總線是理想的，因爲你不想重新發明車輪。

如果您有需要排隊等待運行的進程，您也可以使用消息總線，因爲您可以將所有項目轉儲到隊列中，並且進程監聽將根據需要進行處理。

我們傾向於爲交易系統使用消息總線，但它可用於需要向多個客戶端發送消息的任何事情。這是一個有點矯枉過正，如果你只是一個單一的客戶端/服務器應用程序，你並不需要所有的客戶端保持最新。

但是這一切都取決於您的使用場景，所以很難說。查看消息總線提供的信息，看看它是否在你的應用程序環境中提供任何幫助。問問自己，你可以使用簡單的服務提供相同的事情，你需要一個Pub/Sub模型，你需要有保證的消息傳遞，消息確認如何。你只是要求提供只讀數據還是數據輸入系統？是否有涉及的工作流程可以從消息總線等獲益，等等。

最重要的是看看這些系統提供什麼，看看它是否適合你。但也要看看容量，可用性，可維護性等等。您可以根據一個簡單的場景找到多個解決方案，這些解決方案都可以從部分像這樣的東西中受益，但對於小型項目可能超級過度。

Answer 2

我從來沒有聽說過「脊柱」。然而，一個共同的架構是一個Enterprise Service Bus (ESB)。

通常情況下，當您有許多不同的組件需要訂閱從其他組件發送的消息時，請使用此選項。通常在斷開狀態下（火和忘記），但有時您需要回復。

ESB不是處理雙向通信的高速方式。

Biztalk是一個這樣的系統的例子。還有很多其他的，你可以明顯地編碼你自己的。

一個示例需求是訂單管理和計費系統。假設客戶下訂單。訂單的通知可以在公交車上發送。如果你有單獨的計費和執行系統，則可能總線的傳播完成消息給每個那些沒有訂購系統知道它是怎麼去收取費用，甚至誰去完成它。