Микросервисная архитектура — как реализовать транзакции?
Добрый день.
Решил в свободное время спроектировать, а затем уже реализовать сервис-ориентированный проект в целях изучения подхода. Начал прикидывать приблизительное ПО, которое будет использоваться.
Но один вопрос не даёт мне покоя и который я не понимаю: целостность данных при падениях компонентов сервиса. Здесь наверняка должна быть реализована очередь сообщений через кроссплатформенный протокол. Например, AMQP.
1) Как реализуются транзакции в данном случае? У AMQP кажется есть два вида транзакций, но насколько я понял, все они предлагают транзакции сообщений в очереди. Как же быть с данными, которые, возможно, уже будут внесены в БД? Или транзакция протокола это покрывает?
2) Что происходит с сообщением, если сервис, допустим, застрял на дедлоке? Есть ли возможность повторить обработку сообщения сервисом?
3) Если два вопроса чертовски глупые, то возникает вопрос - а как правильно реализовывать транзакции? Распределенные транзакции могли бы быть вариантом, если бы не условие, что БД в такой архитектуре могут быть разными и далеко не во всех из них есть достойная поддержка распределённых транзакций.
Ох и щепетильная же тема. И тут слишком много вопросов, каждый из которых отдельно надо рассматривать. Если совсем коротко то тема данного вопроса гуглится как Distributed Transactions. Основой распределенных транзакций является оркестрация микросервисов и Saga Pattern. Организовывается действительно через очереди, но чаще всего они скрыты под капотом Workflow Manager (Zeebe, AWS StepFunctions, ...)...
Целостность данных в распределенных системах не бывает 100%. Вернее есть моменты в которые это случается, но это скорее чудо. За проверку консистентности данных отвечают дополнительные механизмы, занимающиеся их фоновым аудитом.
Недоступность сервисов решается проще всего - через Circuit Breaker Design Pattern.
Средний
Простой
Простой
Простой
Средний
