因此，我们正在设计一种新的微服务架构。内部沟通是最大的挑战之一。对于需要响应的通信，我们使用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吗？
SQS使用XML over http，RabbitMQ使用AMQP，所有协议都有开销。序列化/反序列化需要付出代价。亚马逊SQS和AMQP都非常高效。我会从计算中排除这些“间接费用”，而是专注于您的其他要求。
使用队列的一大优势是处理浪涌活动。如果您获得100K命中，并且需要发送100K消息，并且您尝试将其实现为服务间调用（非阻塞或其他），您将对系统的可扩展性达到实际限制（如果没有，则从端口计数）其他）。如果您将100K消息放在队列中，那么这些消息基本上可以在远程服务器的“休闲”处理。
另外，正如您在上面提到的，队列的持久性更难以自行实现。如果数据不重要，这不是一个大问题，但如果这个数据具有更高的重要性，那么你真的想要一些推送到持久存储的东西（如SQS或Rabbit持久队列）......
我迟到了，但是很晚才开始使用NON Blocking I / O并看到NIO的一大好处，特别是在调用无法访问消息队列的外部服务时。使用固定连接池将确保使用非阻塞I / O处理100K问题，并且不会创建太多连接。
在调用内部服务时，首选消息队列，但假设您没有该选项，您可以利用重试机制和连接池来利用NIO，为您提供相同的可扩展性消息队列。这假设接收器能够处理NIO呼叫的负载。