Распределенные транзакции и стратегии двухфазного коммита в финансовом ПО на базе микросервисов

Введение и архитектурная трансформация

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

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

Проблемы распределенных транзакций и целостности данных

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

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

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

Протокол двухфазного коммита (2PC)

Одним из наиболее известных подходов к сохранению атомарности в распределенных транзакциях является протокол двухфазного коммита (Two-Phase Commit - 2PC). Этот протокол гарантирует, что транзакция либо одобрена всеми сервисами-участниками, либо совместно отменена.

1. Фаза подготовки (Prepare Phase)

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

2. Фаза коммита (Commit Phase)

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

Альтернативные подходы и компенсирующие транзакции

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

• Паттерн Saga: Подход, который делит долгоиграющие распределенные транзакции на ряд локальных шагов и определяет обратимую компенсирующую транзакцию (compensating transaction) для каждого шага. Когда один шаг терпит неудачу, шаги обратной компенсации запускаются последовательно.
• Конечная согласованность (Eventual Consistency): Вместо мгновенных блокировок обеспечивается синхронизация данных во всех сервисах в течение определенного периода времени с использованием событийно-ориентированной архитектуры (Event-Driven Architecture).

Заключение

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

Гипотетический пример сценария и рабочий процесс

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

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

При запуске архитектуры распределенных транзакций в финансовых системах на базе микросервисов в эксплуатацию необходимо соблюдать определенные инженерные стандарты. Во-первых, время ожидания (timeout) должно быть точно настроено для таких сценариев, как разделение сети (network partition) и сбой координатора. Автоматические механизмы компенсации должны быть активированы, чтобы предотвратить бесконечное нахождение системы в неопределенном состоянии (in-doubt state), когда сервисы-участники не отвечают. Во-вторых, все шаги распределенной транзакции должны мониториться с помощью централизованной инфраструктуры логирования и распределенной трассировки (distributed tracing), обеспечивая сопоставление каждого шага с уникальными идентификаторами транзакций. На этапе управления ошибками для разрывов соединения с базой данных и исключений взаимоблокировок (deadlock) должны применяться политики экспоненциального отката с повторными попытками (exponential backoff). Однако для защиты финансовой целостности данных нельзя идти на компромисс с принципами идеопотентности (повторяемости) проектирования. Таким образом, даже если один и тот же запрос по ошибке запускается более одного раза, балансы не подвергаются повторной обработке.

Источники

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