Почему сессии хуже токенов в микросервисной архитектуре?

Почему сессии не используются в микросервисной архитектуре? Я вижу две проблемы
1) Вместо самостоятельной верификации токена, микросервису нужно стучаться к auth-микросервису, что создает нагрузку.
Масштаб этой проблемы колеблется от одного проекта к другому. С одной стороны, нагрузка может быть не слишком большой. С другой стороны, уменьшая такую нагрузку теряется возможность быстро управлять авторизацией - все изменения в правах\ролях пользователя переносятся на срок жизни токена (или нет, если создавать ту же нагрузку на доп.проверки в бд)

2) Микросервисы часто раскиданы на разных доменах, а куки не поддерживаю кросс-доменные запросы.
Храним session-id там же, где и токены === проблема не является специфичной для сессий.
  • Вопрос задан
  • 792 просмотра
Решения вопроса 1
sergey-gornostaev
@sergey-gornostaev
Седой и строгий
С одной стороны, нагрузка может быть не слишком большой.

Всего лишь в два раза минимум - по одному дополнительному запросу верификации сессии на каждый запрос пользователя. К тому же, в какой-то момент времени "auth-микросервис" загнётся под нагрузкой и его надо будет как-то масштабировать. Если запустить дополнительные экземпляры с общей базой, то бутылочным горлышком станет база. Если использовать разные базы, то получите проблемы синхронизации.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
inoise
@inoise
Solution Architect, AWS Certified, Serverless
Причин миллион, но мне просто интересно как ты собираешься управляться с сессиями в stateless мире?) Правильный ответ - никак, они для stateful
Ответ написан
profesor08
@profesor08
Вот и ответ:
куки не поддерживаю кросс-доменные запросы
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы