首先，我知道可以使用像NATS这样的优质（轻量级）消息代理。如果这是一项工作，那么我当然会采用可靠的解决方案，这更多的是关于好奇心和理解的意愿。
假设我要构建一个像CRM一样的系统，并且我希望它以微服务为基础，因此它易于扩展并且可以适应工作负载。由于微服务应该解耦。在进来pub-sub。为了使pub-sub能够按预期工作（发布者和订阅者解耦），我需要一个消息传递系统。假设我想通过node.js来实现这一点（要充分意识到，有很多更快的方法可以完成此任务）。
我的“问题”或可能只是认知上的失败是让我全神贯注于如何确保所有订阅者都从他们订阅的主题接收到消息？
客户端/前端将事件请求发送到代理。代理可能会验证消息并将其放入预期的队列中。有2个微服务订阅了此队列。代理现在只是将队列中最旧的事件发送给两个微服务，并带有回调。
当其中一种微服务比另一种微服务显着慢时，这不会引起问题吗？
我的意思是，只要我不想发回表明任务已由所有订阅者完成的确认消息，它就应该起作用。客户端不知道事件请求涉及多少服务，因此它无法跟踪它。因此，它需要由代理完成。
这是否意味着我需要将其包括在消息代理中？是否跟踪给定事件的订阅服务计算状态？
[经过更多的研究和躺在床上几个小时后，我得出的结论是，如果发布者希望接收响应/确认以便跟踪其状态，那么拥有多个订阅者可能会被认为是不好的做法。发送的请求/消息/事件。
经过多番思考，我得出的结论是，对同一主题的多个订阅服务极有可能是不必要的-至少在我的情况下，只要我正确设计了服务即可。我能想到的唯一方案是在以后的某个时间点添加某些功能，而不会涉及已经部署的服务。这感觉像是对不合适的服务设计的修复。
然后，我想到了如何进行管理，提出了3种方法。
<< img src =“ https://image.soinside.com/eyJ1cmwiOiAiaHR0cHM6Ly9pLmltZ3VyLmNvbS9nRHo3S1MxLmpwZyJ9” alt =“标准的发布子结构”>我想不需要进一步的解释。不要介意某些方法的细节，这只是头脑风暴的版本，绝对不是理想的选择。显示图案就足够了。
<< img src =“ https://image.soinside.com/eyJ1cmwiOiAiaHR0cHM6Ly9pLmltZ3VyLmNvbS9kTzcxTWlNLmpwZyJ9” alt =“聚合器方法”>由于代理跟踪每个订户，因此它始终知道（或可以轻松计算）期望的响应数。因此，它可以将响应消息重定向到一个聚合主题，该主题在发送/发布时需要响应或成功消息的情况下自动创建（想想一些客户数据的更新-您显然想知道该消息已得到通过并成功处理）。
当然，即使只有一个响应返回，聚合器也始终可以介于两者之间。这样可以减少需要处理的案件数量。聚合器基本上是某种代理。但这仍然增加了代理的复杂性。
<< img src =“ https://image.soinside.com/eyJ1cmwiOiAiaHR0cHM6Ly9pLmltZ3VyLmNvbS9zQkZodEtnLmpwZyJ9” alt =“发布确认消息”>首先：不要介意右侧的连接混乱。它对我来说是一个草图，但还不够整洁。
Broker正在用确认消息回答正在发布的每条消息。该消息被放入消息的各个主题堆栈中。由于代理知道每个主题有多少个订阅者，因此它可以发回发布者应该期望的响应数。通常，确认消息还可以用于通知发布者是否接受或不接受其消息/事件/请求（请在此处考虑身份验证和授权模式）。
只要发布者始终希望得到答复，这将起作用。如果没有，则消息可能会停留一段时间。超时可以解决此问题。
<< img src =“ https://image.soinside.com/eyJ1cmwiOiAiaHR0cHM6Ly9pLmltZ3VyLmNvbS9STVBDSUxELmpwZyJ9” alt =“传输协议响应”>这与方法2非常相似，不同之处在于，使用传输协议来通知发布者有关已发送请求的状态以及预期的潜在响应数。]
由于大多数（如果不是全部）适用于这种地形的协议都提供了某种方式的响应消息，并且由于无论如何都应使用那些协议来首先验证消息是否已成功发送，因此答案还可能包含有效载荷，以通知客户不仅涉及成功的转移，还涉及期望得到多少响应。
我会说，聚合器方法开销太大，并且比使用传输协议或消息系统本身需要更多的代码。聚合器很有趣，因为客户端可以完全不理会服务，因此是分离的。
消息系统的用法对于记录目的（潜在的调试）和Sagas的实现（事件链）也很有趣。
我不推荐将这些方法中的任何一种作为最佳实践。我只想用研究结果回答自己的问题。