Мой вопрос дня касается комбинаторных операций при создании микросервисов.
Давайте воспользуемся вымышленным сценарием: я хочу построить информационную панель. Панель инструментов состоит из группы людей и их информации (история, обзоры, покупки, последние поисковые продукты).
Читая spring-cloud и spring-reactor, я хотел бы иметь неблокирующее решение, вызывающее несколько микросервисов: пользовательскую службу, службу проверки, службу поисковой системы, ....
Моей первой догадкой было сделать что-то вроде
- загрузить пользователей,
- для каждого загрузите свои обзоры, затем
- загрузите его историю тогда
- объединить все данные
В псевдокоде что-то вроде loadUsers().flatmap(u -> loadReviews(u))....reduce(). Как видите, это действительно приблизительно.
При загрузке 1 пользователя мы можем оценить, что нам нужно еще 4 http-вызова. Для 100 пользователей, 400 дополнительных вызовов и т. д. Большой O не кажется линейным.
В худшем случае, когда микросервис также делегирует загрузку данных из микросервисов XYZ, мы получаем: для 1 пользователя -> N вызовов, включая 1 обзорный вызов -> 1 вызов XYZ. Извините, я не рассчитал Big-O (квадратичное?).
Чтобы избежать этого, мы, возможно, можем загрузить всех пользователей, извлечь их идентификаторы, вызвать микросервисы поиска с набором идентификаторов. Каждый микросервис может загружать все данные сразу (возможно, список отзывов, сопоставленных с идентификатором), и исходный вызов объединит все эти списки. (своего рода функция почтового индекса)
Резюме: я только что прочитал этот вопрос о составе Observables. Мой вопрос можно резюмировать следующим образом: «Используете ли вы ту же стратегию, когда у вас нет уникального пользователя в начале цепочки, а есть сотни пользователей?» (производительность может быть проблемой, нет?)
