architecture - 代理与非代理消息系统的优缺点

Question

我正在尝试设计一个模块化的实时监控系统，因此它可以针对不同的硬件和网络进行分布式和扩展/重新配置。

我很快得出结论，我需要某种分布式企业消息传递系统。但是有很多选择，每种都有优点和缺点，其中一些决定了不同的架构。我正在尝试确定我是否需要代理或无代理系统，是否需要某些系统(例如 RabbitMQ)的消息可靠性或 ZeroMQ 等系统的轻量级高吞吐量，或者“按顺序到达” Kafka 的高吞吐量。

首先，这些架构有意义吗？

ZeroMQ 类型“无代理”系统:



笔记:

每个“B 部分”可以有许多“A 部分”，并且许多“B 部分”馈入“C 部分”

优势:

高吞吐量、低延迟

轻松集成到组件中，轻量级部署(无需部署代理)。

缺点

邮件不保证送达。有些可能会被丢弃。这可能是橙色突出显示区域中的问题。这对 GUI 来说并不重要，但如果本地控制模块正在做出决定，它可能需要所有信息。 (想想看，最新的可能就足够了——用过时的数据做出决定是没有意义的)。类似地，如果 A 和 B 之间的网络出现故障，历史学家将拥有不完整的历史。但这有多重要？

没有“发现”。需要更多地管理组件之间的关系。

RabbitMQ 类型 Broker 系统:



优势:

消息保证送达。

通过经纪人管理发现。

缺点

慢得多，延迟高

更多的部署和维护(brokers/RabbitMQ 需要安装在机器上，它不只是内置在模块中)

中间选项:

我看过卡夫卡。它是中介的，所以发现会得到照顾。然而，它似乎比 RabbitMQ 更轻量级，虽然它不保证交付(因此更快/更低的延迟)，但它确实保持秩序，而 RabbitMQ 没有。它还缓冲消息 - 因此如果出现网络问题，可以检索它们。

写下来之后，我不确定保证交付的重要性。如果控制模块收到一条消息，如果它是“旧的”，则无关紧要。如果历史学家有完整的历史，那就太好了——但这是否必要？

在 ZeroMQ 中实现我自己的“消息缓冲区”可能是一种选择，用于在发生故障时存储消息的网络通信。我将拥有比 RabbitMQ 更多的控制权，并且可以在我需要它以通过更不可靠的(通过网络)进行消息传递时实现它。

显然，权衡这些优点或缺点是我的工作。我的问题是:还有什么需要考虑的吗？这两个选项的架构是否有意义？

我计划在 C# 中实现大多数实现，而我目前在消息传递系统方面的经验为零。

Answer 1

实时和 保证消息传递实际上是不可能的。如果一个系统真的需要实时数据(例如股票交易算法)，那么它更关心的是获得具有最低延迟的最新价格，而不是高延迟交付保证。

我认为您应该查看您的系统并将其分解为以下组件:

需要实时(实时控制、决策)

需要可靠(历史数据库)

看你的图我认为你对两个消息系统有很好的要求

zeromq 用于实时控制部分

kafka 用于保证交付历史/数据库部分。

顺便说一句，zmq 发现很容易通过几个冗余的 zmq 代理和某种形式的 DNS 解决。