@Harry_The_Head

Микросервисная архитектура — как реализовать транзакции?

Добрый день.
Решил в свободное время спроектировать, а затем уже реализовать сервис-ориентированный проект в целях изучения подхода. Начал прикидывать приблизительное ПО, которое будет использоваться.

Безусловно должен быть Docker - удобен в деплоях и сам контейнер заменит мне виртуальную машину. Также было бы неплохо иметь некую ORM, которая из коробки умеет в распространенные БД. Здесь я остановился на Doctrine (хорошее покрытие БД из коробки + возможность написать свою прослойку под экзотическую sql-like базу). Выбор Doctrine предполагает, что сервисы будут на PHP, что не очень хорошо, но вполне приемлемо.

Но один вопрос не даёт мне покоя и который я не понимаю: целостность данных при падениях компонентов сервиса. Здесь наверняка должна быть реализована очередь сообщений через кроссплатформенный протокол. Например, AMQP.

1) Как реализуются транзакции в данном случае? У AMQP кажется есть два вида транзакций, но насколько я понял, все они предлагают транзакции сообщений в очереди. Как же быть с данными, которые, возможно, уже будут внесены в БД? Или транзакция протокола это покрывает?
2) Что происходит с сообщением, если сервис, допустим, застрял на дедлоке? Есть ли возможность повторить обработку сообщения сервисом?
3) Если два вопроса чертовски глупые, то возникает вопрос - а как правильно реализовывать транзакции? Распределенные транзакции могли бы быть вариантом, если бы не условие, что БД в такой архитектуре могут быть разными и далеко не во всех из них есть достойная поддержка распределённых транзакций.
  • Вопрос задан
  • 93 просмотра
Пригласить эксперта
Ответы на вопрос 1
inoise
@inoise
Solution Architect, AWS Certified, Serverless
Ох и щепетильная же тема. И тут слишком много вопросов, каждый из которых отдельно надо рассматривать. Если совсем коротко то тема данного вопроса гуглится как Distributed Transactions. Основой распределенных транзакций является оркестрация микросервисов и Saga Pattern. Организовывается действительно через очереди, но чаще всего они скрыты под капотом Workflow Manager (Zeebe, AWS StepFunctions, ...)...

Целостность данных в распределенных системах не бывает 100%. Вернее есть моменты в которые это случается, но это скорее чудо. За проверку консистентности данных отвечают дополнительные механизмы, занимающиеся их фоновым аудитом.

Недоступность сервисов решается проще всего - через Circuit Breaker Design Pattern.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы