Оркестрация против хореографии: как координировать шаги распределённого процесса

Прямой ответ

Распределённый процесс из нескольких шагов координируется двумя способами. Оркестрация — центральный координатор вызывает шаги и знает порядок. Хореография — сервисы реагируют на события друг друга, и общего координатора нет.

Оркестрация выглядит как последовательный вызов:

def process_order(order_id: int) -> None:
    payment = payment_service.charge(order_id)      # шаг 1
    stock = inventory_service.reserve(order_id)     # шаг 2
    shipment = shipping_service.create(order_id)    # шаг 3

Порядок виден в одном месте, а при отказе шага координатор выполняет компенсацию предыдущих; о механизме — в статье про сагу и outbox.

Хореография строится на событиях:

orders      --OrderCreated-->        payments
payments    --PaymentCompleted-->    inventory
inventory   --StockReserved-->       shipping

Каждый сервис знает, на какое событие реагирует, но не знает о процессе целиком. Порядок существует как следствие подписок, а не как явное описание.

Практические различия проявляются в трёх местах.

Понимание процесса. При оркестрации последовательность читается в одном файле. При хореографии она восстанавливается перебором подписок всех участников, и при десятке сервисов это становится отдельной задачей.

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

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

Распространённое заблуждение — считать хореографию «слабо связанной» по определению. Связность остаётся, но переносится в контракты событий и в неявный порядок шагов, который нигде не зафиксирован.

Скрытые издержки хореографии

Хореография выглядит проще на трёх сервисах и усложняется нелинейно с ростом числа участников.

Восстановление последовательности. Порядок шагов существует как следствие подписок. Чтобы узнать, что происходит после определённого события, нужно найти всех подписчиков, а затем подписчиков на их события.

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

Каскадные изменения формата. Изменение структуры события затрагивает всех подписчиков, которых нужно найти. При отсутствии схемы события изменение обнаруживается в момент обработки.

Сложность тестирования. Проверка процесса целиком требует подъёма всех участников. Тест одного сервиса не проверяет последовательность.

Накопление неявных правил. Условие «отгрузка возможна только после оплаты» нигде не зафиксировано, кроме кода подписчика. Новый разработчик узнаёт его из разбора инцидента.

Эти издержки не означают, что хореография неприменима. Они означают, что её преимущества — отсутствие центрального компонента и независимость развёртывания — имеют цену, которая растёт с числом участников.

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

Практика: выбор подхода

1. Используйте оркестрацию для процессов с явным порядком. Оформление заказа, возврат, онбординг клиента — процессы, где последовательность важна и должна читаться.

2. Используйте хореографию для уведомлений. Оповещение нескольких сервисов о событии без порядка обработки не требует координатора.

3. Фиксируйте процесс в коде, а не в схеме. Диаграмма, не соответствующая коду, вводит в заблуждение сильнее, чем её отсутствие.

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

5. Добавляйте наблюдаемость процесса. Идентификатор процесса проходит через все шаги и позволяет восстановить его выполнение; о трассировке — в статье про трейсинг.

6. Ограничивайте число участников. Процесс из трёх шагов читается легко, из пятнадцати — требует отдельной документации независимо от подхода.

7. Не смешивайте подходы в одном процессе. Часть шагов в координаторе и часть через события делают процесс нечитаемым в обоих представлениях.

8. Проверяйте завершение процесса. Процесс, остановившийся на середине, должен обнаруживаться по таймауту, а не по обращению пользователя.

Рекомендации:

1. Начинайте с оркестрации для новых процессов. Она даёт наблюдаемость и явный порядок, которые при хореографии приходится восстанавливать.
2. Выделяйте координатор в отдельный сервис. Логика процесса в одном из участников делает его ответственным и за свои данные, и за чужой порядок.
3. Храните состояние процесса. Координатор без сохранённого состояния не может продолжить выполнение после перезапуска; о механизмах — в статье про workflow engine.
4. Проверяйте идемпотентность шагов. Повтор шага при восстановлении после сбоя не должен выполнять действие дважды.
5. Учитывайте частичный отказ. Шаг может выполниться, а ответ потеряться, поэтому координатор должен различать «не выполнено» и «результат неизвестен».

Практический сценарий: восстановление порядка процесса после роста числа участников

Контекст: процесс оформления заказа начинался с трёх сервисов на хореографии. Через два года участников стало одиннадцать, и разбор инцидентов занял часы.

1. Диагностика. При сбое в середине процесса никто не мог сказать, какие шаги выполнены. Порядок существовал как следствие подписок, а схема в документации отставала от кода на четыре шага.
2. Причина. Хореография выбрана как «слабо связанное» решение без учёта того, что порядок процесса нигде не фиксируется. С ростом числа участников восстановление последовательности требовало чтения кода всех сервисов.
3. Действия. (а) Процесс оформления перевели на координатор с явным перечнем шагов и сохранением состояния; (б) каждый шаг сделали идемпотентным, чтобы повтор после сбоя не выполнял действие дважды; (в) добавили компенсацию для шагов, которые можно отменить, и явную пометку для тех, что нельзя; (г) уведомления, не влияющие на процесс, оставили на хореографии; (д) добавили метрику числа процессов, остановившихся на середине, с тревогой по таймауту.
4. Результат. Разбор инцидента сократился до чтения состояния процесса в координаторе, а незавершённые процессы обнаруживаются по таймауту автоматически.

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

FAQ

Что проще поддерживать? Оркестрацию для процессов с порядком: последовательность читается в одном месте. Хореография проще для независимых уведомлений.

Является ли хореография слабо связанной? Связность переносится в контракты событий и неявный порядок шагов. Она не исчезает, а становится менее видимой.

Можно ли сочетать подходы? Да, но в разных процессах. Смешение внутри одного процесса делает его нечитаемым.

Как обнаружить незавершённый процесс? Метрикой числа процессов в промежуточных состояниях с тревогой по таймауту. Без этого процесс остаётся незавершённым до обращения пользователя.

Источники: Azure Architecture Center (микросервисные паттерны), microservices.io (Saga), AWS Compute Blog — ссылки в шапке.