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

Using ZeroMQ in a crossplatform desktop/mobile app-suite for architecture concerns

本文关键字：ZeroMQ 解决问题桌面跨平台移动套件应用程序更新时间：2023-10-16

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

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

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

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

我的要求：

Windows 和 macOS 上的桌面主机，作为单独的控制台后端和 GUI 前端;后端必须用C++编写;
iOS和安卓上的移动访客，后端用C++编写;
桌面使用 TCP 与移动设备交谈;

老路

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

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

然后，我需要实现线程安全的消息队列，并且不可避免地会在调度程序和一堆 Command 类之间进行耦合，这些类本质上只是这些执行程序行为的函数包装器。使用C++，这将是很多样板代码。

新的验证方式

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

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

我的期望合理吗？

如果是 ZeroMQ_{域的新手，请随时查看此内容，最好先了解一下"不到五秒的 ZeroMQ原则"，然后再深入了解更多细节}

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

ZeroMQ 基于这样的假设：存在一个插入while (1) ...循环的假设

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

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

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

也就是说，让我们关注您的购物清单：

我的要求：

c++ZeroMQ：Windows 和 macOS 上的 [PASSED] 桌面主机，作为单独的控制台后端和 GUI 前端;后端必须用C++编写;
c++ZeroMQ：在iOS 和 Android 上[通过] 移动访客，后端用 C++ 编写;
tcpZeroMQ：[已通过]使用TCP与移动设备进行桌面对话;

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

井：

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

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

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

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

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

[通过]：延迟 - ZeroMQ 从一开始就旨在提供最终的低延迟。鉴于它可以为高频交易传输生态系统提供数据，桌面/移动系统在所有访问的传输 + O/S 处理延迟的 E2E 一次性累积意义上的限制性要小几个数量级。