Сделки в микросервисах

Question

Я прочитал несколько статей о архитектуре микросервисов, но никто не принимает тему транзакции. Все, что они говорят, что это трудно сделать. Может быть, кто-то может описать, как с этим справиться?

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

Кто знает некоторые библиотеки или проект для этой проблемы?

Answer 1

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

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

Answer 2

Я не могу быть экспертом в этом, но я уверен, что вы направляетесь к Распределенные транзакции. Чтобы они работали, всем компонентам службы приложений нужен общий общий идентификатор транзакции, и вы должны убедиться, что каждый компонент информирован о состоянии транзакции. Он асинхронный, поэтому вам потребуются значительные прог-навыки.

Вот распределенные транзакции, упомянутые или обсуждавшиеся:

https://en.wikipedia.org/wiki/Distributed_transaction

http://contino.co.uk/microservices-not-a-free-lunch/

http://martinfowler.com/articles/microservices.html

Казалось бы, люди стараются избегать его, как это трудно. Может быть, поэтому вы ничего не нашли.

Надеется, что это помогает сделать шаг вперед :-)

Answer 3

здания на вершине предыдущих ответов, распределенные транзакции являются решением. На мой взгляд, вы не хотите создавать свои собственные механизмы отслеживания глобального транзакционного состояния, скорее, вы хотите использовать какой-то продукт - их несколько. Я написал длинную статью блог о решении этой проблемы с сервером приложений Java:

http://blog.maxant.co.uk/pebble/2015/08/04/1438716480000.html

Answer 4

двухфазная фиксация может быть option.Coordinator отправить совершить сообщение запроса cohorts.Cohorts отправить обратно ok.After затем координатор отправляет сообщение фиксации в когорты. Если какой-либо отказ происходит, координатор отправляет сообщения отката в когорты.

Answer 5

Первый необработанный вещь, которая пришла мне в голову после прочтения этого вопроса заключается в создании каждой добавить апи с удалить ИПН с, позволяет сказать, дополнительный DelFlag логический флаг.

boolean flag delFlag;

Для POST это будет 0. Для DELETE это будет 1.

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

PS- Просто сырая мысль. Исправьте меня, если вы считаете, что это неправильно.

Answer 6

Вы можете использовать механизм рабочего процесса (например, JBPM, Activiti) для организации логики и обработки транзакций или компенсационных транзакций в ней для достижения целостности данных. Это аналогичный случай, который вы используете в архитектуре SOA с ESB, BPMN и веб-сервисами.