Как откатить MicroServices

Question

У меня есть сомнения, связанные с MicroServices. Предположим, есть 5 микро-сервисов, скажем, M1, M2, M3, M3, M4 и M5. Есть 4 базы данных, которые подключены / доступны через 4 микросервиса. Например, M2 подключен к MySql, M3 подключен к Cassandra, M4 подключен к MangoDb и M5 подключен к Oracle.

Теперь

Шаг-1: M1 звонит в M2, чтобы обновить некоторые пользовательские данные в mySql, и он успешно обновился, после чего наконец получил ответ об успешном выполнении от M2

Step-2: M1 звонит M3 для обновления некоторых данных в Cassandra, и он успешно обновляется, а затем, наконец, получает ответ об успешном выполнении от M3

Шаг 3: M1 звонит M4 для обновления некоторых данных в MangoDb ине удалось из-за какой-либо проблемы с сервером БД или любой другой проблемы.

Здесь мое требование заключается в том, что я хочу откатить изменения БД, которые произошли с предыдущими микро-сервисами (M2 и M3)

Что мы должнынужно сделать, чтобы достичь такого сценария отката?

Answer 1

Это типичный случай распределенной транзакции. Независимо от того, что вы используете отдельную технологию для своей базы данных или одну и ту же на другом сервере, вы выполняете операцию, которая является транзакционной. Чтобы обработать откат для этого типа транзакции, вы не можете ретранслировать механизм баз данных для транзакций и откатов. Вы должны сделать это самостоятельно.

Saga Pattern

Распространенным решением для сценариев распределенных транзакций в микросервисной архитектуре является Saga pattern ,Распределенные саги - это шаблон для управления сбоями в сценариях, который вы описали.

Saga создаются на основе бизнес-процесса, например «Купить продукт в интернет-магазине». Этот процесс может включать несколько действий с несколькими микро-сервисами. Saga будет контролировать и управлять выполнением этого процесса, и в случае сбоя одного из шагов она будет запускать действия, чтобы отменить действия, выполненные до неудачного действия.

Существует несколько способов реализации саг. Это зависит от вашей архитектуры и от того, как ваши микро-сервисы взаимодействуют друг с другом. Используете ли вы команды и / или события?

---

Пример

Бизнес-процесс «Купи товар в интернет-магазине». Допустим, этот бизнес-процесс состоит из 3 простых шагов, выполняемых 3 различными микроуслугами:

• Действие 1 - резервирование продукта в продуктах-инвентарь-микроуслуга
• Действие 2 - проверка платежав платежном микро-сервисе
• Действие 3 - Заказать продукт в заказном микро-сервисе

Использование событий:

Вы можетепубликуйте события для выполнения какого-либо действия (или действий), и если одно из действий не выполняется, вы можете опубликовать событие отмены (или удаления) для этого события. Для приведенного выше бизнес-процесса, скажем, 1. Действие выполнено успешно, а 2. Действие завершено неудачно. В этом случае для отката действия 1. Вы должны опубликовать событие, подобное «RemoveReservationFromProduct», чтобы удалить резервирование и вернуть состояние обратно в состояние, которое было до запуска транзакции для этого бизнес-процесса. Это событие будет обработано обработчиком события, который переместит это состояние в вашу базу данных. Поскольку это событие, вы можете реализовать механизм повторных попыток для сбоев или просто повторно применить его позже, если в коде есть какая-то ошибка.

Использование команд:

Если у вас естьНаправляя вызовы к вашим микро-сервисам в виде команд, используя какой-то API отдыха, вы можете запустить некоторые конечные точки удаления или обновления, чтобы отменить изменения, которые вы сделали. Для приведенного выше бизнес-процесса, скажем, 1. Действие выполнено успешно, а 2. Действие завершено неудачно. В этом случае для отката действия 1. Вы должны вызвать api delete, чтобы удалить резервирование для определенного продукта, чтобы удалить резервирование и вернуть состояние обратно в состояние, которое было до запуска транзакции для этого бизнес-процесса. ,

Вы можете взглянуть на этот пример реализации шаблона Saga.

Answer 2

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

Answer 3

чтобы ответить на ваш вопрос, давайте добавим некоторые бизнес-требования

Случай 1 . M1 выполняет все взаимодействие с другими микросервисами на основе события, полученного, например, «Заказ размещен»

Теперь в этом случае обновление M2 ... M5,

требование 1: если все онинезависимо друг от друга.

сначала создайте 5 событий из одного события, а затем

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

(вы могли бы реализовать подобную логику, используя очередь аварийного переключения - которая через некоторое время отправляет то же событие обратно в исходную очередь)

требование 2: если все не являются независимыми

использовать одно событие и все то же решение.

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

Случай 2. если вызывается API M1 и M1 должен выполнить все задачи из нескольких микросервисов, а затем дать ответ пользователю.

мы могли бы создать запущенное событиев микросервисной базе данных M1 (sync_event_table) попробуйте выполнить обновление во всех микросервисах после завершения всего, обновите таблицу событий синхронизации с завершенными значениями

для тех случаев, которые не завершены - запустите таймер, который проверяет задания, которые не были выполненыдля> X мин, а затем выполните действия по отмене или все, что требуется,

Суть:

Так что если уВы видите, что все решения предлагают вашей системе повернуть все различия. микросервисное обновление

путем создания задания

проверка статуса задания

написание функции отмены / возврата задания

Answer 4

Вы можете убедиться, что у вас включен @Transactional во всей этой последовательности вызовов.

1. Рассматривать вызов всех микросервисов из M1 как одну транзакцию.
2. Предоставить откат вследующим образом:
   • При обновлении БД в M2, M3 и M4 поместите значения в кэш Spring также вместе с БД.
   • При вызове / откате в M2, M3 или M4 получитезначения из Spring Cache и отмените их из БД.
3. В fallbackMethod команды hysterix, когда M1 отвечает с ошибкой или выводом по умолчанию, вызывает / откатывает другие службы.

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