2
我試圖設計一個實時監控&控制系統是模塊化的，因此它可以爲不同的硬件網絡分配和擴展/重新配置。經紀和非經紀消息系統的優點和缺點
我很快得出結論，我需要某種分佈式企業消息傳遞系統。但是有很多選擇，每個都有優點和缺點，其中一些選項決定了不同的體系結構。我試圖弄清楚我是否需要經紀商或無代理系統，是否需要某些系統（例如RabbitMQ）的消息可靠性或像ZeroMQ這樣的系統的輕量級高吞吐量，還是需要「按順序到達」 Kafka的高吞吐量。
首先，這些體系結構是否有意義？
ZeroMQ類型 「Brokerless」 系統：
注：
可以有許多 「A部分」 每個 「B部分」，以及許多「部分B「喂入」C部分「
優點：
- 高吞吐量，低letancy
- 容易地集成到組件，輕便部署（無需部署經紀人）。
缺點
- 消息不能保證傳遞。有些可能會被丟棄。這可能是橙色突出顯示區域中的問題。這對於GUI並不重要，但是如果本地控制模塊正在作出決定，它可能需要需要所有信息。 （想想看，最新的可能就足夠了 - 沒有必要用過時的數據做出決定）。同樣，如果A和B之間的網絡出現故障，歷史記錄將具有不完整的歷史記錄。這有多關鍵？
- 沒有「發現」。組件之間的關係需要更多的管理。
RabbitMQ的類型代理系統：
優點：
- 消息保證遞送。
- 通過經紀人進行管理。
缺點
- 慢得多，高延遲
- 更多部署&維持（經紀人/ RabbitMQ的需要安裝的機器，它不只是內置的模塊）
Inbetween opti ons：
我看了卡夫卡。它的代理，所以發現照顧。但是，它看起來比RabbitMQ輕巧得多，雖然它不能保證傳輸（因此速度更快/延遲更低），但它確實維持了RabbitMQ所不具備的順序。它還緩衝消息 - 因此如果有網絡問題可以檢索它們。
寫下來之後，我不確定保證交貨的重要性。如果控制模塊收到消息，如果它是「舊」，則無關緊要。如果這位歷史學家有完整的歷史將會很棒 - 但它至關重要嗎？
在ZeroMQ中實現我自己的「消息緩衝區」可能是一個選項，用於在發生故障時存儲消息的網絡通信。我比RabbitMQ擁有更多的控制權，並且可以在我需要通過更不可靠的（通過網絡）進行消息傳遞時實施它。
顯然，衡量這些優點或缺點是我的工作。我的問題是：還有什麼可以考慮的嗎？和這兩個選項的架構是否有意義？
我計劃大多數實現是在C＃中，而我目前在消息傳遞系統方面沒有任何經驗。