#node.js #amazon-web-services #webhooks
#node.js #amazon-веб-сервисы #webhooks
Вопрос:
Ожидается, что приложение, над которым я работаю, будет сталкиваться с периодическими всплесками входящих сообщений, подлежащих обработке (события Facebook webhook). Живые тесты этого приложения еще не проводились, но, исходя из опыта аналогичных проектов, ожидается, что эти всплески могут начаться резко и продолжаться со скоростью ~ 0,8-3 тыс. сообщений в секунду в течение нескольких часов. Начало всплеска можно предсказать с точностью до нескольких секунд — десятков секунд.
Кажется рациональным передавать эти сообщения в какую-нибудь очередь, например в AWS SQS, а затем обрабатывать их с удобной скоростью. Если да, то каким было бы оптимальное решение для повторной отправки таких волн сообщений в SQS, чтобы приложение для прослушивания всегда было доступно, особенно в начале всплеска (в противном случае Facebook, вероятно, может показать ошибку 503 «Ваш веб-хук не работает»):
-
размещение приложения для прослушивания на AWS EC2 с балансировщиком нагрузки;
-
размещение приложения для прослушивания на AWS Lambda (возможно, реализация некоторых подобных мер по улучшению лямбда)
-
другие идеи? Было бы удобно, если бы SQS могла подтвердить подписку на веб-страницы Messenger, чтобы Facebook отправлял эти сообщения непосредственно в SQS, но, к сожалению, это невозможно из-за «пассивной» природы SQS.
Заранее спасибо.
Комментарии:
1. Резюме: Спасибо А.Хану и Матцеву (а также Дэвиду М. за электронное письмо) за ваши ответы. Вероятно, мы начнем с балансировщика нагрузки с несколькими экземплярами EC2 за его пределами и посмотрим, как это работает.
Ответ №1:
размещение приложения для прослушивания на AWS EC2 с балансировщиком нагрузки
Я думаю, вы можете упростить это, перейдя на бессерверный.
размещение приложения для прослушивания на AWS Lambda (возможно, реализация некоторых мер по утеплению лямбды
Я не думаю, что Lambda будет хорошим вариантом из-за ограничения на 1000 одновременных выполнений, хотя его можно увеличить.
другие идеи? Было бы удобно, если бы SQS могла подтвердить подписку на веб-страницы Messenger, чтобы Facebook отправлял эти сообщения непосредственно в SQS, но, к сожалению, это невозможно из-за «пассивной» природы SQS
Я бы предложил использовать AWS API Gateway с интеграцией сервисов AWS с использованием SQS. Вы можете настроить события Facebook webhook так, чтобы они передавались непосредственно в конечную точку REST вашего API Gateway. Вы можете настроить аутентификацию и регулирование в соответствии с вашими требованиями в API gateway.
Ответ №2:
Мне нравится архитектура с тонким интерфейсом, единственной обязанностью которого является принятие входящего запроса и немедленная выгрузка его в очередь или поток. На другом конце потока есть рабочее приложение, которое заботится о фактической обработке событий.
другие идеи?
Лично я бы использовал API Gateway, сопоставленный с Kinesis (или Kinesis Firehose) для внешнего интерфейса приложения вместо EC2. Таким образом, я могу положиться на AWS в обеспечении балансировки нагрузки, автоматического масштабирования, исправлений ОС, настройки сети и так далее. Кроме того, Kinesis предлагает значительные возможности буферизации, поэтому нет необходимости повторно отправлять пакет сообщений. Для рабочей части приложения это зависит от того, какое действие необходимо выполнить. Для кратковременных операций я рекомендую Lambda, но AWS также предлагает интеграцию с EMR, Redshift, Elasticsearch и так далее.