Отложенные Задачи В Микросервисной Архитектуре

Часто в проектах возникает необходимость выполнения отложенных задач, таких как отправка электронной почты, push-уведомлений и других специфических задач, специфичных для домена вашего приложения.

Трудности начинаются, когда простого crontab уже недостаточно, когда пакетная обработка не подходит и когда каждый модуль задачи имеет собственное время выполнения или назначается динамически.

Для решения этой проблемы было создано другое решение под названием Спусковой крючок .

Принципиальная схема работы представлена на рисунке 1. На схеме показано, что происходит с заданиями на протяжении всего их жизненного цикла.

Изменение цвета означает изменение статуса задачи.



Отложенные задачи в микросервисной архитектуре

Рисунок 1 – Принципиальная схема работы спускового крючка



Отложенные задачи в микросервисной архитектуре

задача, время запуска которой наступит не скоро


Отложенные задачи в микросервисной архитектуре

задача, время запуска которой скоро наступит


Отложенные задачи в микросервисной архитектуре

задача, время запуска которой пришло


Отложенные задачи в микросервисной архитектуре

обработанное задание


Отложенные задачи в микросервисной архитектуре

неподтвержденный статус задания в базе данных


Отложенные задачи в микросервисной архитектуре

команда удаления
Жизненный цикл задачи:
  • Когда задача создана, она попадает в базу данных (квадратный блок) (красный и желтый).

  • Задачи (треугольный блок) загружаются в оперативную память, если приближается время их запуска (переход красный-> желтый).

    Эта структура реализована в виде приоритетной очереди (кучи).

  • Когда наступает время выполнения задачи, она отправляется на выполнение (переход желтый-> зеленый).

    Перед обработкой используется промежуточный буфер для компенсации пиковых нагрузок.

  • Если задача успешно отправлена, она удаляется из базы данных (переход зеленый-> синий-> удалить).

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

Далее я постараюсь подробнее описать некоторые особенности и привести аргументы в пользу выбора данного решения.



Простота API

Идентификатор принимается в формате UUIDv4. Если он не передан, он будет сгенерирован независимо.

Возможность передачи идентификатора задачи из внешнего сервиса будет полезна при использовании асинхронного канала.

Время начала указывается в формате UNIX. Создание:

   

task := &domain.Task{

Теги: #open source #Kubernetes #Microservices #Go #symfony #microservices #celery #event-driven #trigger #task-manager #crontab #job-scheduler #task Scheduler #delayed messages #delayedjob
Вместе с данным постом часто просматривают: