💃 Хореография и Оркестрация в микросервисной архитектуре 🎻

В микросервисной архитектуре (МСА) есть два основных подхода для управления работой сервисов:
💃 хореография,
🎻 оркестрация.

Суть — организовать работу нескольких микросервисов, которые должны отработать в рамках одного алгоритма.


Например, завершение зарядки электромобиля — это не просто «всё, машина заряжена».
Это триггер для цепочки действий:
🔸 списание оплаты с карты,
🔸 начисление бонусов по программе лояльности,
🔸 отправка уведомления.


С точки зрения архитектуры, этот процесс может быть реализован по-разному:

📌 Хореография
Каждый сервис сам знает, что делать при наступлении определенного события в системе.

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

Сервисы подписываются на события в брокере, такие как charging.finished («завершение зарядки»), payment.success («оплата проведена успешно»), и реагируют на них независимо друг от друга.

Например, сервис бонусов может слушать событие об успешной оплате и начислить бонусы, а сервис уведомлений — сформировать и отправить сообщение пользователю.


📌 Оркестрация
Здесь управление процессом сосредоточено в отдельном компоненте — оркестраторе.

Пример оркестратора “из коробки”: Camunda.

Оркестратор вызывает нужные микросервисы по порядку (например: сначала — платёж, затем — бонусы, потом — уведомление) и отслеживает результат выполнения каждого этапа.

Вся логика сценария сосредоточена в одном месте, что упрощает контроль и трассировку бизнес-процесса.



Оба подхода имеют свои преимущества и применяются в зависимости от целей:

💃 Хореография подходит для гибких, масштабируемых систем с высокой степенью независимости компонентов;

🎻 Оркестрация — для сценариев, требующих строгой последовательности, централизованного контроля и отслеживания хода выполнения.


#АрхитектураGA