Получение данных микросервисов
Добрый день Я прочитал несколько книг об архитектуре микросервисов, но у меня все еще есть вопрос ... Одна из них о ситуации, когда вам нужно получить данные о некоторых сущностях, которые связаны с другими ... например: у нас есть микросервисы заказов и пользователей, например, каждый заказ содержит некоторую информацию о пользователе, а клиент хочет получить заказы пользователей. поэтому я вижу три способа добиться этого:
- Клиентское приложение делает запрос на заказ микросервиса и после этого делает n запрос к микросервису пользователей для получения информации о пользователе в заказе
- Клиентское приложение делает запрос на заказ mircoservice, который делает запрос к микросервисам пользователей
- Заказ микросервиса db хранит необходимую информацию о пользователе
Для первого случая - клиентскому приложению сложно создавать и агрегировать данные из двух источников (заказов и пользователей)
Для второго случая - если у нас больше двух микросервисов, то общее время запроса будет расти
Для третьего случая связано с проблемой согласованности данных (пользователь изменил данные, но база данных заказа еще не обновляется)
какой чехол используется чаще всего?
и небольшой вопрос №2 - в случае использования микросервиса и веб-API - каждый микросервис содержит только один или, может быть, два контроллера?
Ответы 1
To answer to your all three cases, it will purely depend on microservices architecture.
Первый случай -> В этом случае ваш клиент должен дать консолидированный ответ, сделав вызов различных микросервисов. Это накладные расходы для клиента, что является плохим архитектурным подходом.
Второй случай -> Это хороший подход по сравнению с первым. Если у вас есть независимая база данных / таблицы (без прямого отношения), это будет хороший подход. Просто вам нужно сохранить ссылки для orderId / userId в соответствующих таблицах, чтобы получить эти сведения. Общее время вашего запроса будет сгруппировано, но ваш пользовательский модуль будет работать независимо от модулей заказа. При таком подходе вы добьетесь слабой связи.
Третий случай -> Если у вас нет разных баз данных для каждого микросервиса, это будет вашим лучшим подходом, поскольку он уменьшит количество обращений к базе данных, а также к другим микросервисам. Вы можете получить прямую информацию, реализовав методы обслуживания для каждой требуемой модели.
which case is most used?
Ответ Я не думаю, что кто-то использует первый подход как плохую практику. Если у вас разные базы данных для разных микросервисов, то ответом будет второй случай. Если у вас одна база данных, вы также можете перейти к третьему случаю. Но ваш код уровня сервиса будет дублироваться в разных микросервисах.
In case of microservice and web api application - each microservice contains only one or maybe two controllers?
Стандартного количества контроллеров в каждой микросервисе не существует. Это будет зависеть от размера микросервиса и обязанностей, выполняемых этим микросервисом.