2
我试图设计一个实时监控&控制系统是模块化的，因此它可以为不同的硬件网络分配和扩展/重新配置。经纪和非经纪消息系统的优点和缺点
我很快得出结论，我需要某种分布式企业消息传递系统。但是有很多选择，每个都有优点和缺点，其中一些选项决定了不同的体系结构。我试图弄清楚我是否需要经纪商或无代理系统，是否需要某些系统（例如RabbitMQ）的消息可靠性或像ZeroMQ这样的系统的轻量级高吞吐量，还是需要“按顺序到达” Kafka的高吞吐量。
首先，这些体系结构是否有意义？
ZeroMQ类型 “Brokerless” 系统：
注：
可以有许多 “A部分” 每个 “B部分”，以及许多“部分B“喂入”C部分“
优点：
- 高吞吐量，低letancy
- 容易地集成到组件，轻便部署（无需部署经纪人）。
缺点
- 消息不能保证传递。有些可能会被丢弃。这可能是橙色突出显示区域中的问题。这对于GUI并不重要，但是如果本地控制模块正在作出决定，它可能需要需要所有信息。 （想想看，最新的可能就足够了 - 没有必要用过时的数据做出决定）。同样，如果A和B之间的网络出现故障，历史记录将具有不完整的历史记录。这有多关键？
- 没有“发现”。组件之间的关系需要更多的管理。
RabbitMQ的类型代理系统：
优点：
- 消息保证递送。
- 通过经纪人进行管理。
缺点
- 慢得多，高延迟
- 更多部署&维持（经纪人/ RabbitMQ的需要安装的机器，它不只是内置的模块）
Inbetween opti ons：
我看了卡夫卡。它的代理，所以发现照顾。但是，它看起来比RabbitMQ轻巧得多，虽然它不能保证传输（因此速度更快/延迟更低），但它确实维持了RabbitMQ所不具备的顺序。它还缓冲消息 - 因此如果有网络问题可以检索它们。
写下来之后，我不确定保证交货的重要性。如果控制模块收到消息，如果它是“旧”，则无关紧要。如果这位历史学家有完整的历史将会很棒 - 但它至关重要吗？
在ZeroMQ中实现我自己的“消息缓冲区”可能是一个选项，用于在发生故障时存储消息的网络通信。我比RabbitMQ拥有更多的控制权，并且可以在我需要通过更不可靠的（通过网络）进行消息传递时实施它。
显然，衡量这些优点或缺点是我的工作。我的问题是：还有什么可以考虑的吗？和这两个选项的架构是否有意义？
我计划大多数实现是在C＃中，而我目前在消息传递系统方面没有任何经验。