Бизнес-процесс проходит через пять сервисов, а число компенсаций растёт. В каком случае оркестрация саги предпочтительнее хореографии?
Оркестрация саги предпочтительнее, когда процесс имеет много шагов, ветвлений, тайм-аутов и компенсаций, а его состояние нужно явно контролировать. Центральный оркестратор хранит состояние процесса, отправляет команды участникам и определяет дальнейший переход после успешного выполнения или ошибки.
Хореография лучше подходит для коротких и слабо связанных реакций, где участники самостоятельно реагируют на события. При сложном процессе цепочка событий быстро становится трудной для понимания, диагностики и изменения.
Вызов нескольких сервисов в рамках одной локальной транзакции невозможен без общей транзакционной границы. Распределённые транзакции могут быть дорогими, ограничивать автономность сервисов и плохо сочетаться с независимым масштабированием и отказоустойчивостью.
Подход Saga разделяет длительную операцию на последовательность локальных транзакций. Если очередной шаг не выполнен, система запускает компенсирующие действия для уже завершённых шагов. Оркестрация и хореография — два способа управлять такой последовательностью.
Представим процесс оформления заказа: резервирование товара, проверка риска, авторизация платежа, создание доставки и уведомление клиента. Каждый шаг может завершиться успешно, сообщить об отказе или остаться неопределённым из-за тайм-аута.
При хореографии каждый сервис публикует событие, а другие сервисы подписываются на него и публикуют следующие события. При росте числа участников зависимости образуют неявную цепочку: становится сложно определить, кто отвечает за переход процесса, какие компенсации уже выполнены и что произойдёт после повторной доставки события.
Неверный выбор приводит либо к чрезмерно связанному оркестратору, либо к неуправляемой сети реакций. В обоих случаях усложняются наблюдаемость, повторное выполнение, восстановление после сбоев и изменение бизнес-процесса.
В оркестрации отдельный компонент является владельцем состояния саги. Он отправляет сервисам команды вроде «зарезервировать товар» или «создать доставку», фиксирует результаты, применяет тайм-ауты и при необходимости запускает компенсации.
Оркестратор не должен напрямую изменять базы данных участников или содержать их бизнес-правила. Его ответственность — порядок шагов, переходы состояния, политика повторов и реакция на окончательные ошибки. Бизнес-операции и их локальные инварианты остаются внутри соответствующих сервисов.
Оркестрация обычно предпочтительнее, если:
Плюсы оркестрации — явный граф процесса, единое место для корреляции и более простой аудит. Минусы — дополнительный компонент, риск превратить его в «распределённый монолит» и необходимость масштабировать его состояние.
В хореографии нет центрального координатора: сервисы реагируют на события и сами решают, какие действия выполнять. Она сохраняет автономность участников и хорошо подходит для независимых реакций, например обновления аналитики или отправки уведомления после изменения заказа.
Главное ограничение обоих вариантов — отсутствие общей транзакции. Компенсация не равна откату: она является новой бизнес-операцией, может завершиться ошибкой и иногда требует ручного разрешения. Поэтому каждый шаг и каждая компенсация должны быть идемпотентными, а состояние саги — наблюдаемым и восстанавливаемым.
В интернет-магазине процесс включал семь шагов, три ветвления и четыре компенсации. Изначально сервисы обменивались событиями: успешная оплата запускала доставку, отказ доставки инициировал возврат, а отмена резерва публиковала ещё одно событие.
Рассматривались два варианта. Сохранить хореографию было проще для локальных изменений и не требовало отдельного координатора, но цепочка стала непрозрачной: по журналам было трудно понять, на каком шаге находится заказ и какая компенсация должна сработать. Полностью синхронный процесс давал простой контроль, но создавал длинную цепь доступности и зависимость от тайм-аутов.
Выбрали оркестратор с долговечным состоянием саги. Участники получили команды и возвращали результаты, а оркестратор хранил корреляцию, число попыток и текущий шаг. События о независимых побочных действиях, таких как аналитика, оставили в хореографическом стиле.
Такое разделение уменьшило связанность основного бизнес-процесса, упростило повторное выполнение после сбоя и сделало ручное восстановление контролируемым. При этом оркестратор не стал владельцем данных о товарах, платежах или доставке.
1. Может ли оркестратор сам откатить изменения во всех сервисах?
Нет. Он может только инициировать компенсирующие операции, а не выполнить настоящий откат общей транзакции. Компенсация может быть недоступна, частично выполнена или иметь собственные бизнес-ограничения, поэтому её результат нужно отслеживать как отдельное состояние.
2. Чем оркестрация отличается от простого синхронного вызова сервисов через один компонент?
Оркестратор управляет долгоживущим процессом, сохраняет его состояние и допускает продолжение после временного сбоя. Синхронный фасад обычно удерживает цепочку вызовов в рамках одного запроса и не решает проблему восстановления после тайм-аута или падения между шагами.
3. Как избежать превращения оркестратора в распределённый монолит?
Нужно ограничить его роль координацией процесса. Он не должен дублировать внутренние правила сервисов, обращаться к их базам данных или объединять все бизнес-решения в одном модуле. Границы ответственности следует проверять по владению инвариантами: сервис исполняет локальную операцию, а оркестратор определяет, какой шаг следует выполнить дальше.