Согласованность данных между микросервисами с RabbitMq

Question

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

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

Я попытался разбить это ОЧЕНЬ простое требование на несколько микросервисов. Они определены ниже:

API предоставляет различные уровни функциональности - он позволяет нам создавать нового клиента, и это вызывает следующее:

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

Например, мы можем сделать следующее и предположить, что SQL будет управлять блокировкой, что означает, что число должно заканчиваться на правильном числе, когда два заказа обрабатываются одновременно:

UPDATE [orderms].[customers] SET CreditLimit = CreditLimit - 100, NoOfOrders = NoOfOrders + 1 WHERE CustomerId = 1

С учетом вышеизложенного, если кредит был равен 1000, и 2 заказа по 100 обрабатываются, и каждый заказ распределяется по отдельному экземпляру микросервиса «Заказ», мы должны предполагать, что правильные цифры будут присутствовать в таблица клиентов в микросервисе заказа (блокировка на основе запросов MSSQL должна позаботиться об этом автоматически).

Проблема возникает тогда, когда мы пытаемся интегрировать их обратно в микросервис клиента. У нас будет два сообщения от каждого экземпляра микросервиса заказа, передаваемого как событие, например, как показано ниже:

Учитывая вышеизложенное - вероятно, мы будем следовать схеме обновления таблицы SQL «Клиент» согласно следующему (это два запроса):

UPDATE [customerms].[customers] SET CreditLimit = 900.00 WHERE CustomerId = 1
UPDATE [customerms].[customers] SET CreditLimit = 800.00 WHERE CustomerId = 1

Однако - в зависимости от скорости, с которой работают эти "Микросервисы" Клиента, Экземпляр # 1 может в настоящий момент создавать несколько новых Клиентов, и поэтому может обрабатывать этот запрос медленнее, чем Экземпляр № 2, что означает запросы SQL будет выполнено не по порядку, и поэтому у нас останется база данных «Заказ» с CreditLimit 800 (правильно) и клиентская микросервис с CreditLimit 900 (неправильно).

В монолитном приложении мы обычно добавляем элемент блокировки (или, возможно, Mutex), если это действительно необходимо, в противном случае мы будем полагаться на блокировку SQL согласно функциональности в микросервисе Order, однако, поскольку это распределенный процесс, ни один из этих более старых методов не будет применяться.

Есть совет? Кажется, я не вижу, как это проходит?

Answer 1

Решение на мой взгляд

Поддерживать начальный кредитный лимит в обоих микросервисах. Скажите, что начальный кредитный лимит равен 1000, и установите его в обеих БД Microservices. Когда заказ обрабатывается, сначала уменьшите его в микросервисах заказа и вместо отправки кредитного лимита (800, 900 или любой суммы) отправьте сумму, которая должна быть уменьшена с кредитного лимита микросервисов клиента.

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

Источник событий (лучший подход)

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