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

 Добрый день.  

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

  

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

  

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

  

1) Как реализуются транзакции в данном случае? У AMQP кажется есть два вида транзакций, но насколько я понял, все они предлагают транзакции сообщений в очереди. Как же быть с данными, которые, возможно, уже будут внесены в БД? Или транзакция протокола это покрывает?   

2) Что происходит с сообщением, если сервис, допустим, застрял на дедлоке? Есть ли возможность повторить обработку сообщения сервисом?   

3) Если два вопроса чертовски глупые, то возникает вопрос - а как правильно реализовывать транзакции? Распределенные транзакции могли бы быть вариантом, если бы не условие, что БД в такой архитектуре могут быть разными и далеко не во всех из них есть достойная поддержка распределённых транзакций. 

 Ох и щепетильная же тема. И тут слишком много вопросов, каждый из которых отдельно надо рассматривать. Если совсем коротко то тема данного вопроса гуглится как Distributed Transactions. Основой распределенных транзакций является оркестрация микросервисов и Saga Pattern. Организовывается действительно через очереди, но чаще всего они скрыты под капотом Workflow Manager (Zeebe, AWS StepFunctions, ...)...  

  

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

  

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