Патерн Saga використовується в мікросервісах для управління розподіленими транзакціями. Оскільки мікросервіси спілкуються один з одним і підтримують окремі бази даних, досягти консистентності даних між кількома сервісами є складно. Патерн Saga гарантує, що всі сервіси, залучені в транзакцію, успішно зафіксують зміни, або відкотять зміни в разі невдачі.
Два типи патернів Saga:
- Saga на основі хореографії (Event-Driven)
- Saga на основі оркестрації (Централізоване керування)
Простий приклад: Замовлення продукту в системі електронної комерції
Уявімо систему онлайн-покупок, що містить ці три мікросервіси:
- Order Service → Створює замовлення
- Payment Service → Знімає гроші
- Inventory Service → Резервує товар
1. Saga на основі хореографії (Event-Driven)
У цьому підході кожен сервіс слухає подію і відповідає відповідно.
Потік:
Крок 1: Order Service → Отримує запит на створення замовлення та відправляє подію OrderCreated.
Крок 2: Payment Service → Слухає подію OrderCreated, знімає суму та відправляє подію PaymentSuccess.
Крок 3: Inventory Service → Слухає подію PaymentSuccess, резервує товар і відправляє подію StockReserved.
Крок 4: Order Service → Слухає подію StockReserved, оновлює статус замовлення на Completed.
Обробка помилок (Rollback):
- Якщо платіж не вдався → Payment Service відправляє
PaymentFailed, і Order Service скасовує замовлення. - Якщо товар недоступний → Inventory Service відправляє
StockNotAvailable, і Payment Service повертає суму.
Основна перевага: Немає центрального контролера; сервіси реагують на події незалежно.
Складність: Важко відстежувати транзакції між кількома мікросервісами.
2. Saga на основі оркестрації (Централізоване керування)
Тут Saga Orchestrator (спеціалізований сервіс) керує робочим процесом.
Потік:
Крок 1: Order Service → Надсилає запит до Saga Orchestrator.
Крок 2: Saga Orchestrator → Викликає Payment Service.
Крок 3: Якщо платіж успішний, Saga Orchestrator викликає Inventory Service.
Крок 4: Якщо товар доступний, Saga Orchestrator завершує замовлення.
Обробка помилок (Rollback):
- Якщо платіж не вдався → Оркестратор вказує Order Service скасувати замовлення.
- Якщо товар недоступний → Оркестратор вказує Payment Service повернути суму.
Основна перевага: Централізоване керування і легше налагодження.
Складність: Оркестратор може стати вузьким місцем.
Коли використовувати Saga?
- Коли кілька мікросервісів мають підтримувати консистентність даних.
- Коли тривала транзакція охоплює кілька сервісів.
- Коли використовується архітектура, орієнтована на події (Choreography) або централізоване керування (Orchestration).
Код: Перевірте реалізацію коду для патерна Saga на основі хореографії та оркестрації.
Підсумок
Якщо ваші мікросервіси не мають сильних міжсервісних залежностей, використовуйте Choreography. Якщо вам потрібно краще керувати та обробляти відкат, використовуйте Orchestration.
Удачі в програмуванні!
Перекладено з: Microservices Pattern: Saga Design Pattern