Связь между микросервисами - запрос данных

Question

Я имею дело со связью между микросервисами.

Например ( пример, только для иллюстрации ):

• Микросервис A -Пользователи магазина (getUser и т. Д.)
• Микросервис B - Хранение заказов (createOrder и т. Д.)

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

Клиент -> Микросервис B (createOrder для userId 5) -> Микросервис A (getUser с идентификатором 5)

Микросервис Bсоздаст заказ с деталями (адресом) от Микросервиса пользователя.

ПРОБЛЕМА ДЛЯ РЕШЕНИЯ: Как эффективно справляться с обменом данными между микросервисом A и микросервисом B, так как мы должны ждать, пока не придет ответназад?

ОПЦИИ:

• Использовать RestAPI,
• Использовать AMQP, как RabbitMQ, и решать эту проблему с помощью RPC.(https://www.rabbitmq.com/tutorials/tutorial-six-dotnet.html)

Не знаю , что будет лучше для производительности . Быстрее ли вызов через RabbitMQ или RestAPI? Какое решение лучше всего подходит длямикросервисная архитектура ?

Answer 1

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

Вариант 1 Используйте API отдыха:

Когда вам нужна синхронная связь.Например, ваш случай.Этот вариант подходит.

Вариант 2 Используйте AMQP:

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

Я настоятельно рекомендую взглянуть на http://microservices.io/patterns/index.html

Answer 2

Все зависит от поведения вашего сервиса в выборе между API REST и дизайном на основе событий. Или и то, и другое. .

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

В идеале для протокола межпроцессного взаимодействия лучше использовать обмен сообщениями, а для клиентского сервиса лучше всего подходят API REST.Проверьте стиль связи в microservices.io

Архитектура на основе REST

• Преимущество

  1. Запрос / Ответ прост и лучше всего подходит, когда вам нужны синхронные среды.

  2. Упрощенная система, так как промежуточного брокера нет

  3. Способствует оркестровке, т. Е. Служба может предпринимать действия на основании ответа другой службы.

• недостаток

  1. Службам необходимо обнаруживать местоположенияэкземпляров сервисов.

  2. Отображение один к одному между сервисами.

  3. Используется оставшийся HTTP, который является универсальным протоколом, построенным поверх TCP / IPчто добавляет огромные накладные расходы при использовании его для передачи сообщений.

Архитектура, управляемая событиями

• Advantage

  1. Управляемые событиями архитектуры привлекательны для разработчиков API, посколькуОни отлично работают в асинхронных средах.

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

  3. Улучшенная доступность, поскольку брокер сообщений буферизует сообщения до тех пор, пока потребитель не сможет их обработать.

• Недостаток

  1. Дополнительная сложность брокера сообщений, которая должна быть высокой доступности
  2. Отладка запроса события не так проста.

Answer 3

Лично я не фанат использования брокера сообщений для RPC.Это добавляет ненужные сложности и накладные расходы.

Как вы размещаете своего долгоживущего потребителя RabbitMQ в своем веб-сервисе Users?Если вы сделаете это статическим синглтоном, как вы будете работать с масштабированием и параллелизмом в веб-сервисе?Или вы делаете это автономным процессом демона?Теперь у вас есть два пользовательских приложения вместо одного.Что произойдет, если ваш потребитель Users замедлится, к тому времени, когда он получит сообщение-запрос, контекст службы заказов мог истечь и отправил другое сообщение или отказался.

Для RPC я бы предложил простой HTTP.

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

В вашем случае вашему приложению Users не нужно ничего знать о заказах, но ваше приложение Orders требуетзнать некоторые детали о ваших пользователях.Таким образом, каждый раз, когда пользователь добавляется, изменяется, удаляется и т. Д., Служба «Пользователи» генерирует событие (UserCreated, UserModified, UserRemoved).Служба Orders может подписаться на эти события и хранить только те данные, которые ей необходимы, например, адрес пользователя.

Преимущество заключается в том, что во время запроса ваша служба Orders имеет одну менее синхронную зависимость от другой службы.Тестировать сервис проще, поскольку у вас меньше зависимостей от времени запроса.Однако есть и недостатки, такие как некоторая задержка между изменениями записей пользователей, которые происходят и принимаются приложением Orders.Что следует учесть.

ОБНОВЛЕНИЕ Если вы используете RabbitMQ для RPC, не забудьте использовать функцию TTL для сообщений.Если время ожидания клиента истекло, установите срок действия сообщения на этот период.Это поможет избежать бесполезной работы со стороны потребителя и избежать резервного копирования очереди под нагрузкой.Одна из проблем, связанных с RPC через посредник сообщений, заключается в том, что, как только очередь заполняется, она может добавить большие задержки, для восстановления которых требуется некоторое время.Установка истечения срока действия вашего сообщения на тайм-аут клиента помогает избежать этого.

Относительно RabbitMQ для RPC.Обычно мы используем брокер сообщений для разделения и долговечности.Поскольку RPC является синхронной связью, то есть мы ждем ответа, тогда долговечность не рассматривается.Это оставляет нас отделенными.Вопрос в том, что развязка покупает вам что-нибудь помимо развязки, которую вы можете делать с HTTP через шлюз или имена сервисов Docker?