为发布者和订阅者使用不同的消息代理是否正确

Question

在软件架构中使用 ZeroMQ 作为发布者和 RabbitMQ 作为订阅者是否正确？

Publisher 使用 ZeroMQ 作为消息代理，而我的 Node.js 应用程序需要使用 RabbitMQ 订阅主题（因为 RabbitMQ 节点包不需要先决条件，因为 ZeroMQ需要安装python & .NET 框架）。

此外，Publisher 使用不同的 ZeroMQ 库，而不是 Node.js 所需的库。

Answer 1

谈论建筑？

Prologue:

首先要注意的是，ZeroMQ 是一个无代理 消息传递/信令框架。如果您的架构需要 Broker，您要么必须从其他 COTS 架子中挑选，要么自行实现自定义特定的 Broker-factory。

The Tower of Babel:

部署先决条件不足以成为停止思考或牺牲基本操作逻辑的理由。

如果一个人认为 专有协议 A sender 与 专有协议 B receiver 先验互连是一个公平的假设，那么很难帮助或解释问题的根本原因。

虽然 ZeroMQ 文档包含一组已发布的 ZMQ-Protocol-Proposals，但它们的起源来自其各自的 RFC 状态，但没有明确的保证，AFAIK，另一个“结束-the-phone-line" 理解并在ZeroMQ 规范内与"remote-caller" 充分合作，除非协议设计所有者确保双方同意的兼容性（如果有人承担了这样的责任，这将得到很好的推广）努力，由于缺乏任何商业动机的理由来开发产品只是为了声明与另一个协议引擎的兼容性，这很难成为现实，这在 FOSS 领域已经被广泛采用了大约十年）。

对不起，这不会飞。

How to repair the flawed architecture?

最好的办法是寻求最小公倍数 - 让所有异构系统能够使用相同的消息传递/信令框架（共享有保证的交叉兼容协议套件，不同的版本可能并且确实会出现在此类设计中，因为到外部约束）。

通常首选具有轻量资源要求、几乎线性可扩展、极速/低延迟和最低先决条件的候选人：

• ZeroMQ
• nanomsg

将是我第一次测试架构以在系统范围内部署它们。

Good Hunt!