Распределенные транзакции в микросервисной архитектуре: Обеспечение целостности данных в финансовых ПО с помощью паттерна Saga

Введение и архитектура распределенных систем

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

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

Что такое паттерн Saga и как он работает?

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

Однако при возникновении ошибки на любом этапе цепочки вступает в силу паттерн Saga. Запускаются компенсирующие транзакции (compensating transactions), которые обращают вспять эффекты успешно завершенных предыдущих шагов. Этот механизм работает на основе принципа итоговой согласованности (eventual consistency) и обеспечивает критически важную защиту для финансового программного обеспечения.

Пошаговые методы реализации Saga

При интеграции паттерна Saga в вашу архитектуру вы можете выбрать два основных подхода:

1. Хореографическая Saga (Choreography)

В этом методе, где нет центрального координатора, сервисы взаимодействуют друг с другом посредством событий (events).

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

2. Оркестровая Saga (Orchestration)

В этой структуре, где есть центральный менеджер (orchestrator), весь рабочий процесс контролируется одним компонентом.

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

Применение в финансовых процессах и на что следует обратить внимание

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

• Компенсирующие транзакции обязательно должны быть спроектированы как идеопотентные (дающие одинаковый результат при повторении того же запроса).
• Очереди сообщений должны быть настроены отказоустойчивыми к обрывам связи или сбоям сервисов.
• Необходимо настроить централизованные механизмы логирования и отслеживания для мгновенного мониторинга статусов транзакций.

Заключение

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

Работа на основе гипотетического финансового сценария

Чтобы конкретизировать работу паттерна Saga на практике, давайте рассмотрим сценарий многонационального денежного перевода и конвертации валюты. Когда пользователь инициирует перевод иностранной валюты с исходного счета на целевой, в игру вступают три отдельных микросервиса: Сервис баланса счетов, Сервис конвертации валюты и Сервис бухгалтерского учета. На первом этапе Сервис баланса счетов списывает сумму с локальной базы данных пользователя и создает сообщение об успехе. На втором этапе Сервис конвертации валюты выполняет конвертацию по текущим обменным курсам, однако на этапе Сервиса бухгалтерского учета, который является третьим шагом, происходит непредвиденная ошибка тайм-аута базы данных. В этом сценарии вместо традиционных механизмов блокировки запускается принцип итоговой согласованности. Как только сервис-оркестратор обнаруживает сигнал ошибки, он запускает процессы компенсации. Конвертация валюты отменяется, а сумма, списанная со счета на первом этапе, возвращается пользователю Сервисом баланса счетов посредством компенсирующей транзакции (compensating transaction). Самый большой архитектурный компромисс, который следует учитывать в этом процессе, заключается в повышении доступности (availability) системы за счет отказа от мгновенной согласованности. Информация о том, что транзакция находится в ожидании, должна прозрачно передаваться в пользовательском интерфейсе.

Контрольный список реализации и управления ошибками

Существуют критические моменты, которые следует учитывать при выходе паттерна Saga в продакшн-среду в распределенной финансовой архитектуре. Во-первых, все компенсирующие транзакции и команды должны быть спроектированы строго идеопотентными (повторяемыми). В случае повторной доставки того же сообщения из-за сбоев сети следует использовать уникальные ключи идеопотентности (idempotency keys), чтобы предотвратить дублирование операций списания или возврата средств. Во-вторых, сценарии очереди невостребованных писем (Dead Letter Queue), с которыми можно столкнуться в очередях сообщений (Message Broker), должны быть запланированы заранее, и для исключительных ситуаций, требующих ручного вмешательства, должны быть созданы механизмы тревоги. В-третьих, проверяемость (auditability) обязательна при интеграции Финансовых и бухгалтерских систем; поэтому статус каждого шага Saga, временная метка и логи ошибок должны храниться в централизованной инфраструктуре логирования. На последнем этапе система должна пройти нагрузочное тестирование, в ходе которого будет подробно проанализировано, создают ли сервисы-оркестраторы узкие места при высоком трафике, а также время задержки компенсирующих транзакций.

Источники

• Финансовые и бухгалтерские системы — Cy Logic Software