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

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

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

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

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

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

Понимание паттерна Saga

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

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

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

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

Подходы к реализации 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. Обработка таймаутов

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

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 для ведения полного аудиторского следа. При реализации хранилищ событий и механизмов воспроизведения, обобщения (generics) в Go могут помочь создать типобезопасный, многоразовый код обработки событий. С продвинутыми паттернами использования генериков в 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 Pattern: Обеспечьте надежную публикацию событий
• Ключи идемпотентности: Используйте уникальные ключи для всех операций
• Машина состояний Saga: Моделируйте saga как машину состояний

Антипаттерны, которых следует избегать

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

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

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

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

Для сервисов оркестратора, которым требуются интерфейсы командной строки для управления и мониторинга, статья Построение CLI-приложений в Go с Cobra & Viper предоставляет отличные паттерны для создания инструментов командной строки для взаимодействия с оркестраторами saga.

При развертывании микросервисов на основе saga в Kubernetes, реализация сервисной сетки (service mesh) может значительно улучшить наблюдаемость, безопасность и управление трафиком. Статья Реализация сервисной сетки с Istio и Linkerd охватывает, как сервисные сетки дополняют паттерны распределенных транзакций, предоставляя сквозные функции, такие как распределенная трассировка и circuit breaking.

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

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

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

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

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

Заключение

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

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

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

• Microservices Patterns by Chris Richardson
• Saga Pattern - Martin Fowler
• Eventuate Tram Saga Framework
• Temporal Workflow Engine
• AWS Step Functions Documentation
• Шпаргалка по Go
• Go Generics: Use Cases and Patterns
• Сравнение Go ORM для PostgreSQL: GORM vs Ent vs Bun vs sqlc
• Реализация CQRS в Go
• Построение CLI-приложений в Go с Cobra & Viper
• Реализация сервисной сетки с Istio и Linkerd
• Построение событийно-ориентированных микросервисов с AWS Kinesis