Репликация данных в микросервисах

Question

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

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

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

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

Есть два варианта решения этой проблемы.

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

• Другой способ - скопировать частичные данные, используя pub / sub, что требуется микросервисом транзакции и заказа в самой службе.Так что в основном это что-то вроде новой таблицы в микросервисе заказа и принятия соединения в сервисе для обслуживания данных.таким образом убивая необходимость делать зависимые звонки.

Итак, во-первых, является ли собственно разделение услуг?

секунда, какой из двух методов является лучшим вариантом

Примечание: у нас есть около 10 сервисов, которые будут зависеть от базы данных товаров.Также на странице обычно есть звонки на 5-6 микросервисов.Хорошо, что у нас есть собственный шлюз, который выполняет все вызовы параллельно.Таким образом, если мы используем первый метод, будет не более 2 последовательных вызовов.

Answer 1

когда мы хотим видеть список транзакций, выполненных пользователем => Это в основном аудит и, в конечном счете, analytix.

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

По мере перехода к шаблону микросервисов - лучшим подходом здесь будет иметьТекущие службы сделали запись в аудитах со всеми подробностями, и события будут лучшим выбором здесь, так что ваш аудит (или будущий аналитический модуль) может работать независимо.Таким образом, если все службы генерируют необходимые события, которые необходимы для целей аудита / отчетности, вы можете создать микросервис аудита / отчетности, который имеет дело с остальными - да, он будет дублировать данные, но всегда лучше держать аудиты подальше отфактические данные.

Answer 2

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

Неплохая практика хранить дублированные данные других сервисов, если вы собираетесь добиться слабой связи.Еще одной модификацией вашего дизайна может быть использование CQRS / Event Sourcing.Вы сохраните все свои события в хранилище событий и создадите модель / проекции только для чтения из этого хранилища событий.Это очень мощный паттерн, но помните, что это сложный паттерн и может быть излишним.