Транзакции в микросервисах
Я прочитал несколько статей о архитектуре микросервисов, но никто не принимает тему транзакции. Все, что они говорят, что это трудно сделать. Может быть, кто-то может описать, как с этим справиться?
Но не с домена, а с технологической стороны. Допустим, что у нас есть бизнес-пример, когда нам нужно вызвать две разные службы, и оба они вносят некоторые изменения в базу данных. Но как откат, если какая-то ошибка возникает во втором?
Кто знает некоторые библиотеки или проект для этой проблемы?
Ответы
Ответ 1
Лучший дизайн - это изолированные службы: каждая служба просто выполняет свою работу в рамках собственной транзакции, и ваш рабочий процесс ожидает сбоев в одной службе.
Если вам действительно нужно зафиксировать, только если все службы вызываются без ошибок, вы должны создать службу более высокого уровня, которая выполняет эти вызовы внутри внешней транзакции.
Ответ 2
Я не могу быть экспертом в этом, но я уверен, что вы направляетесь к распределенным транзакциям. Чтобы они работали, всем компонентам службы приложений нужен общий общий идентификатор транзакции, и вы должны убедиться, что каждый компонент информирован о состоянии транзакции. Он асинхронный, поэтому вам потребуются значительные прог-навыки.
Здесь перечислены или обсуждены распределенные транзакции:
https://en.wikipedia.org/wiki/Distributed_transaction
http://contino.co.uk/microservices-not-a-free-lunch/
http://martinfowler.com/articles/microservices.html
Казалось бы, люди пытаются избежать этого, поскольку это сложно. Может быть, поэтому вы ничего не нашли.
Надеюсь, это поможет сделать шаг вперед: -)
Ответ 3
Первая полезная вещь, которая пришла мне в голову после прочтения этого вопроса, заключается в создании каждого add api с удалением api, скажем, дополнительным логическим флагом delFlag.
boolean flag delFlag;
Для POST это будет 0. Для DELETE это будет 1.
Теперь вы поддерживаете Менеджер транзакций, который является суперсервером для всех ваших микросервисов.
В этой службе поддерживаются очереди вызовов всех сервисов и API. Когда и когда служба терпит неудачу, получите вызывающий api и вызовите метод удаления этой службы и отмените все, что вы сделали.
PS - Просто сырая мысль. Исправьте меня, если вы считаете, что это неправильно.
Ответ 4
В основе предыдущих ответов относятся распределенные транзакции. На мой взгляд, вы не хотите создавать свои собственные механизмы отслеживания глобального транзакционного состояния, скорее, вы хотите использовать какой-то продукт - их несколько. Я написал длинную статью в блоге о решении этой проблемы с сервером приложений Java:
http://blog.maxant.co.uk/pebble/2015/08/04/1438716480000.html
Ответ 5
двухфазное коммита может быть опцией. Координируйте отправку сообщения запроса комманды в когорты. Координирует отправку обратно. После этого координатор отправляет сообщение фиксации в когорты. Если какой-либо отказ происходит, координатор отправляет сообщения отката в когорты.
Ответ 6
Вы можете использовать механизм рабочего процесса (например, JBPM, Activiti) для организации логики и обработки транзакций или компенсационных транзакций в ней для обеспечения целостности данных. Это аналогичный случай, который вы используете в архитектуре SOA с ESB, BPMN и веб-службами.