队列与非阻塞I / O
所以，我们正在devise一个新的微服务架构。 内部沟通是最大的挑战之一。 对于需要响应的通信，我们使用REST API。 但对于只想传递信息的服务，这个API处理是不必要的开销。
一种方法是使用队列。 service1将信息推入队列，service2可以从那里消耗。 因此，service1不必等待（不像API调用）。 （如果在处理信息时有任何错误，service2可以通过callbackURL通知service1，或者以其他方式通知;这点不是问题[1]）
现在有了Queue，有两个选项，一个是RabbitMQ 。 另一个是AWS SQS 。 有了RabbitMQ，我不得不担心服务器设置和一切（可以完成，但是要避免它）。 所以在SQS的POC之后，这似乎是一个不错的select，但SQS在内部使用Rest API与AWS服务器进行通信，在这两个时间点（service1在推送时，service2在消费时）都会有开销。 所以现在我想为什么不在NodeJS中做，service1将打到service2的信息。 Service2将立即作出回应，确认它已收到信息，如果有任何错误[1]。
现在我可以总结的优点/缺点是 –
的RabbitMQ
- 易于实施
- 如果接收方不可用，发送方不必担心重试。
- 服务器设置成本+维护（+调整）
SQS
- 最容易实施
- 价钱
- 对消息进行持续轮询
- 在推/收上的开销
非阻塞API
- 没有第三个媒体需要沟通
- Service1必须pipe理重试机制
- 相对于SQS，更less的开销
- 信息将在内存中处理
所以到了某种程度，我的问题是，使用非阻塞API是否是个好主意？ 或者在制度可扩展性方面哪一个更好。
编辑 – 像PubNub或Pusher的PubSub提供程序可以用来代替队列吗？
SQS使用XML over http，RabbitMQ使用AMQP ，所有协议都有开销。 序列化/反序列化有成本。 亚马逊SQS和AMQP都非常高效。 我会从计算中排除这些“间接费用”，而将注意力放在您的其他要求上。
使用队列的一大优点是处理激增活动。 如果你得到了100K的点击量，并且需要发送100K的消息，并且你试图把这个作为inter-service调用（非阻塞的或者其他的）来实现，那么你的系统的可扩展性就会受到很大的限制其他）。 如果将100K邮件放在队列中，那么这些邮件基本上可以在远程服务器的“闲置”处理。
另外，正如你在上面提到的，队列有一个持久性，这个难度比你自己的要难得多。 如果你的数据不重要，这不是一个大问题，但是如果这个数据更重要的话，你真的想把东西推到一个持久化的存储区（像SQS或Rabbit持久队列）。