Какие знаешь виды Saga?

Виды Saga (SAGA-паттерн)

SAGA — это паттерн оркестрации распределенных транзакций в микросервисных архитектурах, где традиционные ACID-транзакции невозможны. Он обеспечивает согласованность данных путем координации последовательности локальных транзакций с компенсирующими действиями для отката.

Существуют два основных вида Saga: Orchestration (Оркестрация) и Choreography (Хореография).

1. Orchestration Saga (Оркестрация)

В этом подходе выделяется центральный координатор — Orchestrator, который управляет выполнением шагов Saga и компенсирующих транзакций. Orchestrator отправляет команды участникам (сервисам) и обрабатывает их ответы.

Пример структуры Orchestration Saga в Go:

type SagaOrchestrator struct {
    steps []SagaStep
}

type SagaStep struct {
    Command    func(ctx context.Context) error
    Compensate func(ctx context.Context) error
}

func (o *SagaOrchestrator) Execute(ctx context.Context) error {
    for i, step := range o.steps {
        if err := step.Command(ctx); err != nil {
            // Выполняем компенсирующие транзакции для уже выполненных шагов
            for j := i - 1; j >= 0; j-- {
                if errComp := o.steps[j].Compensate(ctx); errComp != nil {
                    log.Printf("Compensation failed for step %d: %v", j, errComp)
                }
            }
            return fmt.Errorf("saga failed at step %d: %v", i, err)
        }
    }
    return nil
}

Преимущества Orchestration:

• Централизованное управление: Легко отслеживать состояние Saga, дебажить и логировать.
• Сниженная сложность взаимодействия: Сервисы не знают друг о друге, общаются только с Orchestrator.
• Прямой контроль компенсаций: Orchestrator гарантирует выполнение компенсаций в правильном порядке.

Недостатки:

• Дополнительный компонент: Orchestrator становится критической точкой, требует высокой надежности.
• Риск связывания: Orchestrator может стать "God Object", если логика слишком сложная.

2. Choreography Saga (Хореография)

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

Пример Choreography Saga с событиями в Go:

// Сервис OrderService
func CreateOrder(ctx context.Context, orderData Order) error {
    // Локальная транзакция: создание заказа
    err := db.CreateOrder(orderData)
    if err != nil {
        eventBus.Publish("OrderCreatedFailed", orderData)
        return err
    }
    eventBus.Publish("OrderCreated", orderData)
    return nil
}

// Сервис PaymentService (обработчик событий)
func onOrderCreated(event OrderCreatedEvent) error {
    err := processPayment(event.OrderID)
    if err != nil {
        eventBus.Publish("PaymentFailed", event.OrderID)
        return err
    }
    eventBus.Publish("PaymentProcessed", event.OrderID)
    return nil
}

Преимущества Choreography:

• Децентрализация: Нет единой точки отказа, более scalable архитектура.
• Низкая связность: Сервисы независимы, общаются только через события.
• Гибкость: Новые сервисы могут легко присоединиться к Saga, подписываясь на события.

Недостатки:

• Сложность отслеживания: Трудно понять текущее состояние Saga без мониторинга всех событий.
• Риск циклов событий: Возможны deadlock-ситуации или незавершенные Saga из-за потерянных событий.
• Трудности дебага: Распределенная логика требует сложного инструментария для трассировки.

Ключевые критерии выбора

• Orchestration предпочтительнее для сложных бизнес-процессов с многими шагами, где нужен четкий контроль и мониторинг.
• Choreography лучше подходит для простых сценариев с небольшим количеством сервисов или в системах с уже развитой event-driven инфраструктурой.

В Go разработке для реализации Saga часто используют:

• Для Orchestration: фреймворки типа Cadence или Temporal, или собственные решения на основе goroutines и channels.
• Для Choreography: шины событий (NATS, Kafka) и библиотеки (Watermill, Go-EventBus).

Выбор вида Saga зависит от требований к сложности, наблюдаемости и масштабируемости вашей микросервисной архитектуры.