Паттерны микросервисной архитектуры часть 2| Microservices architecture patterns part 2
Vložit
- čas přidán 16. 06. 2024
- Telegram: t.me/digital_train
Boosty: boosty.to/digital_train
Рассмотрим основные паттерны микросервисной архитектуры из следующих областей:
➕ Тестирование (CDC + Service layer)
➕ UI composition
➕ Circuit breaker
➕ Немного Security & Cross-cutting concerns
Полезные ссылки:
docs.pact.io
micro-frontends.org
www.openidentityplatform.org/...
Описание:
0:00 Введение и Кратко обо мне
1:26 Структура интервью
5:38 Паттерны тестирования
12:10 Паттерны копмозиции UI
23:20 Circuit breaker
30:25 Cross-cutting concerns
44:05 Access token
50:15 Вопросы на собеседовани
58:00 Спонсоры
микросервисной архитектуры часть 2,архитектуры часть 2| Microservices,Паттерны микросервисной архитектуры,Паттерны микросервисной,архитектуры часть 2| Microservices architecture patterns part 2,Digital train | Alex Babin,микросервисы,программирование,что это такое,архитектуры часть 2| microservices,архитектура,паттерны микросервисной архитектуры,архитектура приложений,паттерны микросервисной,архитектуры часть 2| microservices architecture patterns part 2
Пили про аутентификацию, всегда актуально)
контент супер! Спасибо вам
Всё доходчиво) Возник вопрос по поводу JWT. Допустим есть API Gateway сервис и Security сервис, который после первоначальной проверки имя:пароль генерирует JWT, используя RSA шифрование и отдает его клиенту. Каким образом лучше всего осуществить проверку этого токена, не отправляя каждый запрос от клиента в Security, у которого (только!) есть доступ к RSA ключам? Сейчас на Gateway применяется фильтр, который отправляет запросы к другим микросервисам сначала в Security на верификацию JWT. Как-то криво по-моему(
Есть несколько подходов, если я правильно понял ваш случай - это случай когда для каждого микросервиса мы осуществляет запрос и проверку токена, такой подход отлично работает с точки зрения безопасности, но у него есть минусы и один из основных это проблема масштабирования (при большом количестве микросервисов и запросов рост нагрузки будет экспоненциальным). В таком случае чаще всего переходят на аутентификацию на edge (по перимитру), что сильно упрощает масштабирование, но снижает "строгость" проверок для каждого вызова внутри безопасной зоны
Подробно данных подход хорошо изложен в блоге Netflix (они как раз столкнулись с проблемой управления и масштабирования) - netflixtechblog.com/edge-authentication-and-token-agnostic-identity-propagation-514e47e0b602
Спасибо за видео. Очень интересное но как по мне уж слишком поверхностное. Автор подчеркивает важность демонстрации практического опыта на собеседовании но именно этого самого практического опыта использования этих паттернов автором в этом видео и не хватает. Надеюсь в будующих видео будет что-то основанное на реальных проектах. Хотя возможно для начинающих видео будет полезно чтобы не искать по гуглам все эти паттерны.