我有一个服务 A,每隔一段时间就需要向服务集群 B1、B2 ... BN 发送一条消息。然后,所有这些服务都需要可靠地接收该消息,并向 A 发送回确认。 A 收到来自集群 B 的所有服务的确认后,需要向另一个服务集群 C1、C2 ... CN 发送消息.
正确的 ZMQ 模式是什么?我应该选择什么套接字?这看起来像是一个路由器 - 经销商的情况,其中 A 是路由器,B 和 C 是经销商。我需要传输这些消息以获得传递保证,所以不确定我是否可以在这里进行发布订阅。
问:
“正确的 ZeroMQ 模式是什么,我应该选择什么套接字?”
我敢透露一个观点,自 v.2.0 以来,在过去 15(?并计数......)年中使用 ZeroMQ 收集的。
在设计现实世界的应用程序时,不存在这样的“选择”。 ZeroMQ 内置的可扩展正式通信原型模式是智能、快速、健壮的,但请不要认为它们是“完整的”,只选择其中一种并准备好进入现场实践。
Pieter Hintjens 和 Martin Sustrik 都明确指出,只要有可能,什么是值得保证的(而其他则不是)。
因此,我们有一个保证,ZeroMQ 将交付原始版本的位精确副本(或者根本不交付任何内容,并且在这两个主要角落状态之间不交付任何内容)。
因此,我们必须在给定的内置原语“之上”设计我们需要的任何和所有逻辑,因为这样我们:
(a) 准确设计我们确实需要的东西,并且
(b) 不要过度设计任何我们不需要的东西
典型的系统由消息传递(传输)层和信令层组成,其中操作 ZeroMQ 原型原语以传递(或不传递)具有应用程序相关内容的消息,在信令层中我们使用单独构建的 ZeroMQ 链路,用于向应用程序发送信号心跳级,用于我们的应用程序级已发送或丢失的传输消息的 ACK/NACK,用于我们的应用程序级自我诊断和性能评估需求。
因此,我们的努力产生了一个相当新的生态系统的概念,它是根据 ZeroMQ 原始原型构建的,从应用程序级别来看,它们一起构成了一个智能消息传递/信令元平面。
这种元平面可以有意使用许多成对的
PUSH-PULL
-s 来实现简单、通用的节点互连(那里和后面)传输层,并且除此之外,还可以使用几个通用的和特定于服务的 PUB-SUB
-s根据需要,使用任何其他模式,对于信令层,分为多个Context()
实例,以便微调性能并隔离优先级和资源容量。
从来没有“一刀切”的 ZeroMQ 模式,我们喜欢智能、超快速的内置原始原型,适合设计足够复杂的消息传递和信令元平面,以最好地满足我们的所有需求在我们的应用程序中。