Оркестрация нужна там, где бизнес-процесс переживает отдельные запросы, сервисы и даже перезапуски платформы.
Для реального проектирования глава показывает, как долгоживущие процессы, компенсации, владение состоянием и возобновляемое выполнение меняют требования к системе сильнее, чем выбор между Temporal, Cadence или Step Functions.
Для интервью и инженерных разборов она помогает сравнивать оркестрацию и хореографию через прозрачность управления, эволюцию процесса и риск зависших либо дублированных действий.
Практическая польза главы
Практика проектирования
Проектируйте долгоживущие процессы с явными компенсациями и понятным владельцем состояния.
Качество решений
Сравнивайте оркестрацию и хореографию по прозрачности управления и сложности эволюции.
Аргументация на интервью
На интервью разбирайте Saga-сценарий через основной ход процесса, сбои и правила восстановления.
Анализ отказов
Задавайте тайм-ауты и пределы повторных попыток, чтобы процессы не зависали и не дублировали действия.
Primary source
Temporal Workflows
Базовая модель надёжного возобновляемого выполнения и семантики рабочего процесса Temporal.
Бизнес-процесс из нескольких сервисов редко укладывается в один запрос: оплата прошла, отгрузка зависла, а откатить нужно уже сделанное. Оркестрация долгоживущих процессов — это отдельный слой, который держит состояние процесса, единые политики повторных попыток и тайм-аутов, компенсации и операционный контроль в одном месте, чтобы эта логика не расползалась по каждому сервису.
В этой главе означает явное управление шагами, состоянием и реакцией на сбои. Ключевые термины: , , и .
Когда действительно нужна оркестрация
Процесс длится минуты, часы или дни
Когда бизнес-процесс выходит за пределы одного запроса по протоколу HTTP, нужны и возможность безопасно продолжить выполнение после сбоя.
Есть компенсации и сценарии отката
Если шаги затрагивают несколько сервисов, оркестратор делает явным: , порядок и прозрачную историю действий.
Нужны единые правила повторных попыток
Общие правила , и уменьшают дублирование инфраструктурного кода в каждом сервисе.
Важен операционный контроль
Зависший процесс кто-то должен уметь разобрать руками. Для этого нужны , , , аудит и метрики по состояниям процесса в одном контуре наблюдаемости.
Temporal, Cadence и Step Functions: практическое сравнение
Temporal
- Модель состояния
- и история событий
- Модель разработки
- Процесс описывается в коде через комплект разработчика (SDK) на Go/Java/TS/...
- Повторы и тайм-ауты
- Политики для шагов и процессов, плюс
- Компромиссы
- Нужна и отдельный контур эксплуатации.
Cadence
- Модель состояния
- , архитектурно близкое к Temporal
- Модель разработки
- Процесс описывается в коде через комплект разработчика (SDK)
- Повторы и тайм-ауты
- Политики повторных попыток для и настройки домена
- Компромиссы
- Чаще встречается в существующих инсталляциях и миграционных сценариях.
AWS Step Functions
- Модель состояния
- Управляемый на языке описания состояний (ASL) с визуальными состояниями
- Модель разработки
- Декларативные конечные автоматы и AWS-интеграции
- Повторы и тайм-ауты
- Повторные попытки и перехват ошибок на уровне состояний
- Компромиссы
- Интеграции с сервисами AWS из коробки, но цена — : при переносе в другое облако процессы придётся переписывать.
| Платформа | Модель состояния | Модель разработки | Повторы и тайм-ауты | Компромиссы |
|---|---|---|---|---|
| Temporal | и история событий | Процесс описывается в коде через комплект разработчика (SDK) на Go/Java/TS/... | Политики для шагов и процессов, плюс | Нужна и отдельный контур эксплуатации. |
| Cadence | , архитектурно близкое к Temporal | Процесс описывается в коде через комплект разработчика (SDK) | Политики повторных попыток для и настройки домена | Чаще встречается в существующих инсталляциях и миграционных сценариях. |
| AWS Step Functions | Управляемый на языке описания состояний (ASL) с визуальными состояниями | Декларативные конечные автоматы и AWS-интеграции | Повторные попытки и перехват ошибок на уровне состояний | Интеграции с сервисами AWS из коробки, но цена — : при переносе в другое облако процессы придётся переписывать. |
Эталонный процесс с компенсациями
Типовой процесс заказа: резервируем товар, списываем оплату, создаём отгрузку, отправляем подтверждение. При сбое выполняем компенсации в обратном порядке.
Эталонный процесс оркестрации
Успешный сценарий и компенсации Saga в одной схеме.
export async function OrderWorkflow(input: OrderInput): Promise<void> {
const reservation = await reserveInventory(input.orderId, input.items);
try {
await chargePayment(input.orderId, input.amount);
await createShipment(input.orderId, reservation.warehouseId);
await sendConfirmation(input.orderId);
} catch (error) {
await refundPayment(input.orderId);
await releaseInventory(input.orderId);
throw error;
}
}Контракт выполнения и чек-лист надёжности
Контракт выполнения
- Каждый идемпотентен: повторный запуск не нарушает бизнес-состояние.
- Для каждого внешнего вызова и для всего процесса заданы явные и .
- отменяют бизнес-эффект шага, а не просто откатывают запись в базе: вернуть деньги, а не стереть строку о платеже.
- позволяет старым экземплярам завершиться по старым правилам.
- Каждое состояние процесса видно через метрики и трассировку.
Чек-лист надёжности
- У каждого есть стабильный , например
orderId, и политика удаления дублей. - Шаги процесса не содержат скрытых без обёртки в
- Ошибки разделены на повторяемые и неповторяемые с разной политикой реакции.
- Ручные операции — возобновить, завершить или — описаны как .
- Целевой уровень сервиса (SLO) оркестрации измеряется отдельно: задержка старта, время завершения и доля неуспешных процессов.
Риски реализации
Смешивание бизнес-логики и деталей транспорта
Держите процесс как слой координации, а доменные решения и внешние интеграции выносите в отдельные шаги и обработчики.
Неявные компенсации
Определяйте рядом с каждым шагом и тестируйте их отдельно через инъекцию отказов.
Один гигантский процесс
Разделяйте поток на подпроцессы с чёткими входами, выходами и ответственностью .
Недостаточная наблюдаемость
Публикуйте метрики по статусам шагов, , накоплению очереди и времени до завершения.
Источники
Связанные главы
- Паттерны межсервисной коммуникации - Базовый контекст синхронных и асинхронных взаимодействий между сервисами.
- Распределённые транзакции: двухфазная (2PC) и трёхфазная (3PC) фиксация - Почему паттерн Saga часто практичнее двухфазной фиксации для долгих бизнес-процессов.
- Событийно-ориентированная архитектура - Как сравнивать оркестрацию, хореографию, хранение состояния через события (Event Sourcing), разделение команд и чтения (CQRS) и Saga.
- Обнаружение сервисов - Как шаги процесса находят нужные сервисы во время выполнения.
- Паттерны устойчивости - Практики деградации и управления сбоями: размыкатель цепи, изоляция ресурсов и повторные попытки.
