ZeroMQ 消息模式
ZeroMQ message patterns
我需要创建一个分布式系统，其中我有以下节点类型：
- 客户端 [1-n 个实例]
- 服务器 [1-n 个实例]
- 代理 [1 个实例 - 基本上是任何服务器的转发器]
- 云服务器[1 个实例 - 基本上是任何代理的转发器]
[客户端] -> [云服务器] -> [代理 -> 服务器] - 分布式设置
[客户端 -> 服务器] - 本地设置
[代理和服务器 运行 在同一节点或网络上]
一旦客户端与服务器处于同一网络，也应允许直接连接到服务器，而不是通过云服务器/代理。
服务器可以连接多个客户端，但除了响应来自客户端的请求外，它还可以为客户端发布消息。 Server/Cloud服务器需要通过id区分客户端节点，随时知道他们是否连接/断开。
据我了解，服务器应提供一个 REQ/REP 端点以允许与代理/本地客户端和 PUB 端点进行消息交换，代理/本地客户端将在其中订阅任何通知来自服务器。
关于代理，看来我必须有两个端点；一个在里面，两个端点在外面。基本上，我将有一个 ROUTER/DEALER 端点用于 REQ/REP 和 XPUB/XSUB 端点用于 PUB/SUB 针对远程客户端的通知。但我担心的是，外面的代理总是只有一个节点可以回复，只有一个节点订阅通知，这就是云服务器。
关于云服务器，看起来我会有类似于我上面描述的代理的东西，但与上面的代理不同，我看到 ROUTER/DEALER 和 XPUB/XSUB 满足要求。
显然我是 ZeroMQ 的新手，它提供了很多东西。我想专注于暂时需要的东西，非常感谢您的帮助。
Well, ZeroMQ is a great tool to design & build systems with, but the first thing I would recommend anyone, being a keen young novice, or a seasoned hands-on experienced Computer Science veteran, "Forget to consider all the patterns a Plug-and-Play solution to everything."
Having built "a few" distributed, low-latency systems, there are many similarities one will, sooner or later, meet in person.
Some of the ZeroMQ's built-in primitives for the Formal Scaleable Communication Patterns have "almost" matching behaviour, but one needs other ordering than an in-built round-robin stepper, some other is "almost" matching, but has some particular sequence-of-steps requirements, which one cannot guarantee in the reality of the worlds of distributed-agents. Simply put, there are many moments, when one feels "almost" done, but some tiny ( or hidden ) detail makes a ( hidden ) call to "Houston, we have a problem..."
如何专注于需要的东西？
忘记以经典的顺序方式思考。
分布式系统比普通的SEQ工具编程的单一系统复杂几个数量级。除了主要的设计目标之外，还有更多的东西，可以并且将在生产中出错。
重新访问设计规则并仔细检查新的：
1. 缩放方面：定义隐藏需求-（节点、消息大小、流量峰值）
2. blocking 状态：定义额外的信号需求（允许脱离所有潜在的分布式状态dead-/live-locking）
3. 生存能力 需求 - 分布式系统会遇到丢失消息、丢失节点
4. 不连贯 协议版本 - 对于没有人可以保证分布式系统中强制统一的情况
5. 自卫 需要 - 如果远程节点开始 panic/flawed 泛洪 signalling/messaging 通道（OOP as-is 不提供自卫工具，并且不能限制 remote-reqestors 注入的调用，构建了一套保护工具用于内部自我修复保护，以防对象服务被外部调用者过度使用或误用，从而加强您的设计以防止此类错误/恶意操作模式，正常的典型 OOP 模型方法通常无法保护自己不受其影响）。
最佳下一步：
现实世界的系统架构必须包含更多"wires"
如果您的代码努力进入生产状态，而不仅仅是学术界的例子，则必须做更多的工作，为恶劣的现实世界生产环境提供生存能力措施。
Pieter HINTJEN 的书 "Code Connected, Vol.1" 是执行此操作的绝妙视角，也是使用 ZeroMQ 进行现实设计的好书( may check my posts on ZeroMQ to find the book's direct pdf-link ).
此外，ZeroMQ 之父 Martin SUSTRIK 在 low-level truths about the ZeroMQ implementation details & scale-ability
上发表了另一篇精彩的文章
Epilogue: As a bonus, theREQ/REP primitive behaviour communication pattern is dangerous per-se in the real-world as it can self-deadlock the communication processes pair in case a transport ( for whatever reason ) has lost a packet and the "pendulum"-style message delivery gets incomplete and locked forever.
我需要创建一个分布式系统，其中我有以下节点类型：
- 客户端 [1-n 个实例]
- 服务器 [1-n 个实例]
- 代理 [1 个实例 - 基本上是任何服务器的转发器]
- 云服务器[1 个实例 - 基本上是任何代理的转发器]
[客户端] -> [云服务器] -> [代理 -> 服务器] - 分布式设置
[客户端 -> 服务器] - 本地设置
[代理和服务器 运行 在同一节点或网络上]
一旦客户端与服务器处于同一网络，也应允许直接连接到服务器，而不是通过云服务器/代理。
服务器可以连接多个客户端，但除了响应来自客户端的请求外，它还可以为客户端发布消息。 Server/Cloud服务器需要通过id区分客户端节点，随时知道他们是否连接/断开。
据我了解，服务器应提供一个 REQ/REP 端点以允许与代理/本地客户端和 PUB 端点进行消息交换，代理/本地客户端将在其中订阅任何通知来自服务器。
关于代理，看来我必须有两个端点；一个在里面，两个端点在外面。基本上，我将有一个 ROUTER/DEALER 端点用于 REQ/REP 和 XPUB/XSUB 端点用于 PUB/SUB 针对远程客户端的通知。但我担心的是，外面的代理总是只有一个节点可以回复，只有一个节点订阅通知，这就是云服务器。
关于云服务器，看起来我会有类似于我上面描述的代理的东西，但与上面的代理不同，我看到 ROUTER/DEALER 和 XPUB/XSUB 满足要求。
显然我是 ZeroMQ 的新手，它提供了很多东西。我想专注于暂时需要的东西，非常感谢您的帮助。
Well, ZeroMQ is a great tool to design & build systems with, but the first thing I would recommend anyone, being a keen young novice, or a seasoned hands-on experienced Computer Science veteran, "Forget to consider all the patterns a Plug-and-Play solution to everything."
Having built "a few" distributed, low-latency systems, there are many similarities one will, sooner or later, meet in person.
Some of the ZeroMQ's built-in primitives for the Formal Scaleable Communication Patterns have "almost" matching behaviour, but one needs other ordering than an in-built round-robin stepper, some other is "almost" matching, but has some particular sequence-of-steps requirements, which one cannot guarantee in the reality of the worlds of distributed-agents. Simply put, there are many moments, when one feels "almost" done, but some tiny ( or hidden ) detail makes a ( hidden ) call to "Houston, we have a problem..."
如何专注于需要的东西？
忘记以经典的顺序方式思考。
分布式系统比普通的SEQ工具编程的单一系统复杂几个数量级。除了主要的设计目标之外，还有更多的东西，可以并且将在生产中出错。
重新访问设计规则并仔细检查新的：
1. 缩放方面：定义隐藏需求-（节点、消息大小、流量峰值）
2. blocking 状态：定义额外的信号需求（允许脱离所有潜在的分布式状态dead-/live-locking）
3. 生存能力 需求 - 分布式系统会遇到丢失消息、丢失节点
4. 不连贯 协议版本 - 对于没有人可以保证分布式系统中强制统一的情况
5. 自卫 需要 - 如果远程节点开始 panic/flawed 泛洪 signalling/messaging 通道（OOP as-is 不提供自卫工具，并且不能限制 remote-reqestors 注入的调用，构建了一套保护工具用于内部自我修复保护，以防对象服务被外部调用者过度使用或误用，从而加强您的设计以防止此类错误/恶意操作模式，正常的典型 OOP 模型方法通常无法保护自己不受其影响）。
最佳下一步：
现实世界的系统架构必须包含更多"wires"
如果您的代码努力进入生产状态，而不仅仅是学术界的例子，则必须做更多的工作，为恶劣的现实世界生产环境提供生存能力措施。
Pieter HINTJEN 的书 "Code Connected, Vol.1" 是执行此操作的绝妙视角，也是使用 ZeroMQ 进行现实设计的好书( may check my posts on ZeroMQ to find the book's direct pdf-link ).
此外，ZeroMQ 之父 Martin SUSTRIK 在 low-level truths about the ZeroMQ implementation details & scale-ability
上发表了另一篇精彩的文章Epilogue: As a bonus, the
REQ/REPprimitive behaviour communication pattern is dangerous per-se in the real-world as it can self-deadlock the communication processes pair in case a transport ( for whatever reason ) has lost a packet and the "pendulum"-style message delivery gets incomplete and locked forever.