Background Processing

PreviousДругие технологии NextLoad Balancing

Last updated 2 years ago

Was this helpful?

Background Processing

Проблема с которой мы переодически сталкиваемся на многих проектах это необходимость выполнять задачи:

по таймеру (cron like)
в режиме пакетной обработки (batch jobs)
в фоне (background jobs)
в порядке очереди (queued jobs) и т.д.

В зависимости от архитектуры нашего проекта мы обычно добавляем нужную библиотеку для работы с Jobs:

Java - Spring Batch
Ruby - Sidekiq
Python - rq, etc
NodeJS - BullMQ и многие другие.

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

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

Что мы тут видим:

API в процессе работы генерирует некие jobs
Jobs попадают в очередь
Workers подбирают Jobs

Важно: API & Workers это один репозиторий и один код

Как же мы знаем когда нам нужен API, а когда Worker код? Ответ довольно простой, и лежит в том, что мы можем создать разные настройки для запуска:

API: node server.js -> который запускает ваш сервер

Worker: node worker.js -> который запускает нужный вам воркер

Дальше можно усложнять, например в одном из проектов используют PM2 + его возможности для запуска различных типов worker-s. В другом написаны Unix services - которые запускают в нужном формате команды worker-s, где-то это просто cron-expressions.

Данный подход позволяет:

работать с слоем БД (DAO) в одной кодовой базе и не размазывать его по разным репозиториям
использовать единую кофигурацию для подключений к БД, и различным 3rd party. Что бы не было ситуаций, а вот там вот забыл еще параметр обновить
можно собирать контейнеры под разный тип ворекров (в одном из проектов видел :) )

Доклады

Вступительная KT - 20210513 - Фонові завдання (Background jobs) Видео: https://nas.in6k.com/share.cgi?ssid=0H12cTZ Слайды: https://nas.in6k.com/share.cgi?ssid=06y9kt6

PreviousДругие технологии NextLoad Balancing

Last updated 2 years ago

Was this helpful?

Проблема с которой мы переодически сталкиваемся на многих проектах это необходимость выполнять задачи:

по таймеру (cron like)
в режиме пакетной обработки (batch jobs)
в фоне (background jobs)
в порядке очереди (queued jobs) и т.д.

В зависимости от архитектуры нашего проекта мы обычно добавляем нужную библиотеку для работы с Jobs:

Java - Spring Batch
Ruby - Sidekiq
Python - rq, etc
NodeJS - BullMQ и многие другие.

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

Что мы тут видим:

API в процессе работы генерирует некие jobs
Jobs попадают в очередь
Workers подбирают Jobs

Важно: API & Workers это один репозиторий и один код

API: node server.js -> который запускает ваш сервер

Worker: node worker.js -> который запускает нужный вам воркер

Данный подход позволяет:

работать с слоем БД (DAO) в одной кодовой базе и не размазывать его по разным репозиториям
использовать единую кофигурацию для подключений к БД, и различным 3rd party. Что бы не было ситуаций, а вот там вот забыл еще параметр обновить
можно собирать контейнеры под разный тип ворекров (в одном из проектов видел :) )