управление сеансами микросервисов

Question

Насколько я знаю, лучшие практики в архитектуре микросервисов - не использовать совместно используемые БД / кэши, поэтому у каждого микросервиса должна быть своя база данных и база данных / механизм кэширования. Но как насчет сессий?

Большинство людей, которых я нашел, предлагают использовать распределенное хранилище сеансов , и, насколько я понимаю, распределенное хранилище сеансов означает наличие общего хранилища для сеансов. Но вот вопрос номер один. Должны ли только шлюзы API проверять сеанс или каждый микросервис должен проверять сеанс? Другими словами, если веб-интерфейс отправляет какой-либо запрос, я должен проверять только сеанс в шлюзе API или в каждом из микросервисов, с которыми взаимодействует шлюз API?

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

Answer 1

Сеансы

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

Проверка токена / сеанса

Вам необходимо проверить сеанс на шлюзе, и это предпочтительный подход. Но это действительно зависит от вашего дизайна. Если у вас есть службы за шлюзом API и есть какой-либо доступ publi c, то, безусловно, токен должен быть проверен в каждом приложении / услуге. Если ваши услуги являются частными, вы можете проверить токен только на Api Gateway и отклонить неподтвержденные запросы.

Собственные облачные шлюзы (например, AWS Api Gatway) могут проверять токен без написания дополнительного кода, если вы используете известных провайдеров идентификации, таких как (auth0, Okta et c). Если требуются пользовательские утверждения, возможно, вам потребуется написать logi c в вашем приложении или использовать собственные библиотеки для получения пользовательских утверждений из токена. Я верю, что во всем этом сценарии вам не понадобятся дополнительные микросервисы для Auth, если вы не хотите написать свой собственный сервис для выпуска и проверки токенов, что, на мой взгляд, не очень хорошая идея.