System Design Space
Граф знанийНастройки

Обновлено: 9 июня 2026 г. в 17:47

Оркестрация бизнес-процессов: Temporal, Cadence и Step Functions

средний

Как проектировать долгоживущие бизнес-процессы в микросервисах: возобновляемое выполнение, повторные попытки, компенсации, состояние процесса и выбор между Temporal, Cadence и AWS Step Functions.

Оркестрация нужна там, где бизнес-процесс переживает отдельные запросы, сервисы и даже перезапуски платформы.

Для реального проектирования глава показывает, как долгоживущие процессы, компенсации, владение состоянием и возобновляемое выполнение меняют требования к системе сильнее, чем выбор между 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, но выше риск .

Эталонный процесс с компенсациями

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

Эталонный процесс оркестрации

Успешный сценарий и компенсации 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) оркестрации измеряется отдельно: задержка старта, время завершения и доля неуспешных процессов.

Риски реализации

Смешивание бизнес-логики и деталей транспорта

Держите процесс как слой координации, а доменные решения и внешние интеграции выносите в отдельные шаги и обработчики.

Неявные компенсации

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

Один гигантский процесс

Разделяйте поток на подпроцессы с чёткими входами, выходами и ответственностью .

Недостаточная наблюдаемость

Публикуйте метрики по статусам шагов, , накоплению очереди и времени до завершения.

Источники

Связанные главы

Чтобы отмечать прохождение, включи трекинг в Настройки