Готовимся к собеседованию — Оркестрация vs Хореография

Готовимся к собеседованию: оркестрация и хореография

Этой статьёй открывается цикл материалов по подготовке к ИТ-собеседованиям для системных аналитиков и архитекторов. В цикле будут разбираться темы, которые регулярно встречаются на интервью: архитектурные подходы, интеграции, данные, API, асинхронное взаимодействие и типовые проектные компромиссы.

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

Оркестрация

Суть

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

Как работает

1. Оркестратор получает запрос на запуск процесса.
2. Последовательно вызывает нужные сервисы и ожидает результаты.
3. Отслеживает состояние процесса.
4. Обрабатывает ошибки.
5. При необходимости запускает компенсационные действия, чтобы откатить уже выполненные шаги.

Пример

Рассмотрим процесс оформления заказа:

1. Оркестратор вызывает сервис проверки наличия товара.
2. Затем вызывает сервис резервирования.
3. Далее — сервис оплаты.
4. После этого — сервис отправки.
5. Если на одном из этапов возникает ошибка, оркестратор может инициировать откат или компенсацию.

@startuml
title Оркестрация процесса оформления заказа

actor Customer as C
participant Orchestrator as O
participant "Order Service" as OS
participant "Inventory Service" as IS
participant "Payment Service" as PS
participant "Shipping Service" as SS

C -> O : PlaceOrder(request)
activate O

O -> OS : createOrder(request)
activate OS
OS --> O : orderCreated(orderId)
deactivate OS

O -> IS : checkAndReserveStock(orderId)
activate IS
IS --> O : stockReserved
deactivate IS

O -> PS : charge(orderId, amount)
activate PS
PS --> O : paymentApproved
deactivate PS

O -> SS : arrangeShipment(orderId)
activate SS
SS --> O : shipmentPlanned
deactivate SS

O --> C : OrderCompleted(response)
deactivate O

== Ошибка оплаты с компенсацией ==

C -> O : PlaceOrder(request)
activate O

O -> OS : createOrder(request)
activate OS
OS --> O : orderCreated(orderId)
deactivate OS

O -> IS : checkAndReserveStock(orderId)
activate IS
IS --> O : stockReserved
deactivate IS

O -> PS : charge(orderId, amount)
activate PS
PS --> O : paymentFailed
deactivate PS

O -> IS : releaseReservedStock(orderId) \n(компенсация)
activate IS
IS --> O : stockReleased
deactivate IS

O --> C : OrderFailed(error)
deactivate O

@enduml

Плюсы

• Прозрачность: легко проследить всю цепочку шагов.
• Контроль SLA и удобное управление точками рестарта.
• Простая отладка за счёт централизованных логов.
• Удобство для сложных многошаговых бизнес-процессов.

Минусы

• Единая точка отказа: сбой оркестратора может остановить весь процесс.
• Высокая связанность: сервисы зависят от центрального управляющего компонента.
• Риск превратить оркестратор в «монолит в центре системы».
• Возможные узкие места при масштабировании.

Инструменты

• Camunda
• Temporal
• Zeebe
• IBM BPM

Хореография

Суть

Хореография — это децентрализованный подход, в котором нет единого управляющего компонента. Сервисы взаимодействуют друг с другом через события.

Как работает

1. Один сервис публикует событие, например OrderCreated.
2. Другие сервисы, подписанные на это событие, реагируют на него.
3. После выполнения своего действия сервис может опубликовать следующее событие.
4. Процесс развивается как цепочка реакций между независимыми участниками.

Пример

Тот же сценарий оформления заказа:

1. Сервис заказов публикует событие OrderCreated.
2. Сервис склада резервирует товар и публикует StockReserved.
3. Сервис оплаты списывает деньги и публикует PaymentProcessed.
4. Сервис доставки получает событие PaymentProcessed и запускает отправку.

@startuml
title Хореография процесса оформления заказа

actor Customer as C
participant "Order Service" as OS
participant "Inventory Service" as IS
participant "Payment Service" as PS
participant "Shipping Service" as SS
participant "Event Bus" as EB

== Создание заказа ==

C -> OS : HTTP POST /orders
activate OS
OS -> EB : publish(OrderCreated)
deactivate OS

EB --> IS : event(OrderCreated)
activate IS
IS -> IS : reserveStock()
IS -> EB : publish(StockReserved)
deactivate IS

EB --> PS : event(StockReserved)
activate PS
PS -> PS : charge()
PS -> EB : publish(PaymentProcessed)
deactivate PS

EB --> SS : event(PaymentProcessed)
activate SS
SS -> SS : startShipment()
SS -> EB : publish(ShipmentStarted)
deactivate SS

EB --> OS : event(ShipmentStarted)
activate OS
OS -> C : notifyOrderCompleted()
deactivate OS

== Ошибка оплаты ==

EB --> PS : event(StockReserved)
activate PS
PS -> PS : charge()
PS -> EB : publish(PaymentFailed)
deactivate PS

EB --> IS : event(PaymentFailed)
activate IS
IS -> IS : releaseReservedStock()
IS -> EB : publish(StockReleased)
deactivate IS

EB --> OS : event(PaymentFailed)
activate OS
OS -> C : notifyOrderFailed()
deactivate OS

@enduml

Плюсы

• Слабая связанность: сервисы более независимы друг от друга.
• Высокая отказоустойчивость: сбой одного сервиса не всегда останавливает весь процесс.
• Гибкость: проще добавлять новые сервисы и реакции на события.
• Масштабируемость: каждый компонент можно масштабировать отдельно.
• Асинхронность: сервисы не обязаны ждать немедленного ответа.

Минусы

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

Инструменты

• Apache Kafka
• RabbitMQ
• Eventuate

Сравнение

Когда что выбирать

Когда подходит оркестрация

Оркестрацию обычно выбирают в следующих случаях:

• Есть сложный бизнес-процесс с жёсткой последовательностью шагов.
• Нужен строгий контроль выполнения и гарантии прохождения сценария.
• Требуется интеграция с legacy-системами.
• Для бизнеса важны прозрачность процесса и простота диагностики.

Когда подходит хореография

Хореография обычно лучше подходит в следующих сценариях:

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

Что сказать на собеседовании

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

Сильный кандидат дополнительно проговаривает компромисс: оркестрация проще в сопровождении сложного процесса, но создаёт центральную точку контроля; хореография лучше поддерживает масштабируемость и слабую связанность, но требует зрелой наблюдаемости и дисциплины проектирования событий.