🎻 Оркестрация + Хореография: пример схемы интеграции микросервисов 💃

-------

🎻 Оркестрация - это подход, при котором в системе на Backend есть централизованный компонент - оркестратор, который управляет выполнением бизнес-процесса:

▫️ знает последовательность шагов,
▫️ вызывает нужные микросервисы в нужном порядке,
▫️ анализирует ответы,
▫️ принимает решение, что делать дальше (успех / ошибка /альтернативный сценарий).

Вся логика процесса сосредоточена в одном месте.

👉 Оркестратор - отдельный сервис на Backend.

Для его реализации часто используют BPM-платформы вроде Camunda или пишут самописное решение.

-------

💃 Хореография - это подход, при котором нет центрального управляющего компонента для процесса.

Вместо этого:

▫️ система строится вокруг событий, например:
++ OrderCreated - заказ создан,
++ PaymentSucceeded - платеж успешен,
++ UserProfileCreated - пользователь зарегистрирован
▫️ микросервисы:
++ публикуют события,
++ подписываются на события, которые им интересны
▫️ поведение каждого сервиса описывается шагами: «пришло событие X → выполнить действие Y → опубликовать событие Z»

👉 В центре архитектуры с хореографией обычно стоит брокер сообщений на Backend, вв который микросервисы публикуют события и из которого их читают.

Условно его можно представить как “журнал событий”, чем-то похожий на временную БД для сообщений.

Для хореографии в сложных и высоконагруженных системах чаще всего используют Kafka, а также, например, RabbitMQ или другие брокеры.

-------

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


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