Начало работы с архитектурой Microservices

Question

Я очень новичок в Microservices, и я хотел бы смоделировать что-то простое на бумаге: приложение, которое позволяет пользователям входить в систему и загружать фотографии (для примера).

Я полагаю, я должен был бы:

• Войти служба
• Пользователь службы
службы
• Фотографии

Может кто-нибудь помочь с описанием того, что эти API, будет выглядеть?

Войти Услуги:

• (POST) Вход пользователя = имя пользователя & PWD = пароль - Регистрирует пользователя в

User Service:

• (GET) Пользователь & user_id = 123 - Получает указанный пользователь
• (POST) Пользователь - Создает новый пользователю
• (POST) Пользователь & user_id = 123 & имя = John - Обновление существующего пользователя
• Как будет выглядеть удаление в этом примере

Конечно, фотографии будут следуйте подобным требованиям к Сервису пользователей.

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

Спасибо за любой проницательности

Answer 1

Для обеспечения Apis де-факто подход должен сделать что-то вроде этого: -

Authentication
Аутентификация пользователя обычно происходит один раз в сессии - где сессии обычно относится к периоду времени, когда пользователь автоматически выходит из системы, если клиент неактивен в течение определенного периода времени.

Например, если вы используете Enterprise Java, вы обычно настраиваете сервер приложений на время HttpSession в течение определенного периода бездействия. Вы должны аутентифицировать пользователя - обычно, сравнивая базовые учетные данные (имя пользователя/пароль) с каким-либо профилем, который вы им сохраняли после их регистрации (с помощью службы регистрации).В рамках аутентификации пользователя будет создана HttpSession, и ROLE пользователя будет сохранен и проверен для каждого запроса, чтобы проверить, действительно ли сеанс действителен. Если сеанс завершен, пользователь снова должен быть перенаправлен на службу проверки подлинности.

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

Подумайте об аутентификации как ОДИН РАЗ СЕССИИ.

Авторизация Для каждого запроса (предполагается, что сеанс остается в силе) вы бы проверить, что роль пользователя обладает необходимыми правами для выполнения действия запрошенного.

OAuth - пример системы авторизации) - обычно предназначен для аутентификации сторонних клиентов для доступа к одному из ваших ресурсов пользователя, но если вы посмотрите на OAuth 2, то он даст вам представление о том, основанный на подходе при аутентификации пользователя/клиента между запросами.

Думайте о разрешении как КАЖДЫЙ ЗАПРОС.