Архитектурные паттерны ARCH · 09 · 01

Хореография vs оркестрация

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

ARCH Senior ◷ 25 min

Уровень

ОсновыJuniorMiddleSenior

Команда B2B биллинговой платформы начинала с четырёх сервисов, общающихся через события — хореография. Каждый сервис подписывался на события других и эмитировал свои. Общий поток обработки заказов существовал как поведение, возникающее из подписок. Восемнадцать месяцев спустя сервисов стало двенадцать. Когда появилось новое требование — «приостановить обработку заказа, если клиент превысил кредитный лимит» — никто не знал, какой сервис менять. Три дня ушло на трассировку логов, чтобы восстановить неявный поток по двенадцати подпискам. Затем команда рассмотрела переход на оркестрированную сагу, что сделало бы поток явным в одном месте. Но это означало центральный оркестратор, от которого зависели бы все двенадцать сервисов. Они поменяли одну проблему на другую.

Хореография: неявный поток из подписок на события

В хореографированной системе каждый сервис знает только свою роль: «когда я вижу событие X, я делаю Y и эмитирую Z». Никакого центрального авторитета нет. Общий поток нигде не объявлен — он возникает из комбинации подписок всех сервисов.

Пример B2B биллинга с четырьмя сервисами:

OrderService получает запрос клиента и эмитирует OrderPlaced
PaymentService подписан на OrderPlaced, списывает средства, эмитирует PaymentProcessed
InventoryService подписан на PaymentProcessed, резервирует товар, эмитирует InventoryReserved
ShippingService подписан на InventoryReserved, планирует доставку, эмитирует ShipmentScheduled

Ни один сервис не знает полной картины. PaymentService не знает, что ShippingService существует. Поток слабо связан: добавить пятый сервис, реагирующий на PaymentProcessed, не требует изменений в PaymentService. Но поток невидим: единственный способ понять полный жизненный цикл заказа — прочесть подписки и каталог событий каждого сервиса.

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

Оркестрация: явный поток в одном месте

В оркестрированной системе центральный process-manager — оркестратор — содержит полный бизнес-поток и направляет каждого участника шаг за шагом. Оркестратор знает: «сначала списать средства, потом зарезервировать товар, потом запланировать отправку». Участников вызывает оркестратор; они не подписываются на события друг друга.

Пример B2B биллинга с оркестратором OrderSaga:

OrderSaga получает команду создания заказа
Вызывает PaymentService: «спиши средства клиента X за заказ Y»
При успехе вызывает InventoryService: «зарезервируй товар для заказа Y»
При успехе вызывает ShippingService: «запланируй доставку заказа Y»
При сбое любого шага OrderSaga точно знает, что уже сделано, и может скоординировать компенсацию

Поток теперь явный и виден в одном месте. Когда появляется требование «приостановить при превышении кредитного лимита», есть один сервис для изменения: OrderSaga. Компромисс — все участники теперь зависят от оркестратора, который стал узлом связанности.

Оркестратор OrderSaga содержит полный поток и явно направляет участников. Ни один сервис не подписывается на другой. Поток виден и изменяем в одном месте, но все участники зависят от оркестратора.

Викторина

Команда B2B биллинговой платформы три дня трассировала хореографированную систему из 12 сервисов, пытаясь найти, где реализовать «приостановку при превышении кредитного лимита». Разработчик предлагает полностью перейти на оркестрацию. Старший инженер возражает: «Не нужно переводить всю систему — причина трудностей с трассировкой структурная, но она специфична для этого потока». Какое структурное свойство хореографии вызвало проблему трассируемости и что имеет в виду старший инженер?

Реальный компромисс: связанность против видимости

Бинарная формулировка — «хореография развязана, оркестрация связана» — скрывает реальный компромисс. Оба паттерна предполагают связанность; они просто связывают разные вещи по-разному.

Связанность хореографии: каждый сервис связан со схемой события. PaymentService зависит от формы OrderPlaced. Если OrderPlaced получает обязательное поле, PaymentService нужно обновить. Сервисы развязаны от существования друг друга, но связаны с контрактом событий.

Связанность оркестрации: каждый сервис связан с ожиданиями оркестратора. PaymentService должен отвечать на команду ChargeCustomer оркестратора в ожидаемом формате. Оркестратор связан со всеми участниками.

Измерение видимости/управляемости — там оркестрация явно выигрывает: поток аудитируем, тестируем и изменяем в одном месте. Бизнес-правила («приостановить при превышении кредитного лимита», «повторить платёж дважды перед отказом») живут в оркестраторе, а не рассеяны по логике подписчиков. Это важнее всего в потоках с частыми изменениями требований или сложной многошаговой координацией.

Связанность есть у обоих паттернов — у хореографии со схемой событий, у оркестрации с координатором. Реальный компромисс — видимость: оркестрация делает поток аудитируемым и изменяемым в одном месте, хореография оставляет его неявным, но невидимым.

▸lesson.inset.note

Ни один паттерн не является умолчанием. Хореография подходит для стабильных, простых потоков между небольшим числом сервисов, где выгода от развязки превышает стоимость потери видимости. Оркестрация подходит для сложных, часто меняющихся потоков, где бизнес-правила должны быть читаемыми, аудитируемыми и изменяемыми без изменения сервисов-участников. Многие реальные системы используют оба паттерна: хореографию для независимых доменных событий (сервис уведомлений, реагирующий на любое событие заказа), оркестрацию для сложных скоординированных транзакций (сага выполнения заказа).

Викторина

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

Когда каждый паттерн ломается

Хореография ломается, когда:

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

Оркестрация ломается, когда:

Оркестратор накапливает бизнес-логику помимо координации (становится god-object)
Все изменения потока требуют изменения оркестратора, делая его узким местом деплоя
Оркестратор становится единой точкой отказа для всех скоординированных транзакций
Оркестратор технически корректен, но бизнес-команда владеет сервисами-участниками независимо, и связанность с общим оркестратором создаёт организационное трение

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

Викторина

Оркестратор OrderSaga команды вырос до 800 строк. Теперь в нём: логика маршрутизации (вызвать PaymentService), бизнес-правила («если клиент tier gold, пропустить проверку кредита»), политики повтора («повторить платёж до 3 раз»), и логика форматирования («форматировать итог заказа для этикетки доставки»). Старший инженер говорит, что оркестратор потерпел неудачу. Какой это режим отказа и какое структурное исправление?

Вспомните перед уходом

01
Почему хореографию сложно отлаживать при сбое транзакции в середине потока?
02
В чём ключевое различие в связанности хореографии и оркестрации?
03
Назови два признака того, что хореографированный поток стоит мигрировать на оркестрацию.

Итог

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

Сила хореографии — развязка: сервисы реагируют на события, не зная о существовании друг друга. Эта сила становится обязательством, когда поток сложный, когда бизнес-правила должны охватывать несколько участников, или когда вопрос «куда внести это изменение?» занимает дни.

Оркестрация делает поток явным в одном месте. OrderSaga знает полную последовательность, владеет бизнес-правилами и является единственным местом для добавления «приостановки при превышении кредитного лимита». Стоимость — все участники зависят от оркестратора, это узел связанности. И если оркестратор накапливает бизнес-логику помимо координации, он становится god-object.

Практический паттерн: использовать хореографию для простых, стабильных реакций (уведомления, аудит-логирование, метрики) и оркестрацию для сложных, часто меняющихся транзакций, где поток должен быть читаемым, аудитируемым и изменяемым. Многие системы используют оба паттерна одновременно.

Практика

Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.

вспомнитьприменитьуглубить0 из 4 завершено

Что-то непонятно?

Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.