【发布时间】：2017-01-24 13:55:18
【问题描述】：
我正在尝试设计一个模块化的实时监控和控制系统，以便它可以针对不同的硬件和网络进行分布式和扩展/重新配置。
我很快得出结论，我需要某种分布式企业消息传递系统。但是有很多选择，每种都有优点和缺点，其中一些决定了不同的架构。我正在尝试确定我是否需要代理或无代理系统，是否需要某些系统（例如 RabbitMQ）的消息可靠性或 ZeroMQ 等系统的轻量级高吞吐量，或者“按顺序到达” Kafka 的高吞吐量。
首先，这些架构有意义吗？
ZeroMQ 类型“无代理”系统：
注意事项：
每个“B 部分”可以有很多“A 部分”，而“C 部分”可以有很多“B 部分”
优点：
- 高吞吐量、低延迟
- 轻松集成到组件中，轻量级部署（无需部署代理）。
缺点
- 邮件无法保证送达。有些可能会被丢弃。这可能是橙色突出显示区域中的问题。这对 GUI 来说并不重要，但如果本地控制模块正在做出决定，它可能需要所有信息。 （想想看，最新的可能就足够了——用过时的数据做出决定是没有意义的）。类似地，如果 A 和 B 之间的网络出现故障，历史学家将拥有不完整的历史。但这有多重要？
- 没有“发现”。需要更好地管理组件之间的关系。
RabbitMQ 类型 Broker 系统：
优点：
- 消息保证送达。
- 通过代理管理发现。
缺点
- 慢得多，延迟高
- 更多的部署和维护（brokers/RabbitMQ 需要安装在机器上，它不只是内置在模块中）
中间选项：
我看过卡夫卡。它是中介的，所以发现会得到照顾。然而，它似乎比 RabbitMQ 更轻量级，虽然它不保证交付（因此更快/更低的延迟），但它确实保持了秩序，而 RabbitMQ 没有。它还可以缓冲消息，以便在出现网络问题时检索它们。
写下来之后，我不确定保证交付的重要性。如果控制模块收到一条消息，如果它是“旧的”，那没关系。如果历史学家有完整的历史，那就太好了 - 但它是必不可少的吗？
在 ZeroMQ 中实现我自己的“消息缓冲区”可能是一个选项，用于在发生故障时存储消息的网络通信。我将拥有比 RabbitMQ 更多的控制权，并且可以在我需要它以通过更不可靠的（通过网络）进行消息传递时实现它。
显然，权衡这些优点或缺点是我的工作。我的问题是：还有什么需要考虑的吗？和这两个选项的架构是否有意义？
我计划在 C# 中实现大多数实现，而我目前在消息传递系统方面的经验为零。
【问题讨论】：
标签： architecture message-queue