队列与非阻塞 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]。

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

兔MQ

• 易于实施
• 在接收方不可用的情况下，发送方不必担心重试。
• 服务器设置成本 + 维护（+ 调优）

质量标准

• 最容易实施
• 价钱
• 消息的持续轮询
• 推送/接收开销

非阻塞 API

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

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

编辑 - 可以使用 PubNub 或 Pusher 等 PubSub 提供程序代替队列吗？

Answer 1

SQS 使用 XML over http，RabbitMQ 使用AMQP，所有协议都有开销。序列化/反序列化是有成本的。亚马逊SQS和AMQP都非常高效。我会从您的计算中排除这些“开销”，而是专注于您的其他要求。

使用队列的一大优点是处理激增活动。如果您获得 100K 次点击，并且需要发送 100K 消息，并且您尝试将其实现为服务间调用（非阻塞或其他方式），那么您将达到系统可扩展性的真正限制（如果没有任何限制，则来自端口计数）别的）。如果您将 100K 消息放入队列中，则基本上可以在远程服务器的“空闲”时间处理这些消息。

此外，正如您上面提到的，队列具有持久性，而您自己实现起来要困难得多。如果您的数据不重要，这不是一个大问题，但如果这些数据更重要，您确实需要一些可以推送到持久存储的东西（如 SQS 或 Rabbit 持久队列）...