Я планирую использовать шлюз API поверх моих микро-сервисов.Но есть некоторые архитектурные вопросы, на которые у меня нет четких ответов, поэтому я хотел бы узнать мнение сообщества.Также было бы здорово, если бы вы могли поделиться своими идеями о хороших и плохих практиках.Таким образом, чтобы облегчить чтение этого вопроса-поста, у меня есть два основных раздела: «вопросы» и «подробности»
Вопросы
Должен ли шлюз Api взять на себя ответственность за авторизацию и преобразование запроса?
Вопрос в основном в том, что такое шлюз: это просто мост между пользователями API и микро-сервисами.Или это модератор микро-сервисов?См. Раздел «Стратегии реализации шлюза» для получения дополнительной информации.
В случае использования Amazon API Gateway, является ли хорошей практикой выполнение преобразования и авторизации запросов с дополнительным уровнем лямбда-функций?
Если я решу пойти с Amazon API Gateway, и ответом на предыдущий вопрос будет «Шлюз должен выступать в качестве модератора микросервисов».Чем мне нужно будет обрабатывать преобразования запросов / ответов и авторизацию через Amazon lambdas, что будет означать, что у меня будет еще один уровень ниже шлюза.Таким образом, вопрос заключается в следующем: это хорошая практика, чтобы иметь такую архитектуру?
Детали
Технологии
- Spring Boot 2.0
- JWT
- Spring Cloud Gateway или Amazon Api Gateway (в зависимости от ответов)
Услуги
У нас естьследующие микроуслуги в нашей системе
ServiceA
Конечная точка GET / api / resources / {dataId} / admin-endpoint
заголовки- авторизация: токен на предъявителя
эта конечная точка доступна только пользователям с ролью ADMIN (В случае запроса от пользователя без этой роли 403 будет возвращено http-состояние с ответом).
Обратите внимание, что токен должен быть проверен AuthService перед обработкой запроса.А после обработки запроса (в случае отсутствия http-статуса) токен должен быть обновлен AuthService (ответ должен содержать обновленный токен)
Конечная точка GET / api / resources / {dataId} / user-конечная точка
заголовки - авторизация: токен на предъявителя
эта конечная точка доступна пользователям с любой ролью
AuthService
Конечная точка POST / api / auth / login
заголовки - авторизация: токен на предъявителя
body - {"username": String,«password»: String}
аутентифицирует пользователя: в случае успеха подписанный токен авторизации будет возвращен в качестве заголовка ответа (токен на предъявителя JWT).В случае сбоя аутентификации 401 будет возвращено http-состояние
Конечная точка POST / api / auth / logout
заголовки - авторизация: токен на предъявителя
делает недействительным токен авторизации (сохраняя токен в соответствующей таблице), так что пользователь не может получить доступ к защищенному API с данным токеном
Конечная точка GET / api / auth / validate
заголовки - авторизация: токен на предъявителя
проверяет данный токен (должен быть вызван перед обработкой запроса в ServiceA. См. Приложение-A для проверочных проверок
тело ответа - {"role":, "username": String}
Шлюз, реализующий стратегии
Шлюз отвечает только за маршрутизацию
При этомСтратегия ServiceA и AuthService зарегистрированы в качестве маршрутов в шлюзе, перед обработкой запроса никакое дополнительное преобразование запроса не выполняется.
ServiceA общается напрямую с AuthServer для авторизации иoken validation.
Плюсы
- Логика шлюза очень проста
- В качестве шлюза есть большой выбор рамок и инструментов.
Минусы
- ServiceA и AuthService тесно связаны
- Если мне понадобится добавить ServiceB, мне потребуется выполнить какую-то двойную работу для установления связи между ServiceB и ServiceA
- ОбработкаСбои в AuthService в основном будут выполняться ServiceA
Шлюз отвечает за авторизацию и преобразование запроса
С этой стратегией api-gateway будет обрабатывать проверку токена с помощью AuthServer перед передачей запроса в ServiceA,И он также будет обрабатывать обновление токена, когда ServiceA выдаст ответ без ошибок
Pros
- ServiceA полностью отделен от AuthService
- Добавлениедругой ServiceB будет намного проще
- Сбои AuthService будут обрабатываться шлюзом
Минусы
- Шлюз будет иметь больше обязанностейчем просто быть мостом для микро-сервисов
- Amazon Api Gateway, скорее всего, не будет хорошим выбором, так как обработка авторизации и преобразования с помощью Amazon lambda-s может быть очень болезненной (возможно, я ошибаюсь)
Приложение-A: Проверки проверки токена JWT
- Токен имеет действительный префикс канала-носителя: "bearer"
- Токен не просрочен (токен имеет атрибут createAt, который являетсяиспользуется для определения, является ли токен старше 10 минут)
- Пользователь существует: пользователь не был удален после создания токена (токен имеет атрибут субъекта, в котором хранится уникальный идентификатор пользователя)
- Пароль пользователя не менялся при жизни токена