因此，我们正在设计一种新的微服务架构。内部沟通是最大的挑战之一。对于需要响应的通信，我们使用REST API。但对于只想传递信息的服务，这种API处理是不必要的开销。
一种方法是使用队列。 service1将信息推送到队列中，service2可以从那里消费。因此service1不必等待（与API调用不同）。 （如果在处理信息时出现任何错误，service2可以通过回调URL通知service1，或者任何其他方式;此时此问题不是一个问题[1]）
现在有了Queue，有两个选项，一个是 RabbitMQ 。另一个是 AWS SQS 。使用RabbitMQ，我担心服务器设置和所有事情（可以做，但想避免它）。因此，在SQS的POC之后，它似乎是一个不错的选择，但事情是SQS在内部使用Rest API与AWS服务器进行通信，在两点（推送时服务1，消费时服务2），将有开销。所以现在我在思考为什么不在NodeJS中这样做，service1会在信息中点击service2。 Service2将立即响应，确认已收到信息，如果有任何错误，则[1]。
现在我可以概括的优点/缺点是 -
所以对某些人来说，我的问题是，使用非阻塞API是一个好主意吗？或者，在使系统可扩展方面，哪一个将是更好的方法。
编辑 - 可以使用像PubNub或Pusher这样的PubSub提供程序而不是Queue吗？
答案 0 :(得分：2)
SQS使用XML而不是http，RabbitMQ使用AMQP，所有协议都有开销。序列化/反序列化需要付出代价。亚马逊SQS和AMQP都非常高效。我会从计算中排除这些“间接费用”，而是专注于您的其他要求。
使用队列的一大优势是处理浪涌活动。如果您获得100K命中，并且需要发送100K消息，并且您尝试将其实现为服务间调用（非阻塞或其他），您将在系统的可扩展性上达到实际限制（如果没有，则从端口计数）其他）。如果您将100K消息放在队列中，那么这些消息基本上可以在远程服务器的“休闲”处理。
此外，正如您上面提到的，队列的持久性更难以自行实现。如果数据不重要，这不是一个大问题，但如果这个数据更重要，那么你真的想要一些推送到持久存储的东西（如SQS或Rabbit持久队列）...
答案 1 :(得分：0)
我来晚了，但是迟到了，我开始使用NON Blocking I / O，并且看到了NIO的巨大好处，特别是当您调用无法访问消息队列的外部服务时。使用固定连接池将确保通过无阻塞I / O处理100K问题，并且不会创建太多连接。
虽然首选内部消息消息队列，但是可以说您没有该选项，但是可以将NIO与重试机制和连接池一起使用，以提供与您相同的可伸缩性消息队列。这是假设接收方能够处理NIO呼叫的负载。