Масштабируемая архитектура cron поверх AWS - PullRequest
Новая
       42

Масштабируемая архитектура cron поверх AWS

0 голосов
/ 05 ноября 2018

У нас есть веб-приложение, используемое клиентами, и у них есть возможность создавать отчеты. Отчет содержит электронная почта и запланированное время (например: каждый день, 9 часов утра).

Когда запланированное время соответствует , текущее время веб-приложение выполняет некоторую работу и отправляет результат на электронную почту.

У меня есть одно требование, когда мне нужно реализовать масштабируемую архитектуру cron поверх swf.

Моя необходимая архитектура выглядит следующим образом:

  1. Пользователь создает отчет (СОВЕРШЕНО)
  2. Webapp сохраняет отчет в БД и отправляет данные отчета и таймер в микросервис cron через SQS (служба простых запросов). (DONE)
  3. Микросервис Cron считывает входящие сообщения SQS и отправляет обратно сообщение SQS по истечении таймера. (НУЖНО ЭТО)
  4. Webapp читает сообщение SQS и запускает функции Data Analyzer и Emailer для отправки проанализированных данных. (DONE)

Из того, что я читал о сервисе SWF, мы можем создавать задания cron и автомасштабирования SWF. Как создать масштабируемый микросервис cron с помощью SWF?

Открыто для любых предложений ...

P.S. Веб-приложение написано на nodejs, очень хорошо будет написать микросервис на nodejs.

Обновление 1: Потратив некоторое время на изучение возможных решений, Я нашел https://github.com/capside/CloudCron проект. Но это зависит от события cloudwatch. Для многих запланированных задач это может потребовать много IMO.

Обновление 2: Банджо Обайоми предложил использовать лямбда-функции с SQS и CWE.

Решение 1:

  1. Webapp отправляет сообщение SQS.
  2. Сообщение SQS запускает лямбда-функцию1
  3. Лямбда-функция создает правило CWE
  4. Правило CWE запускает лямбда-функцию2
  5. Лямбда-функция2 отправляет сообщение SQS обратно в веб-приложение.

Ограничения: Мы можем создать только 100 правил CWE для каждого региона. Это означает, что веб-приложение не может генерировать более 100 отчетов с запланированной датой.

Ссылки: хрон-в-AWS-с лямбда-функции

Ответы [ 4 ]

0 голосов
/ 15 ноября 2018

Вам не нужен хрон, вам просто нужно использовать правильный тип очереди.

С SQS и другими очередями (например, RabbitMQ) они имеют то, что называется «обменом мертвыми буквами», и вы можете добавить время жизни (TTL) к определенным очередям. Решение SQS называется «Очереди задержки», и когда вы отправляете им сообщение, ваши подписчики не получают их, пока не пройдет задержка.

Вы должны объявить интервал задержки при создании очереди, но он очень прост. Я считаю, что сначала нужно выбрать очередь типа FIFO, а затем установить интервал задержки.

В других очередях вы можете установить TTL для сообщений и объявить обмен мертвыми буквами (то есть, после истечения срока действия сообщения, оно отправит его в целевую очередь). Это хорошая уловка, чтобы создать задержку, и ваши подписчики ожидают новых сообщений в очереди, на которые она отправляется после задержки.

  1. Выберите FIFO queue и «Настроить» Create new FIFO queue
  2. Установите Delivery Delay Set the Delay
0 голосов
/ 06 ноября 2018

Было бы излишне использовать SWF только для шага 3. Но было бы целесообразно использовать его для реализации шагов со 2 по 4 в качестве единого рабочего процесса. Таким образом, вам не нужна зависимость от SQS, приложение становится проще, и вы получаете намного лучшую видимость вашего процесса.

К сожалению, SWF не предоставляет поддерживаемую клиентскую библиотеку nodejs. Он также не поддерживает автоматическое масштабирование, так как вы должны запускать рабочие процессы. Но автоматическое масштабирование может быть реализовано поверх него.

0 голосов
/ 14 ноября 2018

Я не нашел точного решения своей проблемы, но нашел другой способ достичь своей цели с помощью сервисов CloudWatchEvent и SQS.

Вместо получения отдельных сообщений cron SQS от микросервиса cron с параметрами и выполнения анализа, работы с уведомлениями. Мы переместили логику в бэкэнд-приложение, как показано ниже:

  1. Создана очередь SQS ("cron-microservice-dev"), которая получает сообщения от CloudWatchEventRule
  2. Создан CloudWatchEventRule, который отправляет очередь SQS каждые 1 час (мы можем изменить таймер с помощью cron-подобного синтаксиса). Таким образом, каждые 1 час CWE-правило отправляет сообщение в очередь SQS.
  3. Теперь бэкэнд прослушивает очередь "cron-microservice-dev" и проверяет из БД, существуют ли запланированные отчеты, которые должны быть запущены. Если есть отчеты, это будет анализировать каждый отчет и уведомляет получателя.
0 голосов
/ 05 ноября 2018

Звучит так, как будто вы можете использовать AWS Lambda в качестве точки приема, иметь функцию триггера для входящих сообщений SQS, выполнить обработку и затем отправить сообщение SQS обратно.

https://aws.amazon.com/blogs/aws/aws-lambda-adds-amazon-simple-queue-service-to-supported-event-sources/

...