因此，我们正在设计一种新的微服务架构。最大的挑战之一是内部沟通。对于需要响应的通信，我们使用 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]。
现在我可以总结的优点/缺点是 -
所以对一些人来说，我的问题是，使用非阻塞 API 是个好主意吗？或者在使系统可扩展方面，哪一种方法会更好。
编辑 - 可以使用 PubNub 或 Pusher 等 PubSub 提供程序代替队列吗？