Как объединить / объединить ответы от нескольких микросервисов RESTful?

Question

Допустим, есть два (или более) микросервиса RESTful, обслуживающих JSON.Служба (A) хранит информацию о пользователе (имя, логин, пароль и т. Д.), А служба (B) хранит сообщения от этого пользователя (например, sender_id, subject, body, rcpt_ids).

Служба (A) включена/profile/{user_id} может ответить:

{id: 1, name:'Bob'}

{id: 2, name:'Alice'}

{id: 3, name:'Sue'}

и т. Д.

Сервис(B) отвечая на /user/{user_id}/messages, возвращает список сообщений, предназначенных для этого {user_id}, например:

{id: 1, subj:'Hey', body:'Lorem ipsum', sender_id: 2, rcpt_ids: [1,3]},

{id: 2, subj:'Test', body:'blah blah', sender_id: 3, rcpt_ids: [1]}

---

Какобрабатывает ли клиентское приложение, использующее эти сервисы, объединение списка сообщений так, чтобы вместо идентификаторов отправителя / rcpt отображались имена?

Метод 1 : извлечение списка сообщений, затем запуск извлечения профиляинформация для каждого идентификатора, указанного в sender_id и rcpt_ids?Это может потребовать сотен запросов и может занять некоторое время.Скорее наивно и неэффективно и может не масштабироваться со сложными приложениями ???

Метод 2 : Извлечь список сообщений, извлечь все идентификаторы пользователей и сделать групповой запрос для всех соответствующих пользователей отдельно.Это предполагает, что такая конечная точка службы существует.Все еще существует задержка между получением списка сообщений, извлечением идентификаторов пользователей, отправкой запроса на массовую информацию о пользователе, а затем ожиданием ответа на массовую информацию о пользователе.

В идеале я хочу разослать полный набор ответов за один раз (сообщения и информация о пользователе).Мои исследования привели меня к объединению ответов на уровне сервиса ... aka Метод 3 : техника API Gateway.

Но как это вообще реализовать?

Я могу получить список сообщений, извлечь идентификаторы пользователей, сделать закулисный вызов и получить данные пользователей, объединить наборы результатов, а затем обработать этот финальный файл.результат вверх ... Это нормально работает с двумя службами за кулисами ... Но что, если список сообщений зависит от большего количества служб ... Что делать, если мне нужно запросить несколько служб за кулисами, дальнейший анализ ответов этих, запрос большеуслуги, основанные на вторичных (третичных?) результатах, а затем, наконец, объединяются ... где останавливается это безумие?Как это влияет на время отклика?

И теперь я эффективно создал еще одного "клиента", который объединяет все ответы микросервиса в один мега-ответ ... который ничем не отличается от Метод 1 выше ... кроме как на уровне сервера.

Так ли это в "реальном мире"?Есть идеи?Существуют ли какие-либо проекты с открытым исходным кодом, построенные на такой архитектуре шлюза API, которые я мог бы изучить?

Answer 1

В идеале я хочу за один раз раздать полный набор ответов (сообщения и информация о пользователе).

Проблема, которую вы описали, заключается в том, что Facebook осознал несколько лет назад, когда онирешил заняться этим путем создания спецификации с открытым исходным кодом под названием GraphQL .

Но как вообще реализовать это?

Он уже реализован на различных популярных языках программирования, и, возможно, вы можете попробовать его на выбранном вами языке программирования..

Answer 2

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

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

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

https://enterprisecraftsmanship.com/2017/07/05/how-to-request-information-from-multiple-microservices/

Answer 3

Возможно, вы захотите выполнить стратегии агрегации ответов на вашем API-шлюзе.Я написал статью о том, как это сделать на ASP.net Core и Ocelot, но для других технологий API-шлюзов должен быть аналог:

https://www.pogsdotnet.com/2018/09/api-gateway-response-aggregation-with.html