Comments 12
Если микросервисы внутри защищенного периметра, зачем их загонять в https для связи между собой?
Тот же вопрос и про jwt.
Как по мне, jwt самая переоцененная вещь. Если мы хотим меньше делать запросов к бд, то возникают проблемы с принудительной инвалидацией токенов. Или как в данном случае общение происходит в доверенной сети и непонятно для чего jwt в принципе пихать...
Вот даже откопал:
https://habr.com/ru/articles/502702/comments/#comment_21636220
Согласен. Когда я работал в старой компании, там авторизация была на jwt токенах. Мне дали задачу реализовать отслеживание сессий и возможность отключить их. Сначала думал сделать на редисе список токенов, которые отозвали, и спрашивать постоянно их. А потом понял, что это все какая-то херня. В итоге полностью всю авторизацию переписал на cookie + session + seans. Хотя у меня до сих пор кит вопрос по поводу масштабирования такой системы. В плане, я теперь ограничен одним сервером, или как?
P.S. самый прикол в том, что когда я спрашивал старых сотрудников, а зачем вам jwt, мне все дружно отвечали "ну хз, микросервисы же вроде"
Сначала был HTTP без состояния. Потом в заголовках стали передавать указатель на состояние - куки. Для монолита достаточно, но в распределенных архитектурах резольвинг указателя на состояние стал проблемой. Ее решали двумя способами - общим для всех сервисов хранилищем сессий, или шифрованием сессии и передаче ее в заголовках во всех запросах. Второй вариант каноничен для микросервисной архитектуры и отлично масштабируем, но выбор за архитектором.
Тут скорее вопрос о том, в каких конкретных случаях использовать jwt выгодно. Т.к. в подавляющем большинстве случаев в jwt просто хранится id текущего пользователя (и ещё какие-то идшники), что не решает проблему с запросами к бд.
Я нашел только один случай, когда в jwt есть смысл - кэширование не секретных данных, чтобы разгрузить бд. Но это не нужно, либо хранится только id в 99%.
Как по мне, указанный вами пример с монолитом/распределенной системой не является аргументом за jwt, т.к. описанный случай решается гейтвеем.
Да потому что токен должен быть короткоживущим. ТТЛ токена - 2 минуты, потом на рефреш. Тогда и не будет проблем. А по-хорошему вообще засунуть все сервисы за гейтвей - он будет проверять токен перед всеми сервисами, блокировать запрос если токен в блеклисте, и обновлять его если срок жизни подходит к концу, и возвращать его в респонзе сервера в хедере
Прежде чем жаловаться что «технология X» такая ужасная, убедитесь что вы правильно ею пользуетесь
А по-хорошему вообще засунуть все сервисы за гейтвей
Ну и зачем тогда jwt? Чтобы лишний раз парсить и валидировать?
блокировать запрос если токен в блеклисте
А чёрное где хранить? А нельзя ли было там просто хранить строковую сессию?
ТТЛ токена - 2 минут
https://habr.com/ru/articles/502702/comments/#comment_21636220
Прежде чем жаловаться что «технология X» такая ужасная, убедитесь что вы правильно ею пользуетесь
Кто жалуется на технологию? Я написал, что она переоценена, разве это не правда?
Незачем. А для безопасности, если приспичило в zero trust, нужен mtls - меш или сайдкар прокси.
Брокер сообщений обязателен для микросервисной архитектуры. Большинство событий имеют асинхронную природу.
Ничего не сказано про API Gateway и безопасность кластера.
Не раскрыто Observability. Сейчас переходят на OpenTelemetry.
Есть более чем два протокола для коммуникации. Из текстовых, по моему, незаслуженно обходят Json-RPC, который лучше подходит для межсервисных связей чем REST.
А при чем тут nodejs и nestjs? В тексте они упоминаются один раз. Как будто их можно заменить на любой сервис написанный на "язык + фреймворк выберите сами".
Также кажется указывать конкретные технологии при проектировании не очень хорошая идея. Ну или надо уточнять почему нам больше подходит MongoDb для поиска, потому что в зависимости от функционала, архитектурных решений можно вести эффективный поиск в реляционной базе или, вовсе, в графовой.
Как то ниочем. Побили проект на предметные области. Ну ок.
Безопасность: зачем https внутри защищенной среды? Зачем взаимная аутентификация сервисов? Ничего не сказано ни о шифровании данных на дисках, о хранении/ротации сертификатов. Не, может оно так и над ов вашем случае, но почему так?
Выбор баз - почему именно такой, какие ожидаются обьемы данных?
Причем тут вообще node/nest?
И еще миллион открытых вопросов.
К статье очень много вопросов, если мы и так тащим в проект PG/MySql то зачем нам mongodb? Решать проблемы с схемой? Между сервисами не используем grpc или другой протокол с поддержкой схемы потому что выбрали js/ts? И тд и тп
почему это так похоже на вывод нейронки....
Проектирование микросервисной архитектуры в среде NodeJS/NestJS