队列与非阻塞I / O.

时间:2016-05-19 09:18:00

标签: node.js architecture queue rabbitmq amazon-sqs

因此,我们正在设计一种新的微服务架构。内部沟通是最大的挑战之一。对于需要响应的通信,我们使用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]。

现在我可以概括的优点/缺点是 -

的RabbitMQ

  • 易于实施
  • 如果收件人不可用,发件人不必担心重试。
  • 服务器设置成本+维护(+调整)

SQS

  • 最容易实施
  • 定价
  • 消息的常量轮询
  • 推送/接收时的开销

非阻止API

  • 沟通无需第3媒体
  • Service1必须管理重试机制
  • 相对于SQS,开销更少
  • 信息将在内存中处理

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

编辑 - 可以使用像PubNub或Pusher这样的PubSub提供程序而不是Queue吗?

2 个答案:

答案 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呼叫的负载。