Шаблон Saga в распределённых транзакциях - с примерами на Go

Шаблон Saga предоставляет элегантное решение, разбивая распределённые транзакции на серию локальных транзакций с компенсирующими действиями.

Вместо использования распределённых блокировок, которые могут блокировать операции между сервисами, шаблон Saga обеспечивает конечную согласованность через последовательность обратимых шагов, что делает его идеальным для длительных бизнес-процессов.

В микросервисных архитектурах поддержание согласованности данных между сервисами является одной из самых сложных задач. Традиционные транзакции ACID не работают, когда операции охватывают несколько сервисов с независимыми базами данных, оставляя разработчиков в поисках альтернативных подходов для обеспечения целостности данных.

Это руководство демонстрирует реализацию шаблона Saga на языке Go с практическими примерами, охватывающими оба подхода: оркестрацию и хореографию. Если вам нужна быстрая справка по основам Go, Голанг Шпаргалка предоставляет полезный обзор.

Это приятное изображение было сгенерировано AI-моделью Flux 1 dev.

Понимание шаблона Saga

Шаблон Saga был впервые описан Хектором Гарсиа-Молиной и Кеннетом Салемом в 1987 году. В контексте микросервисов это последовательность локальных транзакций, где каждая транзакция обновляет данные внутри одного сервиса. Если какой-либо шаг терпит неудачу, выполняются компенсирующие транзакции для отмены эффектов предыдущих шагов.

В отличие от традиционных распределённых транзакций, использующих двухфазное подтверждение (2PC), шаблон Saga не удерживает блокировки между сервисами, делая его подходящим для длительных бизнес-процессов. Цена за это - конечная согласованность вместо сильной согласованности.

Ключевые характеристики

• Нет распределённых блокировок: Каждый сервис управляет своими локальными транзакциями
• Компенсирующие действия: У каждой операции есть соответствующий механизм отката
• Конечная согласованность: Система в конечном итоге достигает согласованного состояния
• Длительные процессы: Подходит для процессов, которые занимают секунды, минуты или даже часы

Подходы к реализации Saga

Существует два основных подхода к реализации шаблона Saga: оркестрация и хореография.

Шаблон оркестрации

В оркестрации центральный координатор (оркестратор) управляет всем потоком транзакций. Оркестратор отвечает за:

• Вызов сервисов в правильном порядке
• Обработку ошибок и запуск компенсаций
• Поддержание состояния саги
• Координацию повторных попыток и таймаутов

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

• Централизованный контроль и видимость
• Легче понять и отладить
• Лучшая обработка ошибок и восстановление
• Проще тестирование общего потока

Недостатки:

• Единая точка отказа (хотя это можно смягчить)
• Дополнительный сервис для поддержки
• Может стать узким местом для сложных потоков

Пример на Go:

type OrderSagaOrchestrator struct {
    orderService    OrderService
    paymentService  PaymentService
    inventoryService InventoryService
    shippingService ShippingService
}

func (o *OrderSagaOrchestrator) CreateOrder(order Order) error {
    sagaID := generateSagaID()

    // Шаг 1: Создание заказа
    orderID, err := o.orderService.Create(order)
    if err != nil {
        return err
    }

    // Шаг 2: Резервирование инвентаря
    if err := o.inventoryService.Reserve(order.Items); err != nil {
        o.orderService.Cancel(orderID) // Компенсация
        return err
    }

    // Шаг 3: Обработка платежа
    paymentID, err := o.paymentService.Charge(order.CustomerID, order.Total)
    if err != nil {
        o.inventoryService.Release(order.Items) // Компенсация
        o.orderService.Cancel(orderID)          // Компенсация
        return err
    }

    // Шаг 4: Создание отправки
    if err := o.shippingService.CreateShipment(orderID); err != nil {
        o.paymentService.Refund(paymentID)      // Компенсация
        o.inventoryService.Release(order.Items) // Компенсация
        o.orderService.Cancel(orderID)          // Компенсация
        return err
    }

    return nil
}

Шаблон хореографии

В хореографии нет центрального координатора. Каждый сервис знает, что делать, и общается через события. Сервисы слушают события и реагируют соответствующим образом. Этот подход, основанный на событиях, особенно мощный в сочетании с платформами потоковой передачи сообщений, такими как AWS Kinesis, которые предоставляют масштабируемую инфраструктуру для распределения событий между микросервисами. Для всестороннего руководства по реализации микросервисов, ориентированных на события, с использованием Kinesis, см. Создание микросервисов, ориентированных на события, с AWS Kinesis.

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

• Децентрализованный и масштабируемый
• Нет единой точки отказа
• Сервисы остаются слабо связанными
• Естественное соответствие архитектурам, ориентированным на события

Недостатки:

• Сложнее понять общий поток
• Трудно отладить и проследить
• Сложная обработка ошибок
• Риск циклических зависимостей

Пример с архитектурой, ориентированной на события:

// Сервис заказов
type OrderService struct {
    eventBus EventBus
    repo     OrderRepository
}

func (s *OrderService) CreateOrder(order Order) (string, error) {
    orderID, err := s.repo.Save(order)
    if err != nil {
        return "", err
    }

    s.eventBus.Publish("OrderCreated", OrderCreatedEvent{
        OrderID:    orderID,
        CustomerID: order.CustomerID,
        Items:      order.Items,
        Total:      order.Total,
    })

    return orderID, nil
}

func (s *OrderService) HandlePaymentFailed(event PaymentFailedEvent) error {
    return s.repo.Cancel(event.OrderID) // Компенсация
}

// Сервис платежей
type PaymentService struct {
    eventBus EventBus
    client   PaymentClient
}

func (s *PaymentService) HandleOrderCreated(event OrderCreatedEvent) {
    paymentID, err := s.client.Charge(event.CustomerID, event.Total)
    if err != nil {
        s.eventBus.Publish("PaymentFailed", PaymentFailedEvent{
            OrderID: event.OrderID,
        })
        return
    }

    s.eventBus.Publish("PaymentSucceeded", PaymentSucceededEvent{
        OrderID:   event.OrderID,
        PaymentID: paymentID,
    })
}

func (s *PaymentService) HandleInventoryReservationFailed(event InventoryReservationFailedEvent) error {
    // Компенсация: возврат платежа
    return s.client.Refund(event.PaymentID)
}

Стратегии компенсации

Компенсация - это сердце шаблона Saga. Каждая операция должна иметь соответствующую компенсацию, которая может отменить её эффекты.

Типы компенсации

1. Обратимые операции: Операции, которые можно напрямую отменить

   • Пример: Освобождение зарезервированного инвентаря, возврат платежей

2. Компенсирующие действия: Разные операции, которые достигают обратного эффекта

   • Пример: Отмена заказа вместо его удаления

3. Пессимистическая компенсация: Предварительное выделение ресурсов, которые можно освободить

   • Пример: Резервирование инвентаря перед списанием платежа

4. Оптимистическая компенсация: Выполнение операций и компенсация при необходимости

   • Пример: Списание платежа сначала, возврат, если инвентарь недоступен

Требования к идемпотентности

Все операции и компенсации должны быть идемпотентными. Это обеспечивает, что повторный запуск неудавшейся операции не вызывает дублирующих эффектов.

func (s *PaymentService) Refund(paymentID string) error {
    // Проверка, был ли уже возврат
    payment, err := s.getPayment(paymentID)
    if err != nil {
        return err
    }

    if payment.Status == "refunded" {
        return nil // Уже возвращено, идемпотентно
    }

    // Обработка возврата
    return s.processRefund(paymentID)
}

Лучшие практики

1. Управление состоянием Saga

Поддерживайте состояние каждой инстанции Saga для отслеживания прогресса и обеспечения восстановления. При сохранении состояния Saga в базе данных выбор правильного ORM критически важен для производительности и поддержки. Для реализаций на основе PostgreSQL рассмотрите сравнение в Сравнение Go ORM для PostgreSQL: GORM vs Ent vs Bun vs sqlc для выбора наилучшего решения для хранения состояния Saga:

type SagaState struct {
    ID           string
    Status       SagaStatus
    Steps        []SagaStep
    CurrentStep  int
    CreatedAt    time.Time
    UpdatedAt    time.Time
}

type SagaStep struct {
    Service     string
    Operation   string
    Status      StepStatus
    Compensated bool
    Data        map[string]interface{}
}

2. Обработка таймаутов

Реализуйте таймауты для каждого шага, чтобы предотвратить зависание Saga:

type SagaOrchestrator struct {
    timeout time.Duration
}

func (o *SagaOrchestrator) ExecuteWithTimeout(step SagaStep) error {
    ctx, cancel := context.WithTimeout(context.Background(), o.timeout)
    defer cancel()

    done := make(chan error, 1)
    go func() {
        done <- step.Execute()
    }()

    select {
    case err := <-done:
        return err
    case <-ctx.Done():
        // Произошел таймаут, компенсируем
        if err := step.Compensate(); err != nil {
            return fmt.Errorf("компенсация не удалась: %w", err)
        }
        return fmt.Errorf("шаг %s истек по времени через %v", step.Name(), o.timeout)
    }
}

3. Логика повторных попыток

Реализуйте экспоненциальный бэкофф для временных сбоев:

func retryWithBackoff(operation func() error, maxRetries int) error {
    backoff := time.Second
    for i := 0; i < maxRetries; i++ {
        err := operation()
        if err == nil {
            return nil
        }

        if !isTransientError(err) {
            return err
        }

        time.Sleep(backoff)
        backoff *= 2
    }
    return fmt.Errorf("операция не удалась после %d попыток", maxRetries)
}

4. Event Sourcing для состояния Saga

Используйте event sourcing для поддержания полного аудита. При реализации хранилищ событий и механизмов воспроизведения Go generics могут помочь создать безопасные для типов, повторно используемые обработчики событий. Для продвинутых паттернов с использованием generics в Go см. Go Generics: Use Cases and Patterns.

type SagaEvent struct {
    SagaID    string
    EventType string
    Payload   []byte
    Timestamp time.Time
    Version   int64
}

type SagaEventStore struct {
    store EventRepository
}

func (s *SagaEventStore) AppendEvent(sagaID string, eventType string, payload interface{}) error {
    data, err := json.Marshal(payload)
    if err != nil {
        return fmt.Errorf("не удалось сериализовать payload: %w", err)
    }

    version, err := s.store.GetNextVersion(sagaID)
    if err != nil {
        return fmt.Errorf("не удалось получить версию: %w", err)
    }

    event := SagaEvent{
        SagaID:    sagaID,
        EventType: eventType,
        Payload:   data,
        Timestamp: time.Now(),
        Version:   version,
    }

    return s.store.Save(event)
}

func (s *SagaEventStore) ReplaySaga(sagaID string) (*Saga, error) {
    events, err := s.store.GetEvents(sagaID)
    if err != nil {
        return nil, fmt.Errorf("не удалось получить события: %w", err)
    }

    saga := NewSaga()
    for _, event := range events {
        if err := saga.Apply(event); err != nil {
            return nil, fmt.Errorf("не удалось применить событие: %w", err)
        }
    }

    return saga, nil
}

5. Мониторинг и наблюдаемость

Реализуйте всеобъемлющее логирование и трассировку:

func (o *OrderSagaOrchestrator) CreateOrder(order Order) error {
    span := tracer.StartSpan("saga.create_order")
    defer span.Finish()

    span.SetTag("saga.id", sagaID)
    span.SetTag("order.id", order.ID)

    logger.WithFields(log.Fields{
        "saga_id": sagaID,
        "order_id": order.ID,
        "step": "create_order",
    }).Info("Saga начата")

    // ... выполнение Saga

    return nil
}

Общие паттерны и антипаттерны

Паттерны для следования

• Паттерн координатора Saga: Используйте выделенную службу для оркестрации
• Паттерн outbox: Обеспечьте надежную публикацию событий
• Идемпотентные ключи: Используйте уникальные ключи для всех операций
• Машина состояний Saga: Моделируйте Saga как машину состояний

Антипаттерны для избегания

• Синхронная компенсация: Не ждите завершения компенсации
• Вложенные Saga: Избегайте вызовов Saga другими Saga (используйте под-Saga вместо этого)
• Общее состояние: Не делите состояние между шагами Saga
• Долгие шаги: Разбивайте шаги, которые занимают слишком много времени

Инструменты и фреймворки

Несколько фреймворков могут помочь в реализации паттернов Saga:

• Temporal: Платформа оркестрации рабочих процессов с встроенной поддержкой Saga
• Zeebe: Движок рабочих процессов для оркестрации микросервисов
• Eventuate Tram: Фреймворк Saga для Spring Boot
• AWS Step Functions: Оркестрация рабочих процессов без сервера
• Apache Camel: Фреймворк интеграции с поддержкой Saga

Для сервисов оркестрации, которым нужны CLI-интерфейсы для управления и мониторинга, Создание CLI-приложений на Go с Cobra & Viper предоставляет отличные паттерны для создания командных инструментов для взаимодействия с оркестраторами Saga.

При развертывании микросервисов на основе Saga в Kubernetes реализация сервис-меша значительно улучшает наблюдаемость, безопасность и управление трафиком. Реализация сервис-меша с Istio и Linkerd охватывает, как сервис-меши дополняют распределенные транзакционные паттерны, предоставляя поперечные аспекты, такие как распределенная трассировка и прерывание цепи.

Когда использовать паттерн Saga

Используйте паттерн Saga, когда:

• ✅ Операции охватывают несколько микросервисов
• ✅ Долгие бизнес-процессы
• ✅ Приемлема конечная согласованность
• ✅ Нужно избегать распределенных блокировок
• ✅ Сервисы имеют независимые базы данных

Избегайте, когда:

• ❌ Требуется сильная согласованность
• ❌ Операции простые и быстрые
• ❌ Все сервисы используют одну и ту же базу данных
• ❌ Логика компенсации слишком сложная

Заключение

Паттерн Saga является ключевым для управления распределенными транзакциями в архитектурах микросервисов. Хотя он вводит сложность, он предоставляет практичное решение для поддержания согласованности данных через границы сервисов. Выбирайте оркестрацию для лучшего контроля и видимости или хореографию для масштабируемости и слабой связанности. Всегда убедитесь, что операции идемпотентны, реализуйте правильную логику компенсации и поддерживайте всеобъемлющую наблюдаемость.

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

Полезные ссылки

• Паттерны микросервисов от Криса Ричардсона
• Паттерн Saga - Мартин Фаулер
• Фреймворк Saga Eventuate Tram
• Движок рабочих процессов Temporal
• Документация AWS Step Functions
• Шпаргалка по Go
• Go Generics: Use Cases and Patterns
• Сравнение Go ORM для PostgreSQL: GORM vs Ent vs Bun vs sqlc
• Создание CLI-приложений на Go с Cobra & Viper
• Реализация сервис-меша с Istio и Linkerd
• Создание микросервисов с использованием событий с AWS Kinesis