Аутентификация и авторизация в проекте с микросервисной архитектурой: стратегии, практический пример

Рет қаралды 14,641

Spectr — команда разработки цифровых сервисов

Күн бұрын

Пікірлер: 22

@indigoram89 9 ай бұрын

монолит нормальная тема, если правильно готовить

@denisov1985 2 ай бұрын

Мерж конфликты только ядерные выходят когда большая команда а так да нормальная. И архитектурный надзор еще превращаеться в кошмар.

@АнарМусаев-б1л 2 жыл бұрын

Хорошее видео, очень помогло! :)

@povauto3298 7 ай бұрын

Что-то не понятное... Почему сравнивается вообще SPA, Монолит и Микросервисы? Как сюда попал SPA? SPA - это про реализацию фронта через псевдо-одностраничку. Микросервисы и Монолит - это про всё же бэкенд в первую очередь. Ну то есть можно сделать SPA в виде монолита, а можно за SPA скрыть микросервисы, можно SPA + SOA/SBA. Такое ощущение что когда человек готовился, он перепутал SPA и SOA, а потом его не смутило, что это вообще вещи разных плоскостей и он подготовился как смог) И с чего вдруг SPA - разделение на фронтенд и бэкенд?) В чем изоляция? Можно сделать SPA одним фуллстеком, который всё сделает в одной репе..

@molotok1726 Жыл бұрын

Докладчик говорит о том что в монолите все в куче: и бизнес-логика и работа с бд.... по-моему дело не в монолите как архитектуре а в криворукости разработчиков которые не владеют паттернами проектирования. Монолит можно разбить на слабосвязные модули, каждый из которых будет отвечать за одну определенную задачу. Также не понял при чем тут jquery? это просто фреймворк, один из многих, когда он был актуален его можно было грамотно использовать...

@rukurokami 6 ай бұрын

Это уже будет не монолит а модульная архитектура.

@molotok1726 6 ай бұрын

@@rukurokami вы путаете архитектуру приложения (монолит/микросервисы) с архитектурой (принципом) написания кода. Монолит может быть построен с использованием модульного принципа точно также как и микросервисы.

@rukurokami 6 ай бұрын

@@molotok1726 да, вы правы, путаю.

@alex-web7553 4 ай бұрын

отчасти поможет, но это все равно не решит многие проблемы, например, масштабирование. Да и бесконечно создавать все новые и новые модули приведет к оверинжирингу

@BrickOil-dh8ri 2 ай бұрын

Не смог посмотреть пример, на гитлабе нет

@indigoram89 9 ай бұрын

php, laravel 🔥

@rubyxanax4239 Жыл бұрын

Слабый доклад, докладчик видит в способе авторизации через зашивания ролей в пейлоуд jwt и проверку этих ролей уже на самих сервисах какую то панацею, но тут есть один не очень приятный момент. Если наши сервисы используют различные стеки технологий (вплоть до языков), то тогда эту логику проверки ролей нужно будет писать под каждый язык, что на мой взгляд в определенных ситуциях может быть оверинжинирингом. Предложенный способ хорош, если сервисы используют общий стек технологий и мы можем просто как говорится в *** не дуя вынести общую логику проверки пермишенов в отдельную либу и переиспользовать ее где надо. Если же стеки сервисов сильно отличаются, я не вижу проблемы в дополнительном запросе на авторизацию в сервис auth - да, летентность увеличится, но зато нам не придется плодить повторяющуюся логику в каждом сервисе, + у нас появится полноценное использование Single Responsibility и Single Source Of Truth.

@anatoly-k Жыл бұрын

этим грешит наверное вся заказная разработка

@Tiber-Lex Жыл бұрын

Скажите пожалуйста, когда вы говорите про дополнительный запрос к auth, вы про вот эту схему говорите - 27:40 ? Я только начинаю изучать что-то про микросервисы и не до конца понимаю, как это работает, особенно в практическом плане. Верно ли я понимаю эту схему: 1) юзер запрашивает какой-то урл, приложив токен авторизации 2) API Getway как-то определяет, что этот урл требует авторизации и посылает запрос в auth сервис, передавая туда токен 3) Auth сервис по своей базе данных проверяет, что такой токен есть и он живой, отдает положительный ответ (т.е. в auth сервисе есть какая-то таблица с токенами) 4) API Getway получив положительный ответ, еще раз как-то отправляет запрос, но теперь уже на требуемый сервис 5) Требуемый сервис, получив запрос, извлекает из него токен и делает запрос на Auth, с целью убедится, что юзер, владеющий этим токеном, имеет право пользоваться этим сервисом 6) Auth сервис по токену ищет юзера в своей базе данных, а затем проверяет его права (т.е. в auth сервисе так же есть какая-то таблица с правами каждого юзера) и по результатам проверки выдает ответ 7) Конечный сервис, на основе ответа от запроса к Auth сервису выполняет или не выполняет запрошенную операцию.

@raerayan 5 ай бұрын

Сделай лучше доклад, послушаем тебя. В твоем случае, доп запрос это минус, для каждого проекта нужно выбрать наиболее подходящую архитектуру, выделить преимущества и минимизировать недостатки. Он просто рассказал про архитектуру которая работает в его случае наилучшим образом. А вообще я не вижу существенного минуса реализации авторизации на каждом микросервисе даже при том, что каждый микросервис будет написан на разных языках или технологиях. Логика скорее не будет повторяться, а наоборот инкапсулироваться в каждый микросервис (см. Bounded Context) и команда сама решает какую логику описывать для доступа к тем или иным данным этого микросервиса так как у каждого сервиса она скорее будет своя чем общая для всех, а в твоем случае ты перегрузишь gateway или auth сервис логикой присущей для каждого отдельного сервиса и более того добавишь отдельный запрос. В твоем случе кто будет описывать логику авторизации в gateway или auth? Туда будет лазить каждая команда и писать что-то свое для своего сервиса?

@rubyxanax4239 5 ай бұрын

@@raerayan Привет! Спасибо за ответ. С момента написания моего комментария прошло больше года, я существенно переосмыслил свой подход. Я согласен, что любая архитектура это свод каких-то компромиссов, которые должны минимизировать проблемы сопровождаемости кода при масштабировании кодовой базы. Я согласен, что докладчик описал решение их собственной проблемы, исходя из их собственного контекста. Также я согласен в важности соблюдение границ ограниченного контекста и согласованности единого языка внутри него. Перенос логики авторизации всех ограниченных контекстов в одно место приведет к разрушению свойств самого ограниченного контекста: 1) Границ владения. Теперь ограниченном контекстом владеет не только команда разработки, но и инфраструктурная команда, отвечающая за общий сервис авторизации. Это потенциально приводит к разрушению доменной модели, что ведет к ухудшению сопровождаемости кода, что ведет к к увеличению TTM, что ведет к потере конкурентных преимуществ, что ведет к гибели проекта. 2) Физические границы. Ограниченный контекст теряет свои физические границы в виде одного независимого разворачиваемого сервиса. Это уже ведет к ухудшению свойств развертываемости и тестируемости. Поэтому сейчас можно сказать что тут должен быть апдейт под моим изначальным комментом. Если кратко - аутентификация в общем инфраструктурном сервисе, авторизация внутри каждого контекста с учетом всех инвариантов домена.

@raerayan 5 ай бұрын

@@rubyxanax4239 Привет, круто что можешь признавать ошибки и переосмысливать! 👍