Получение данных из микросервиса (API) и соединение их с основными данными приложения
В клиентском приложении мы переносим части монотонной системы на архитектуру микросервисов. Очень упрощенно это выглядит так:
— базовое приложение имеет собственную базу данных с продуктами
— микросервисы имеют собственные базы данных с различными объектами, которые могут быть связаны с продуктами.
Сценарий 1:
Мы хотим показать продукт «Apple» на странице, с соответствующими данными из микросервиса.
Это просто: достаточно взять «Apple» из базы данных основного приложения и получить дополнительные данные для этого продукта из микросервиса. Хорошо.
Сценарий 2:
Мы хотим показать список продуктов с различными условиями для базы данных основного приложения и другими условиями для базы данных микросервиса. Как это сделать?
Должен ли я получить — например — 1000 продуктов из базы данных (core-app) и позвонить в microservice для получения дополнительных данных для этих продуктов? Но как? Стоит ли отправлять один запрос с 1000 идентификаторами или 1000 вызовами API или получать данные из службы API по частям, например, 10 вызовов API для 100 элементов? Мне не нравится каждый из этих вариантов.
Сценарий 3:
У нас есть «Склад» микросервис.
Я хочу, чтобы список первых 100 продуктов был отсортирован по имени, по возрастанию, у которого на складе имеется флаг = true. Как это сделать? Если я получу 100 продуктов из базы данных core-app, а затем вызову API для проверки флага, то окончательный список продуктов может быть ниже 100.
Получение списка всех предметов, доступных на складе, является плохой идеей, потому что может быть миллионы предметов, поэтому время выполнения и размер ответа API будут неприемлемыми.
В общем, мне нужна идея, как объединить некоторые данные из одной БД и некоторые данные из другой БД и вернуть их в представление пользователя.
Приложение написано на PHP, но, возможно, некоторые ребята, имеющие опыт работы с J2EE, знают решения этих проблем?
РЕДАКТИРОВАТЬ: Я обнаружил, что: http://microservices.io/patterns. Я посмотрю на это ближе.
Решение
Первое, что приходит ко мне, это то, что в целом микросервис должен обрабатывать заданный ограниченный контекст / домен. Поэтому мне интересно, что это за «дополнительные» данные, которые вы хотите добавить к продуктам и не должны ли они также попадать под микросервис продуктов.
Если вы уверены, что это не так, это отдельные домены, то это вопрос вашего дизайна API. Если вы прогнозируете часто запрашивать другой микросервис с тысячами идентификаторов, создайте API, который может обрабатывать тысячи идентификаторов (или, предпочтительно, любой длины списка идентификаторов).
Что касается сценария 3 — если бы я получил такую задачу, я бы создал API, который обрабатывает сортировку и фильтрацию, так что все те операции, в которых базы данных хороши, будут обрабатываться базами данных.
В общем, моя идея заключается в том, что API должен определяться потребностями вашего бизнеса и не должен ограничивать вас в быстром предоставлении высококачественных решений. Так что, если простой CRUD API не работает (и редко), просто измените его.
Другие решения
Других решений пока нет …