Саги: многошаговые процессы между сервисами с компенсацией вместо отката

Что это такое

Страница паттерна на microservices.io (в источниках) определяет сагу как последовательность локальных транзакций: каждая обновляет базу одного сервиса и публикует сообщение или событие, запускающее следующую локальную транзакцию. Если локальная транзакция не удаётся из-за нарушения бизнес-правила, сага выполняет компенсационные транзакции, отменяющие изменения предыдущих шагов. Координация строится либо как хореография (каждый сервис реагирует на события), либо как оркестрация (оркестратор говорит участникам, что делать). Страница перечисляет недостатки: нет автоматического отката, поскольку компенсации пишут вручную, и нет изоляции, поэтому параллельные саги могут читать промежуточные состояния друг друга.

Azure Architecture Center (в источниках) добавляет полезные понятия: компенсируемые транзакции можно отменить; поворотная транзакция — точка невозврата, после которой сага обязана двигаться вперёд до завершения; за ней следуют повторяемые транзакции, идемпотентные, чтобы сага всегда могла закончить работу.

Почему это важно

Когда данные находятся в нескольких сервисах, «создать заказ, зарезервировать товар, списать деньги с карты» не может быть одной транзакцией базы данных. Без явной саги пути сбоев остаются неявными: списание без заказа, навсегда зарезервированный товар.

Как применять

• Запишите успешный путь списком шагов, а рядом с каждым компенсируемым шагом — его компенсацию. Если у шага нет осмысленной компенсации (отправленное письмо, окончательно списанный платёж), он является поворотным или должен идти после него.
• Упорядочьте шаги так, чтобы первыми шли шаги с наибольшей вероятностью отказа по бизнес-правилам, а необратимый — последним.
• Сделайте каждый шаг и каждую компенсацию идемпотентными, с ключом по идентификатору саги, поскольку сообщения доставляются как минимум один раз.
• Сохраняйте состояние саги (какой шаг удался), чтобы перезапущенный оркестратор продолжал, а не начинал заново; публикуйте запускающие события через outbox.
• Осознанно обработайте отсутствие изоляции: помечайте записи как ожидающие до завершения саги и заставляйте читающие компоненты учитывать это состояние.
• Задайте тайм-аут каждого шага и определите действия при его истечении (компенсация или передача человеку).

Подводные камни

Компенсация — новое бизнес-действие, а не откат: возврат денег не равен отмене самого факта списания, и он тоже может не удаться и потребовать повторения. Страница Azure описывает хореографию как подходящую для простых процессов с небольшим числом сервисов и отмечает, что при добавлении шагов поток становится запутанным; для более длинных саг проще эксплуатировать оркестратор с видимым конечным автоматом. Саги не устраняют требование идемпотентности последнего шага при повторах.