将大量消息传递高峰传递给AWS SQS的最佳解决方案

Question

我正在使用的应用程序偶尔会遇到待处理的传入消息高峰（Facebook Webhook事件）。这个应用程序的实时测试尚未完成，但根据类似项目的经验，预计这些峰值可能会迅速开始，并在几小时内保持在〜0.8-3k消息/秒的速度。峰值的开始可以预测到几秒到几十秒的精度。

将这些消息传递到AWS SQS之类的队列，然后以合适的速度处理它们似乎是合理的。如果是这样，什么是将此类消息波重新发送到SQS的最佳解决方案，以便侦听应用程序始终可用，尤其是在峰值开始时（否则Facebook可能会显示503错误“您的网络挂钩已关闭”）：

• 使用负载均衡器在AWS EC2上托管监听应用程序;

• 在AWS Lambda上托管监听应用程序（可能实施了一些these之类的Lambda升温措施）

• 还有其他想法吗？如果SQS可以确认已订阅Messenger Messenger，这将很方便，以便Facebook将这些消息直接发送到SQS，但不幸的是，由于SQS的“被动”性质，这是不可能的。

谢谢。

Answer 1

  

使用负载均衡器在AWS EC2上托管监听应用

我认为您可以通过无服务器来简化它。

  

在AWS Lambda上托管监听应用程序（可能实施了一些Lambda升温措施

尽管可以增加1000个并发执行的数量，但我认为Lambda并不是一个好的选择。

  

其他想法？如果SQS可以确认已订阅Messenger Webhooks，这将很方便，以便Facebook将这些消息直接发送到SQS，但是由于SQS的“被动”性质，这是不可能的

我建议将AWS API Gateway与使用SQS的AWS Service集成一起使用。您可以配置 Facebook webhook事件可直接转到您的API Gateway REST端点。您可以根据需要在API网关中配置身份验证和限制。

Answer 2

I like the architecture with a thin frontend application whose only responsibility is to accept the incoming request and immediately offload it to a queue or a stream. At the other end of the stream, there is a worker application that take care of the actually event processing.

other ideas?

Personally, I would use API Gateway mapped to Kinesis (or Kinesis Firehose) for the frontend application instead of EC2. Thus, I can rely on AWS to provide load balancing, autoscaling, OS patches, network configuration and so on. Moreover, Kinesis offers significant buffering capabilities so there is no need to resend the message spike. For the worker part of the application, it depends on what action needs to be performed. For short-lived operations, I recommend Lambda, but AWS also offers integration with EMR, Redshift, Elasticsearch and so on.