在跨平台 desktop/mobile 应用程序套件中使用 ZeroMQ 来解决架构问题
Using ZeroMQ in a crossplatform desktop/mobile app-suite for architecture concerns
我需要对跨平台应用程序套件做出架构决策。我基本上想尝试解耦模块的新方法并使用 ZeroMQ 实现网络 I/O，知道它是进程内、进程间和网络应用程序的消息队列。但我不确定它如何适合我的情况。
如果有人能在我下周阅读他们有趣的书之前澄清一些事情，我将不胜感激：http://zguide.zeromq.org/page:all
我已经检查了这些问题，但没有得到答案：
- How to use ZeroMQ in an GTK/QT/Clutter application?
我的要求：
- Windows 和 macOS 上的桌面主机，作为独立的控制台后端和 GUI 前端；后端必须用C++编写；
- iOS 和 Android 上的移动访客，后端用 C++ 编写；
- 桌面使用 TCP 与移动通信；
老办法
至于桌面后端（控制台应用程序），几年前，我的第一步是编写一个基于 Observer/Command 模式的多线程架构：
- 为 UI 设置主线程并生成一些线程。
- 一个 "scheduler" 线程用于消息处理：一个队列用于从其他模块获取通知，另一个队列用于命令。每种命令类型都引入了自己的依赖项。调度程序相应地发送消息并发出命令。
- 其他 "executor" 个用于设备监控的线程，在 一个桌面和多个移动设备 之间的多路复用网络 I/O，所有发送消息到调度程序以进行实际工作已安排。
然后我需要实现线程安全的消息队列，并且不可避免地会在调度程序和一堆命令 类 之间产生耦合，这些命令本质上只是那些执行程序行为的函数包装器。使用 C++，这将是很多样板代码。
新的验证方式
但现在是 2019 年，所以我希望手写代码会减少，并会尝试一些新的东西。对于 ZeroMQ，我很想看看我的期望是否成立。我很乐意...
- 无需从头开始编写调度程序和 message/command 队列，只需跨线程在进程内模块之间传递 ZeroMQ 请求，因为从头开始编写调度既乏味又低效。
- 简化桌面和移动设备之间的网络I/O。对于这一部分，我已经尝试过 ASIO，它并不比原始套接字和 select 更方便，而且它仅支持 C++。
- 使用基于 ZeroMQ 的 IPC 解耦 GUI 和控制台应用程序，以便 GUI 可以使用不同的技术以各种语言重写。
- 桌面用户和移动用户都感受到低延迟。
我的期望合理吗？
如果是 ZeroMQ 领域的新手，请在深入了解更多细节之前随意查看 this and best enjoy a very first look at
上面提到的 post 提出了一个假设，即：
ZeroMQ is based on the assumption that there is an while (1) ... loop that it is inserted into
完全错误并且会误导任何架构规划/评估工作。
ZeroMQ是一个功能丰富的signaling/messaging元平面，旨在为应用级代码提供很多服务，可以享受轻量级的智能复用，复杂的signaling/messaging 基础设施的低级、高效处理，无论是用于进程内、进程间和节点间多代理分布式方式，为此目标使用许多已经可用的传输-class 协议:
{ inproc:// | ipc:// | tipc:// | vmci:// | tcp:// | pgm:// | epgm:// | udp:// }
话虽如此，让我们按照您的购物清单：
My requirements:
c++ ZeroMQ：[PASSED] Windows 和 macOS 上的桌面主机，作为独立的控制台后端和 GUI 前端；后端必须用C++编写；c++ ZeroMQ：[通过] iOS 和 Android 上的移动访客，后端用 C++ 编写；tcp ZeroMQ：[通过]桌面使用 TCP 与移动通信；
I'd love to ...
- Remove the need of writing a scheduler and message/command queues from scrach, by just passing ZeroMQ requests between in-process modules across threads, because writing scheduling from scratch is tedious and unproductive.
- Simplify network I/O between desktop and mobile devices. For this part I've tried ASIO and it wasn't significantly more convenient than raw socket and select, plus it's C++-only.
- Decouple GUI and console app with ZeroMQ-based IPC, so that GUI can be rewritten using different technologies in various languages.
- Perceive low-latency for both desktop and mobile users.
Is my expectation reasonable?
嗯 :
- 显然不需要从头写scheduler+Queues。队列管理内置于 ZeroMQ 中，实际上隐藏在服务元平面内。另一方面，在许多参与者之间安排事情是您的设计决策，与 ZeroMQ 或其他选择的技术无关。鉴于您的系统设计意图，您决定方式（"autogenerated magics" 仍然是一厢情愿的想法，而不是任何近期的系统设计现实）
[PASSED] QUEUES : 内置 ZeroMQ
[NICE2HAVE] SCHEDULER：为任何通用分布式多代理范围生态系统自动生成（然而，在不久的将来很难期待）
- 网络（以及原则上的任何网络）I/O 已经在 ZeroMQ 服务层次结构中进行了简化
[PASSED] : SIMPLIFIED NETWORK I/O - ZeroMQ 已经提供了所有抽象的 Transport-Class 相关signaling/messaging 元平面
的透明使用隐藏服务，因此 应用程序 代码享受 "just" { .send() | .poll() | .recv() }
[通过]：解耦 GUI 与 ParcPlace-Systems-pioneered-MVC 架构的任何其他部分。从 ZeroMQ v2.11 开始使用这个用于 TCP/IP 网络上的（远）远程键盘，甚至可以集成到基于 actor 的 GUI 中，比如 Tkinter-GUI actor 可以很好地服务于这个分布式本地-V isual/remote-distributed-Controller/remote-distributed-M模型。如果移动终端 O/S 对本地-Visual MVC 组件引入了更复杂的约束，则应与该特定 O/S 领域专家一起验证适当的适应性特性。到目前为止，ZeroMQ signaling/messaging metaplane 本身并未考虑包含任何约束。
[PASSED] : LATENCY - ZeroMQ 从一开始就设计为必须提供最终的低延迟。鉴于它可以为 HFT 交易生态系统提供支持，Desktop/Mobile 系统在所有已访问传输的 E2E 总和累积 + O/S 处理延迟的意义上限制较少数量级。
我需要对跨平台应用程序套件做出架构决策。我基本上想尝试解耦模块的新方法并使用 ZeroMQ 实现网络 I/O，知道它是进程内、进程间和网络应用程序的消息队列。但我不确定它如何适合我的情况。
如果有人能在我下周阅读他们有趣的书之前澄清一些事情，我将不胜感激：http://zguide.zeromq.org/page:all
我已经检查了这些问题，但没有得到答案：
- How to use ZeroMQ in an GTK/QT/Clutter application?
我的要求：
- Windows 和 macOS 上的桌面主机，作为独立的控制台后端和 GUI 前端；后端必须用C++编写；
- iOS 和 Android 上的移动访客，后端用 C++ 编写；
- 桌面使用 TCP 与移动通信；
老办法
至于桌面后端（控制台应用程序），几年前，我的第一步是编写一个基于 Observer/Command 模式的多线程架构：
- 为 UI 设置主线程并生成一些线程。
- 一个 "scheduler" 线程用于消息处理：一个队列用于从其他模块获取通知，另一个队列用于命令。每种命令类型都引入了自己的依赖项。调度程序相应地发送消息并发出命令。
- 其他 "executor" 个用于设备监控的线程，在 一个桌面和多个移动设备 之间的多路复用网络 I/O，所有发送消息到调度程序以进行实际工作已安排。
然后我需要实现线程安全的消息队列，并且不可避免地会在调度程序和一堆命令 类 之间产生耦合，这些命令本质上只是那些执行程序行为的函数包装器。使用 C++，这将是很多样板代码。
新的验证方式
但现在是 2019 年，所以我希望手写代码会减少，并会尝试一些新的东西。对于 ZeroMQ，我很想看看我的期望是否成立。我很乐意...
- 无需从头开始编写调度程序和 message/command 队列，只需跨线程在进程内模块之间传递 ZeroMQ 请求，因为从头开始编写调度既乏味又低效。
- 简化桌面和移动设备之间的网络I/O。对于这一部分，我已经尝试过 ASIO，它并不比原始套接字和 select 更方便，而且它仅支持 C++。
- 使用基于 ZeroMQ 的 IPC 解耦 GUI 和控制台应用程序，以便 GUI 可以使用不同的技术以各种语言重写。
- 桌面用户和移动用户都感受到低延迟。
我的期望合理吗？
如果是 ZeroMQ 领域的新手，请在深入了解更多细节之前随意查看 this and best enjoy a very first look at
上面提到的 post 提出了一个假设，即：
ZeroMQ is based on the assumption that there is an
while (1) ...loop that it is inserted into
完全错误并且会误导任何架构规划/评估工作。
ZeroMQ是一个功能丰富的signaling/messaging元平面，旨在为应用级代码提供很多服务，可以享受轻量级的智能复用，复杂的signaling/messaging 基础设施的低级、高效处理，无论是用于进程内、进程间和节点间多代理分布式方式，为此目标使用许多已经可用的传输-class 协议:
{ inproc:// | ipc:// | tipc:// | vmci:// | tcp:// | pgm:// | epgm:// | udp:// }
话虽如此，让我们按照您的购物清单：
My requirements:
c++ZeroMQ：[PASSED] Windows 和 macOS 上的桌面主机，作为独立的控制台后端和 GUI 前端；后端必须用C++编写；c++ZeroMQ：[通过] iOS 和 Android 上的移动访客，后端用 C++ 编写；tcpZeroMQ：[通过]桌面使用 TCP 与移动通信；
I'd love to ...
- Remove the need of writing a scheduler and message/command queues from scrach, by just passing ZeroMQ requests between in-process modules across threads, because writing scheduling from scratch is tedious and unproductive.
- Simplify network I/O between desktop and mobile devices. For this part I've tried ASIO and it wasn't significantly more convenient than raw socket and select, plus it's C++-only.
- Decouple GUI and console app with ZeroMQ-based IPC, so that GUI can be rewritten using different technologies in various languages.
- Perceive low-latency for both desktop and mobile users.
Is my expectation reasonable?
嗯 :
- 显然不需要从头写scheduler+Queues。队列管理内置于 ZeroMQ 中，实际上隐藏在服务元平面内。另一方面，在许多参与者之间安排事情是您的设计决策，与 ZeroMQ 或其他选择的技术无关。鉴于您的系统设计意图，您决定方式（"autogenerated magics" 仍然是一厢情愿的想法，而不是任何近期的系统设计现实）
[PASSED] QUEUES : 内置 ZeroMQ
[NICE2HAVE] SCHEDULER：为任何通用分布式多代理范围生态系统自动生成（然而，在不久的将来很难期待）
- 网络（以及原则上的任何网络）I/O 已经在 ZeroMQ 服务层次结构中进行了简化
[PASSED] : SIMPLIFIED NETWORK I/O - ZeroMQ 已经提供了所有抽象的 Transport-Class 相关signaling/messaging 元平面
的透明使用隐藏服务，因此 应用程序 代码享受 "just" { .send() | .poll() | .recv() }
[通过]：解耦 GUI 与 ParcPlace-Systems-pioneered-MVC 架构的任何其他部分。从 ZeroMQ v2.11 开始使用这个用于 TCP/IP 网络上的（远）远程键盘，甚至可以集成到基于 actor 的 GUI 中，比如 Tkinter-GUI actor 可以很好地服务于这个分布式本地-V isual/remote-distributed-Controller/remote-distributed-M模型。如果移动终端 O/S 对本地-Visual MVC 组件引入了更复杂的约束，则应与该特定 O/S 领域专家一起验证适当的适应性特性。到目前为止，ZeroMQ signaling/messaging metaplane 本身并未考虑包含任何约束。
[PASSED] : LATENCY - ZeroMQ 从一开始就设计为必须提供最终的低延迟。鉴于它可以为 HFT 交易生态系统提供支持，Desktop/Mobile 系统在所有已访问传输的 E2E 总和累积 + O/S 处理延迟的意义上限制较少数量级。