Как реализуются распределенные транзакции в микросервисной архитектуре? Какие паттерны вы знаете и применяли?

В Go, как и в большинстве современных языков, нет встроенной поддержки распределенных транзакций по протоколу XA (eXtended Architecture), который был популярен в монолитных системах. В микросервисной архитектуре для обеспечения согласованности данных между сервисами используются специальные паттерны.

Основные паттерны:

1. Saga (Сага)

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

• Преимущества: Слабая связанность (loose coupling) сервисов, высокая доступность (не требует блокировки всех ресурсов).
• Недостатки: Сложность в реализации и отладке, особенно компенсирующих транзакций. Обеспечивает только итоговую согласованность (eventual consistency).

Пример логики саги:

// Псевдокод для демонстрации
func CreateOrderSaga(order Order, payment Payment) error {
    // Шаг 1: Создать заказ в сервисе заказов
    if err := orderService.Create(order); err != nil {
        return fmt.Errorf("order creation failed: %w", err)
    }

    // Шаг 2: Списать средства в платежном сервисе
    if err := paymentService.Process(payment); err != nil {
        // Компенсирующее действие
        orderService.Cancel(order.ID) 
        return fmt.Errorf("payment processing failed: %w", err)
    }

    // (Опционально) Шаг 3: Уведомить службу доставки
    // ...

    return nil
}

2. Two-Phase Commit (2PC, Двухфазный коммит)

Этот паттерн обеспечивает строгую согласованность (strong consistency) за счет централизованного координатора.

1. Фаза 1 (Prepare/Vote): Координатор спрашивает все сервисы-участники, готовы ли они зафиксировать транзакцию. Участники блокируют ресурсы и отвечают да или нет.
2. Фаза 2 (Commit/Abort): Если все ответили да, координатор отправляет команду commit. Если хотя бы один ответил нет или не ответил, координатор отправляет всем команду abort (откат).

• Преимущества: Гарантирует атомарность транзакции.
• Недостатки: Низкая производительность из-за блокировок, координатор является единой точкой отказа (SPOF).

3. Outbox Pattern

Этот паттерн используется для надежной публикации событий из сервиса. Вместо того чтобы напрямую отправлять событие в брокер сообщений (например, Kafka или RabbitMQ) после изменения данных в БД, сервис выполняет две операции в рамках одной локальной транзакции:

1. Записывает изменения в свою основную таблицу.
2. Записывает событие в специальную таблицу outbox.

Отдельный процесс (или сам сервис) асинхронно читает события из таблицы outbox и надежно доставляет их в брокер сообщений. Это гарантирует, что событие будет отправлено тогда и только тогда, когда локальная транзакция успешно завершена.