node.js - 队列与非阻塞 I/O

Question

因此，我们正在设计一种新的微服务架构。最大的挑战之一是内部沟通。对于需要响应的通信，我们使用 REST API。但是对于那些只想传递信息的服务来说，这种API处理是不必要的开销。

一种方法是使用队列。 service1 会将信息推送到队列中，service2 可以从那里消费。因此 service1 不必等待(与 API 调用不同)。 (如果在处理信息时有任何错误，service2 可以通过回调 URL 通知 service1，或者任何其他方式；这在这一点上不是问题[1])

现在有了 Queue，有两种选择，一种是 RabbitMQ。另一个是 AWS SQS。使用 RabbitMQ，我不得不担心服务器设置和所有事情(可以完成，但想避免)。所以在 SQS 的 POC 之后，这似乎是一个不错的选择，但问题是 SQS 在内部使用 Rest API 与 AWS 服务器通信，在这两个点(推送时为 service1，消费时为 service2)，都会有开销。所以现在我在想为什么不在 NodeJS 中这样做，service1 将使用信息访问 service2。 Service2会立即响应，确认已经收到信息，如果有任何错误则[1]。

现在我可以总结的优点/缺点是 -

RabbitMQ

• 易于实现
• 如果接收方不可用，发送方不必担心重试。
• 服务器设置成本 + 维护(+ 调整)

质量标准

• 最容易实现
• 定价
• 不断轮询消息
• 推送/接收开销

非阻塞 API

• 无需第三种媒介进行交流
• Service1 必须管理重试机制
• 相对于 SQS，开销更少
• 信息将在内存中直到被处理

所以对于某些人来说，我的问题是，使用非阻塞 API 是个好主意吗？或者就使系统可扩展而言，哪种方法更好。

编辑 - 可以使用 PubNub 或 Pusher 等 PubSub 提供商来代替 Queue 吗？

Answer 1

SQS 通过 http 使用 XML，RabbitMQ 使用 AMQP ，所有协议(protocol)都有开销。序列化/反序列化是有代价的。 amazon SQS 和 AMQP 都非常高效。我将从您的计算中排除这些“开销”，而是专注于您的其他要求。

使用队列的一大优势是处理激增事件。如果您获得 100K 次点击，并且需要发送 100K 条消息，并且您尝试将其实现为服务间调用(非阻塞或其他方式)，您将达到系统可扩展性的真正限制(如果没有，则从端口数开始)别的)。如果您改为将 100K 条消息放在队列中，则这些消息基本上可以在远程服务器的“闲暇时间”进行处理。

此外，正如您在上面提到的，队列具有持久性，您自己实现起来要困难得多。如果你的数据不重要，这不是一个大问题，但如果这个数据更重要，你真的想要推送到持久存储的东西(比如 SQS 或 Rabbit 持久队列)...