Транзакции микросервисов и согласованность данных

Введение

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

Подходы к согласованности данных

Транзакции в одном сервисе

Каждый микросервис отвечает за собственную базу данных и может использовать стандартные транзакции ACID для внутренних операций:

import psycopg2

conn = psycopg2.connect("dbname=test user=postgres password=secret")
cur = conn.cursor()
try:
    cur.execute("INSERT INTO orders (id, amount) VALUES (1, 100)")
    cur.execute("INSERT INTO payments (order_id, status) VALUES (1, 'pending')")
    conn.commit()
except Exception:
    conn.rollback()
finally:
    cur.close()
    conn.close()

Внутри сервиса транзакции обеспечивают атомарность, целостность и откат при ошибках.

Согласованность между микросервисами

Для обеспечения согласованности между сервисами применяют несколько стратегий:

• Eventual consistency — данные могут быть временно рассинхронизированы, но в итоге придут к согласованному состоянию;
• Саги (Sagas) — последовательность локальных транзакций с компенсационными действиями;
• Event-driven подход — обмен событиями через брокеры сообщений (Kafka, RabbitMQ).

Пример саги на псевдокоде:

Сервис Orders создал заказ
→ отправляет событие OrderCreated
Сервис Payments обрабатывает событие
→ создает платеж
Если платеж не прошел
→ отправляет событие PaymentFailed
Сервис Orders откатывает заказ

Если вы хотите детальнее изучить работу с распределёнными транзакциями и согласованностью данных — приходите на наш курс Microservices. На курсе 94 урока и 5 упражнений, AI-тренажеры для безлимитной практики с кодом и задачами 24/7, решение задач с живым ревью наставника, еженедельные встречи с менторами.

Event-driven взаимодействие

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

Пример публикации события в Python через Kafka:

from kafka import KafkaProducer
import json

producer = KafkaProducer(bootstrap_servers='localhost:9092',
                         value_serializer=lambda v: json.dumps(v).encode('utf-8'))

event = {"order_id": 1, "status": "created"}
producer.send('orders', value=event)
producer.flush()

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

Частые ошибки

• Попытка использовать монолитные транзакции ACID между сервисами;
• Отсутствие компенсационных механизмов при сбое;
• Игнорирование временной рассинхронизации данных;
• Неправильная обработка ошибок при событийном обмене.

Частозадаваемые вопросы

Можно ли полностью гарантировать согласованность данных? Полная ACID-согласованность между микросервисами невозможна; применяют eventual consistency и саги.

Что выбрать: события или саги? Саги подходят для последовательных транзакций с компенсациями, события — для асинхронной обработки и высокой масштабируемости.

Заключение

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

Использование этих подходов ускоряет разработку надёжных распределённых систем. Для закрепления навыков работы с транзакциями и согласованностью данных и изучения дополнительных механизмов рекомендуем курс Microservices. В первых 3 модулях курса доступно бесплатное содержание, что позволяет попробовать подходы на практике и понять структуру курса до покупки полного доступа.