Как вы работаете с общими понятиями в микросервисной архитектуре?

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

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

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

— anjunatl
источник

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

В вашем случае вы должны начать снаружи и подумать о том, какие операции вы хотите сделать доступными для вашего пользователя через API (если это бэкэнд-сервис) или какие операции должны быть доступны в графическом интерфейсе, если это веб-приложение. Обратите внимание, что часть GUI часто является обычным приложением со своими собственными контроллерами: операции могут вызываться через REST (как в AngularJS), но эти конечные точки предназначены только для использования приложения GUI и не являются микросервисами в общем смысле.

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

— Михал Космульский
источник

Это мне очень помогло. Я начал с написания пары сценариев использования пользовательского интерфейса, в которых использовался бы стек, и все в основном стало на свои места.

— anjunatl

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

— Рикардо Соуза

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

— Михал

@ MichałKosmulski Мне нужно начать обсуждение, но дизайн StackExchange их не устраивает :) Что мне не нравится в микросервисном подходе в этом конкретном примере, так это прямой запрос к базовой базе данных (где хранятся пользователи и изображения), который может быть намного более эффективным. Представьте, зависят ли эти вышестоящие сервисы от других вышестоящих сервисов и т. Д. Прямой запрос к хранилищу данных намного безопаснее. только мои 5 центов - больше ничего. Опять же, я бы очень хотел провести продуктивную дискуссию на эту тему, но StackExachange не подходит для этого (можете ли вы порекомендовать дискуссионные форумы по микросервисам?)

— ajukraine

@ajukraine Я думаю, что на stackexchange есть чаты, которые могут быть хорошим местом для дискуссий. Что касается производительности: 1. Микросервисы идут с затратами на производительность, и 2. Микросервисы хороши для одних ситуаций, но не для других. Что касается зависимостей: в микросервисных архотектурах вы часто делаете локальные копии данных и используете асинхронный обмен сообщениями, чтобы уменьшить количество зависимостей. Это реальное изменение архитектуры, а не просто автоматическое изменение каждого модуля приложения на отдельное приложение.

— Михал

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

Ну, служба профилей не должна работать с объектом пользователя. Он может знать только идентификатор пользователя, для которого его просят вернуть данные, не более. Таким образом, вам не потребуется взаимодействие между пользовательским сервисом и профильным сервисом.

Если это не отвечает на ваш вопрос, не могли бы вы уточнить его, описав точную ситуацию, с которой вы имеете дело?

— Владислав Раструсный
источник

Это и ответ Михала помогли мне понять это, но его предложение помогло мне наметить необходимые мне услуги. Я застрял в сознании необходимости представлять полный объект, а не просто ссылку на объект (объект пользователя против идентификатора пользователя). Высоко ценится, спасибо!

— 23

@anjunatl Добро пожаловать;)

— Владислав Раструсный