Как правильно собирать данные с разных микросервисов?

Question

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

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

let url = "http://my-domain.com/api/v2/invoices"
let params = {userId:1}
request(url,params,(e,r)=>{
  const results = r // An array of 1000 invoices for the user 1
});

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

results.map((invoice)=>{
   invoice.items.map((itemId)=>{
      const url=`http://my-domain.com/api/v2/products/${itemId}`
      request(url,(e,r)=>{
       const product = r
       //Do something else.....
      });
   });
});

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

Как правильно получить информацию обо всех продуктах без необходимости делать это количество запросовчтобы избежать проблем с производительностью?.

Я нашел несколько обходных путей для таких сценариев, таких как:

1. Создайте конечную точку API, которая принимает список идентификаторов для созданияодин запрос.
2. Дублируйте информацию из службы Продукта в службе счетов и найдите способ их синхронизации.

В микрофонеАрхитектура roservices - это правильные способы решения таких проблем?Для меня они выглядят как простые обходные пути.

Правка № 1: На основе ответа Ремуса Русану.

Согласно рекомендации Ремуса, я решилчтобы выделить мои услуги и описать их немного лучше.

Как показано на рисунке выше, микросервисы теперь изолированы (в частности, биллинг-сервис) и теперь они являются владельцами данных.Используя эту структуру, я гарантирую, что Billing-service сможет работать, даже если есть асинхронные задания или даже если другие две службы не работают.

Если мне нужно создать новый счет, я могу позвонить другомудва микросервиса (Users, Inventory) синхронно, а затем обновите данные в таблицах «cache» (Users, Inventory) в моем биллинговом сервисе.

Можно ли предположить, что эти таблицы «cache» доступны только для чтения?Я предполагаю, что это так, поскольку только пользователь / службы инвентаризации должны иметь возможность изменять эту информацию, чтобы сохранить изоляцию и контроль над информацией.

Answer 1

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

Изолированные микроуслуги означают, что они владеют своими данными и могут работать независимо.Счет-фактура завершен в том виде, в каком он был возвращен службой «Счета»Он содержит названия продуктов, имя клиента, каждую информацию в счете.Все данные поступили из собственного хранилища.Отдельным микросервисом может быть «Инвентаризация», который управляет всеми запасами продукции, текущим запасом и т. Д. Он также будет иметь свои собственные данные в своем собственном хранилище.«Продукт» может существовать на обоих носителях, и когда-то между ними существовала логическая связь (при создании счета), но теперь связь разорвана.Микросервис «Инвентаризация» может изменять свои продукты (например, удалять один, добавлять новые SKU и т. Д.) Без влияния на существующие Счета (это не только требование изоляции микросервиса, но и основное требование учета).Я не буду вдаваться в подробности того, что является «идентичностью» продукта в реальной жизни.

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

Answer 2

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

Первое решение, которое вы представили, является менее устойчивым: если какой-либо из микросервисов Пользователей или Продуктов выйдет из строя, микросервис Счет-фактура также выйдет из строя.Это то, что вы хотите?С другой стороны, эта архитектура самая простая.Вариант этой архитектуры - позволить клиенту делать запросы на соединение;это приводит к болтливому разговору, но имеет то преимущество, что клиент может заменить отсутствующую информацию информацией по умолчанию, когда другие микросервисы не работают.

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