在跨平台桌面/移动应用程序套件中使用 ZeroMQ 来解决体系结构问题

Question

我需要在跨平台应用程序套件上做出架构决策。我基本上想尝试解耦模块的新方法，并使用 ZeroMQ 实现网络 I/O，因为我知道它是进程内、进程间和网络应用程序的消息队列。但我不确定它如何适合我的情况。

如果有人能在我下周阅读他们那本有趣的书之前澄清几件事，我将不胜感激：http://zguide.zeromq.org/page:all

我已经检查了这些问题，但没有得到我的答案：

• 如何在桌面应用程序中使用 zeroMQ
• 如何在 GTK/QT/Clutter 应用程序中使用 ZeroMQ？

我的要求：

• 桌面主机在视窗和macOS上，作为独立的控制台后端和GUI前端;后端必须用C语言编写;
• iOS和Android上的移动客人，后端用C语言编写;
• 使用TCP与移动设备进行桌面对话;

老办法

至于桌面后端（控制台应用程序），几年前，我的第一步是基于观察者/命令模式编写多线程架构：

• 为 UI 设置主线程并生成一些线程。
一个
• 用于消息处理的“调度程序”线程：一个队列用于从其他模块获取通知，另一个队列用于命令。每种命令类型都会引入自己的依赖项。调度程序泵送消息并相应地发出命令。
• 用于设备监控的其他“执行器”线程，一个桌面和多个移动设备之间的多路复用网络 I/O，所有这些都将消息发送到调度程序以安排实际工作。

然后，我需要实现线程安全的消息队列，并且不可避免地要在调度程序和一堆命令类之间进行耦合，这些命令类本质上只是这些执行器行为的html" target="_blank">函数包装。用C语言，这将是一大堆样板代码。

验证的新方法

但现在是2019年，所以我希望减少手写代码，并尝试一些新的东西。对于ZeroMQ，我想看看我的期望是否成立。我很想。。。

• 只需跨线程在进程内模块之间传递 ZeroMQ 请求，即可消除从 scrach 编写调度程序和消息/命令队列的需要，因为从头开始编写调度既乏味又低效。
• 简化桌面和移动设备之间的网络 I/O。对于这部分，我尝试了 ASIO，它并不比原始套接字和选择方便得多，而且它仅限 C。
将
• GUI和控制台应用程序与基于ZeroMQ的IPC解耦，以便可以使用不同语言的不同技术重写GUI。
• 感知桌面和移动用户的低延迟。

我的期望合理吗？

Answer 1

_{如果刚接触 ZeroMQ 域，请随时查看此内容，最好先了解一下“不到五秒的 ZeroMQ 原则”，然后再深入了解更多详细信息}

上面提到的一篇文章提出了一个假设，即：

ZeroMQ基于这样的假设，即存在一个而（1）…循环，它被插入其中

是完全错误的，误导了任何架构（Architecture）规划/评估工作。

ZeroMQ是一个功能丰富的信令/消息传递元平面，它旨在为应用程序级代码提供大量服务，可以在低级上享受智能、复杂、高效处理的信令/消息传递基础设施的轻量级重用，无论是用于进程内、进程间和节点间多代理分布式方式，都使用许多已经可用的传输级协议来实现这一目标：

{inproc://|ipc://|tipc://|vmci://|tcp://|pgm://|epgm://|udp://}

我的要求：

• cZeroMQ：[PASSED]Windows和macOS上的桌面主机，作为分离的控制台后端和GUI前端；后端必须用C编写；
• cZeroMQ：[PASSED]iOS和Android上的移动来宾，后端用C编写；
• tcpZeroMQ：[PASSED]桌面使用TCP与移动通信；

我很乐意...

< li >通过在线程间的进程内模块之间传递ZeroMQ请求，无需从scrach编写调度程序和消息/命令队列，因为从头编写调度程序既繁琐又低效。 < li >简化台式机和移动设备之间的网络I/O。对于这一部分，我已经尝试了ASIO，它并不比原始的socket和select更方便，而且它只支持C语言。 < li >使用基于ZeroMQ的IPC分离GUI和控制台应用程序，以便可以使用各种语言的不同技术重写GUI。 < li >为桌面和移动用户带来低延迟。

我的期望合理吗？

井：

• 显然没有必要从头开始编写调度程序队列。队列管理是内置的 ZeroMQ，实际上隐藏在服务元平面中。另一方面，在多个参与者之间调度事情是你的设计决策，与 ZeroMQ 或其他选择的技术无关。鉴于你的系统设计意图，你决定方式（“自动生成的魔法”仍然比任何近未来的系统设计现实更像是一厢情愿的想法）

[通过]队列：内置ZeroMQ
[NICEHAVE]调度程序：为任何通用分布式多代理范围的生态系统自动生成_{（但在不久的将来很难预料）}

• 网络（和原则上的任何）I/O已经在ZeroMQ服务层次结构中得到了简化

[已通过] ： 简化的网络 I/O - ZeroMQ 提供了所有抽象的传输类相关服务，这些服务隐藏在信令/消息传递元平面的透明使用中，
因此应用程序代码喜欢“只是”{ .send（） | .poll（） | .recv（） }

[PASSED]：将GUI与ParcPlace-Systems开创的MVC架构的任何其他部分分离。自 ZeroMQ v2.11 以来，使用它作为通过 TCP/IP 网络的（远）远程键盘，甚至可以集成到基于参与者的 GUI 中，例如 Tkinter-GUI 参与者可以很好地服务于这种分布式本地可视化/远程分布式控制器/远程分布式模型。如果移动终端 O/S 对本地可视化 MVC 组件引入了更复杂的约束，则应与领域专家就该特定 O/S 属性进行验证。到目前为止，ZeroMQ信令/消息传递元平面尚未被认为包含任何约束本身。

[通过]： LATENCY-ZeroMQ从一开始就被设计为提供最终的低延迟，这是必须的。鉴于它可以为高频传输生态系统提供支持，桌面/移动系统在所有访问的传输O/S处理延迟的E2E一次性累积意义上的限制要少几个数量级。