将 ZeroMQ 驱动的基础模式更改为 REQ/REP¶
https://blueprints.launchpad.net/oslo.messaging/+spec/zmq-req-rep
由于最近提出了许多更改（不仅仅是模式替换），本规范实际上建议提供 ZeroMQ 驱动的并行实现（zmqv2）。 推荐的基础模式是 REQ/REP + ROUTER/DEALER，这将简化驱动程序的实现并提高其可靠性。 实现后，将有可能比较这两种实现。
旧版 zmq 驱动的关键优势在于其向后兼容性以及与旧版本 ZeroMQ 库的兼容性（在进行一些修复后）。
问题描述¶
目前 ZeroMQ 驱动实际上实现了请求-回复模式，但它是基于更原始且不太可靠的 PUSH/PULL 实现的。
主要缺点是 PUSH/PULL 没有反向连接来回复发送者。 我们单向发送消息并忘记。 如果我们想收到回复，我们需要建立另一个连接。 在当前的驱动程序实现中，它是通过 PUB/SUB 完成的。 这导致需要为另一个套接字连接管道提供服务。 更多代码才能使事情正常工作。 连接失败的可能性更高。
更改为 REQ/REP 的主要原因是它“开箱即用”地完成了所有事情。
提议的变更¶
当前的 ZeroMQ 驱动程序实现使用跨服务 zmq_receiver 守护程序作为代理，以便每个节点只有一个 TCP 连接（端口）。 所有消息都到达 TCP 连接，然后通过 IPC 在服务之间传播。 新版本将坚持这种总体架构。
因此，我们有三个部分需要连接
rpc_client (REQ) <=> (ROUTER) zmq_receiver (DEALER) <=> (REP) rpc_server
这足以满足 CALL 方法的要求。
REQ/REP 套接字的优点是它实现了状态机来管理请求/回复，并且在套接字处于“等待回复”状态时发送请求会引发异常。 因此，它理想地匹配 CALL 要求，该要求应阻塞等待回复。
但这对于 CAST 来说很糟糕。 在这里，我们可以用 DEALER 替换 REQ，它是 REQ 的异步等效项。 当我们使用 DEALER 时，我们不需要等待回复，但我们仍然可以接收回复。 我们甚至不需要忽略它们，而是将其用作确认信号，表明 CAST 消息已成功传递。 我们还可以跟踪未确认的消息并在需要时报告它们。 因此，在此步骤中，我们可以看到 REQ/REP 的可靠性高于 PUSH/PULL。 在使用 DEALER 时，REQ 信封需要进行一些操作，但这没有问题，并且在 zmq-guide 中有明确说明。
因此，CAST 的链将如下所示
rpc_client (DEALER) <=> (ROUTER) zmq_receiver (DEALER) <=> (REP) rpc_server
DEALER 也非常适合具有扇出的 CAST。 消息链保持不变。 同样适用于通知程序。
规则很简单：如果我们需要阻塞等待请求，则使用 REQ，否则使用 DEALER 发送异步请求。 ROUTER 是 REP 的异步替代品。
由于我们讨论的是新的驱动程序实现，因此值得一提的是，匹配扇出主题、消息格式、代理守护程序将保留，但会进行重构。 我们将解决诸如 [1]、[2]、[3]、[4]。 [5] 也应在此处应用，但作为优化，在实现完成后。
配置选项和消息传递 API 不应更改，因此我们可以轻松地在 devstack（以及任何其他部署）中使用新的驱动程序代替当前的驱动程序。
备选方案¶
也可以在当前实现中替换模式。
Impact on Existing APIs¶
无。
安全影响¶
无。
性能影响¶
连接数将减少，因此可能会提高性能。
Configuration Impact¶
无。
开发人员影响¶
更少的代码来支持回复。
Testing Impact¶
现有的功能测试应涵盖此更改。
实现¶
负责人¶
- 主要负责人
ozamiatin
里程碑¶
完成目标里程碑：liberty-3
工作项¶
- 实现 CALL 管道和周围的模块
根据 [1] 的包层次结构
将消息序列化、主题操作等从现有实现移动到适当的模块
rpc_client 部分
broker_part
rpc_server 部分
回复处理
实现 CAST
实现扇出
实现通知程序
孵化¶
无。
采用¶
无。
库¶
oslo.messaging。
预计 API 稳定¶
无。
文档影响¶
无。
依赖项¶
无。
参考资料¶
注意
本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
