Как построить межсервисную транзакцию?

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

Основные подходы:

1. Сага (наиболее распространенная)

• последовательность локальных транзакций в сервисах;

• в случае отказа срабатывают компенсирующие действия.

1. Сага об оркестровке

• центральный оркестратор управляет шагами и откатами.

1. Хореографическая сага

— службы реагируют на события друг друга без центрального проводника.

1. 2ПК/ХА

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

Канонический дизайн межсервисной транзакции:

1. Разбейте процесс на локальные атомарные этапы.

2. Для каждого шага определите компенсацию.

3. Обеспечить идемпотентность команд и событий.

4. Внедрите надежную доставку по шаблонам «исходящие/входящие».

5. Добавьте корреляционный transaction/saga id для трассировки.

Критические требования:

1. Идемпотентность на всех границах.

2. Повторить попытку в случае временных сбоев.

3. Дедупликация повторно доставленных событий.

4. Политика тайм-аута и недоставленных сообщений для «зависающих» шагов.

5. Наблюдаемость: статусы саг, метрики, аудит.

Заключение:

Межсервисная транзакция в микросервисах — это не глобальный ACID, а управляемый процесс согласованности: локальные транзакции + события + компенсации. Наиболее практичной моделью для этого является Saga с четкими инвариантами и надежной обработкой ошибок.

Пример:

Пример

// Спрощений оркестратор Saga
func (s *Saga) Run(ctx context.Context, cmd CreateOrder) error {
	if err := s.reserveInventory(ctx, cmd); err != nil {
		return err
	}
	if err := s.chargePayment(ctx, cmd); err != nil {
		_ = s.compensateInventory(ctx, cmd)
		return err
	}
	return s.confirmOrder(ctx, cmd)
}

Итог

В микросервисах классическая ACID-транзакция между несколькими БД/сервисами обычно непрактична.