Javascript 发布子模式和消息代理，如何确保所有订阅者完成对事件的处理

首先，我知道有一些好的（轻量级的）消息代理，比如NAT。如果这是一份工作，我当然会选择经过验证的解决方案，这更多的是好奇心和理解的意愿

比方说，我想构建一个像CRM这样的系统，我想将其建立在微服务的基础上，这样它就可以很容易地扩展并适应工作负载。因为微服务应该解耦。为了使pub-sub按预期工作（发布者和订阅者的分离），我需要一个消息传递系统。假设我想通过node.js实现这一点（充分意识到有很多更快的方法来实现）

我的“问题”或者说可能只是认知上的失误，就是如何确保所有订阅者都收到了来自他们订阅的主题的消息

客户端/前端向代理发送事件请求。代理可能会验证消息并将其放在预期队列中。有2个微服务已订阅到此队列。代理现在正在向两个微服务发送队列上最早的事件，并带有回调

当其中一个微服务明显比另一个慢时，这不会导致问题吗

我的意思是，只要我不想发送回表示任务已由所有订阅者完成的确认消息，它就应该可以工作。客户端不知道事件请求涉及多少服务，因此无法跟踪它。因此，这需要经纪人来完成

---

这是否意味着，我需要将其包含在消息代理中？它会跟踪某个特定事件的订阅服务计算状态吗？

经过更多的研究，在床上醒着躺了几个小时后，我得出结论，如果发布者希望收到响应/确认以跟踪事件，那么让多个订阅者订阅一个主题/主题应该被视为不好的做法已发送请求/消息/事件的状态

经过再三思考，我得出结论，同一主题的多个订阅服务很可能永远都不必要——至少在我的场景中，只要我正确地设计服务。我能想到的唯一情况是在以后的某个时间点添加某些功能，而不涉及已经部署的服务。这感觉像是对不合适的服务设计的修复

然后我想我怎样才能处理它，并想出了3种方法

首先是标准结构 我想不需要进一步解释了。不要介意一些方法的细节，这只是一个头脑风暴的版本，绝对不是理想的。它足以显示模式

方法1-聚合器收集响应 因为代理跟踪每个订户，所以它总是知道（或者可以很容易地计算）预期的响应数量。因此，它可以将响应消息重定向到聚合器主题，该聚合器主题在发送/发布需要响应或成功消息的消息时自动创建（想想一些客户数据的更新-您显然希望知道消息已通过并成功处理）

当然，聚合器可能总是介于两者之间，即使只有一个响应返回。这样可以减少案件数量。聚合器基本上是某种代理。不过，这仍然增加了代理的复杂性

方法2-代理发布确认消息 首先：不要介意右边的连接混乱。它对我来说是一幅素描，但并不整洁

正在发布的每一条消息都由代理用确认消息进行应答。该消息被放在消息单独主题堆栈上。因为代理知道每个主题有多少订阅者，所以它可以发回发布者应该期望的响应数量。一般来说，确认消息也可用于通知发布者其消息/事件/请求是否已被接受（请考虑此处的身份验证和授权模式）

只要出版商总是希望得到回复，这就行了。如果不这样做，消息可能会停留相当长一段时间。超时可以解决这个问题

方法3-传输协议响应 这与方法2非常相似，不同之处在于传输协议用于通知发布者已发送请求的状态和预期的潜在响应数

由于大多数（如果不是所有）适合这种地形的协议都提供了某种方式的响应消息，而且这些消息无论如何都应该用于验证消息是否已成功发送，答案还可以包含一个有效负载，它不仅通知客户端成功的传输，还通知客户端预期的响应数量

结论 我要说的是，聚合器方法的开销太大，它需要更多的额外代码，而不仅仅是使用传输协议或消息系统本身。聚合器很有趣，因为客户端可以完全忽略服务，因此是解耦的

消息系统的使用对于日志记录（潜在调试）和Sagas（事件链）的实现也很有意义

注

---

我不认为这些方法中的任何一种是最佳做法。我只想用我的研究结果来回答我自己的问题。

经过更多的研究，在床上醒着躺了几个小时后，我得出结论，如果出版商想要获得回复/确认，以便跟踪主题的状态，那么一个主题/主题有多个订阅者应该被视为不好的做法已发送的请求/消息/事件

经过再三思考，我得出结论：多个订阅服务