Saga: когда “отмена” — это не rollback, а новое действие в домене
В мире микросервисов есть одна вечная проблема: как обеспечить согласованность данных между независимыми компонентами? Традиционные транзакции здесь не работают, но есть элегантное решение — Saga-паттерн. Разберем, откуда он произошел, что из себя представляет и почему стал стандартом индустрии.
Что такое Saga Паттерн
Saga — паттерн управления данными и транзакциями в распределенных системах.
Вместо одной большой транзакции, когда весь процесс либо завершен, либо откатывается, данный паттерн разбивает весь процесс на несколько локальных транзакций. Каждая транзакция выполняется в своей доменной области (модуле, компоненте или микросервисе), обновляет данные и генерирует события, которые используются для следующих шагов.
Если все шаги выполнены успешно, то Saga считается завершенной. Если же на каком-то из шагов возникла ошибка, то Saga запускает процесс отката необходимых изменений — компенсирующие транзакции.
Ключевое свойство Saga — вместо строгой согласованности обеспечивается только итоговая согласованность (eventual consistency).
Кто придумал и ввел понятие Saga
Паттерн Saga был формально описан в 1987 г. в работе SAGAS авторами Hector Garcia-Molina и Kenneth Salem. Слово "Saga" — это не аббревиатура, а просто название, которое авторы выбрали для этого паттерна. Хотя немного позже придумали еще и расшифровку — "Segregated Access of Global Atomicity". В оригинальной работе Saga — способ управления долгоживущими транзакциями в СУБД.
Однако современную трактовку и адаптацию этого паттерна для распределенных систем связывают с Крисом Ричардсоном (Chris Richardson). Он в своей книге "Microservices Patterns" и на своем ресурсе microservices.io детально описал применение Saga для координации микросервисов. Ему также приписывают выделение двух основных стилей координации — оркестрацию и хореографию. Именно его трактовки де-факто стали стандартами индустрии.
Почему Saga — это не просто компенсации
Многие воспринимают Saga как набор компенсирующих действий, но это неполное и опасное понимание.
На самом деле, компенсации — лишь часть паттерна. Компенсации — это следствие. Saga — это модель бизнес-процесса, механизм управления состояниями этого процесса.
В общем случае Saga — это:
- Четкая последовательность шагов — каждый шаг это атомарная операция.
- События — завершение шага порождает событие, которое запускает следующий шаг и уведомляет заинтересованных акторов.
- Состояние и координация процесса — система отслеживает, на каком этапе находится каждый бизнес-процесс (либо мы можем это отследить по контекстным данным — уникальные идентификаторы и т. д.).
- Стратегии обработки ошибок — выбор шагов, которые необходимо выполнить при возникновении ошибки на определенном шаге.
Как обычно принято реализовывать паттерн Saga
Существуют два основных подхода в реализации Saga: Оркестрация (Orchestration) и Хореография (Choreography).
Оркестрация (Orchestration)
В этом подходе существует центральный координатор (Saga Orchestrator), который управляет всем процессом и явно указывает каждому сервису, что делать.
Преимущества:
- Четкая логика управления потоком событий — всё находится в одном месте.
- Централизованная обработка ошибок — легко реализовать таймауты, повторные попытки и т. п.
- Проще отладка и мониторинг процесса
Недостатки:
- Сервисы тесно связаны с оркестратором.
- Оркестратор становится единой точкой отказа.
- Оркестратор может стать "Божественным объектом" с излишней логикой.
Хореография (Choreography)
В этом подходе нет центрального координатора. Каждый сервис самостоятельно слушает события, выполняет свою работу и публикует события для следующего сервиса.
Преимущества:
- Слабая связанность — каждый сервис независим.
- Нет единой точки отказа.
- Лучше масштабируется для высоконагруженных систем.
Недостатки:
- Логика процесса неявная и распределена по разным участникам — сложно понять и отладить.
- Обработка ошибок распределена по сервисам — трудно обеспечить согласованность.
- Риск "event hell" — множество событий, летающих по системе, могут привести к запутанности.
- Могут возникнуть циклические зависимости.
Заключение
Saga — это архитектурный паттерн и стратегия для управления сложными долгосрочными бизнес-процессами в распределенных системах.
Saga позволяет эффективно решать проблемы согласованности данных и думать не только о happy-path процессов.
Какие подходы реализации Saga вам больше нравятся и почему — оркестрация или хореография?
Мой канал в телеграм