💃 Хореография vs Оркестрация в микросервисной архитектуре 🎻
В микросервисной архитектуре (МСА) есть два основных подхода к управлению процессами между сервисами:
💃 хореография,
🎻 оркестрация.
Суть — несколько микросервисов должны отработать один сквозной сценарий, в правильном порядке и без “потерянных” шагов.
Пример из #AdFlowGA
Разрешение на публикацию объявления — это не просто “всё, публикуемся”.
Это триггер для цепочки действий:
1️⃣ запросить токен ERID для маркировки рекламы,
2️⃣ после этого отправить объявление на публикацию (ВК Реклама / Яндекс.Директ и др.)
3️⃣ запустить учёт бюджета рекламной кампании
С точки зрения архитектуры, этот процесс может быть реализован по-разному:
📌 Хореография
Каждый сервис сам реагирует на события и выполняет свою часть процесса.
Взаимодействие между сервисами происходит через брокер сообщений (обычно Kafka), без централизованного управляющего компонента.
Как это выглядит в AdFlowGA (примеры событий):
+ Срабатывает событие → publication.allowed
+ publication.allowed → МС Маркировки запрашивает ERID и публикует событие → erid.received
+ erid.received → МС Коннектор публикует объявление на площадке → ad.published
+ ad.published → МС Рекламные кампании запускает учёт бюджета
👉 Главное здесь — думать не “кто кого вызывает”, а какие события должны появляться в системе и что должен сделать каждый сервис, когда событие произошло.
📌 Оркестрация
Здесь управление процессом сосредоточено в отдельном компоненте — оркестраторе.
Пример оркестратора “из коробки”: Camunda.
Оркестратор вызывает нужные микросервисы по порядку:
▫️ получить ERID →
▫️ опубликовать на площадку →
▫️ начать отсчет бюджета кампании
и отслеживает их выполнение.
Вся логика сценария сосредоточена в одном месте, что упрощает контроль и трассировку бизнес-процесса.
👉 Что выбрать?
Оба подхода имеют свои преимущества и применяются в зависимости от целей:
💃 Хореография подходит для гибких, масштабируемых систем с высокой степенью независимости компонентов;
🎻 Оркестрация — для сценариев, требующих строгой последовательности, централизованного контроля и отслеживания хода выполнения.
Сводится к простому: где важна строгая последовательность, а где процесс можно построить как связку независимых шагов, выполняемых асинхронно.
#АрхитектураGA #AdFlowGA
В микросервисной архитектуре (МСА) есть два основных подхода к управлению процессами между сервисами:
💃 хореография,
🎻 оркестрация.
Суть — несколько микросервисов должны отработать один сквозной сценарий, в правильном порядке и без “потерянных” шагов.
Пример из #AdFlowGA
Разрешение на публикацию объявления — это не просто “всё, публикуемся”.
Это триггер для цепочки действий:
1️⃣ запросить токен ERID для маркировки рекламы,
2️⃣ после этого отправить объявление на публикацию (ВК Реклама / Яндекс.Директ и др.)
3️⃣ запустить учёт бюджета рекламной кампании
С точки зрения архитектуры, этот процесс может быть реализован по-разному:
📌 Хореография
Каждый сервис сам реагирует на события и выполняет свою часть процесса.
Взаимодействие между сервисами происходит через брокер сообщений (обычно Kafka), без централизованного управляющего компонента.
Как это выглядит в AdFlowGA (примеры событий):
+ Срабатывает событие → publication.allowed
+ publication.allowed → МС Маркировки запрашивает ERID и публикует событие → erid.received
+ erid.received → МС Коннектор публикует объявление на площадке → ad.published
+ ad.published → МС Рекламные кампании запускает учёт бюджета
👉 Главное здесь — думать не “кто кого вызывает”, а какие события должны появляться в системе и что должен сделать каждый сервис, когда событие произошло.
📌 Оркестрация
Здесь управление процессом сосредоточено в отдельном компоненте — оркестраторе.
Пример оркестратора “из коробки”: Camunda.
Оркестратор вызывает нужные микросервисы по порядку:
▫️ получить ERID →
▫️ опубликовать на площадку →
▫️ начать отсчет бюджета кампании
и отслеживает их выполнение.
Вся логика сценария сосредоточена в одном месте, что упрощает контроль и трассировку бизнес-процесса.
👉 Что выбрать?
Оба подхода имеют свои преимущества и применяются в зависимости от целей:
💃 Хореография подходит для гибких, масштабируемых систем с высокой степенью независимости компонентов;
🎻 Оркестрация — для сценариев, требующих строгой последовательности, централизованного контроля и отслеживания хода выполнения.
Сводится к простому: где важна строгая последовательность, а где процесс можно построить как связку независимых шагов, выполняемых асинхронно.
#АрхитектураGA #AdFlowGA