Я подумываю использовать шлюз api поверх своих микросервисов. Но есть некоторые архитектурные вопросы, на которые у меня нет четких ответов, поэтому я хотел бы узнать мнение сообщества. Также было бы здорово, если бы вы могли поделиться своими идеями о хороших и плохих практиках. Итак, чтобы этот вопрос-пост был легко читаем, у меня есть два основных раздела: вопросы и детали.
Вопросов
Должен ли шлюз Api взять на себя ответственность за авторизацию и преобразование запросов?
Вопрос в основном в том, что такое шлюз: это просто мост между пользователями api и микросервисами. Или это модератор микросервисов? Пожалуйста, смотрите раздел Стратегии реализации шлюза для получения дополнительной информации.
В случае использования Amazon API Gateway, является ли хорошей практикой преобразование и авторизация запросов с дополнительным уровнем лямбда-функций?
Если я выберу Amazon API Gateway и отвечу на предыдущий вопрос, Gateway должен действовать как модератор микросервисов. Затем мне нужно будет обрабатывать преобразования запросов / ответов и авторизацию с помощью лямбда-выражений Amazon, что будет означать, что у меня будет еще один уровень ниже шлюза. Итак, вопрос: является ли такая архитектура хорошей практикой?
Подробности
Технологии
- Весенняя загрузка 2.0
- JWT
- Облачный шлюз Spring или Amazon Api Gateway (в зависимости от ответов)
Услуги
В нашей системе есть следующие микросервисы
ServiceA
Конечная точка GET / api / resources / {dataId} / admin-endpoint
заголовки - авторизация: токен на предъявителя
эта конечная точка доступна только для пользователей с ролью ADMIN (в случае запроса от пользователя без этой роли статус HTTP 403 будет возвращен с ответом).
Обратите внимание, что токен должен быть проверен AuthService перед обработкой запроса. И после обработки запроса (в случае HTTP-статуса без ошибок) токен должен быть обновлен AuthService (ответ должен содержать обновленный токен)
Конечная точка GET / api / resources / {dataId} / user-endpoint
заголовки - авторизация: токен на предъявителя
эта конечная точка доступна пользователям с любой ролью
AuthService
Endpoint POST / api / auth / login
заголовки - авторизация: токен на предъявителя
body - {имя пользователя: строка, пароль: строка}
аутентифицирует пользователя: в случае успеха подписанный токен авторизации будет возвращен в качестве заголовка ответа (токен носителя JWT). В случае неудачной аутентификации будет возвращен статус 401 http.
Endpoint POST / api / auth / logout
заголовки - авторизация: токен на предъявителя
аннулирует токен авторизации (путем сохранения токена в соответствующей таблице), так что пользователь не может иметь доступ к защищенному API с данным токеном
Конечная точка GET / api / auth / validate
заголовки - авторизация: токен на предъявителя
проверяет данный токен (должен быть вызван перед обработкой запроса в ServiceA. См. Приложение-A для проверок проверки
тело ответа - {роль:, имя пользователя: String}
Стратегии реализации шлюза
Шлюз отвечает только за маршрутизацию
С этой стратегией ServiceA и AuthService регистрируются как маршруты в шлюзе, дополнительное преобразование запроса не выполняется перед обработкой запроса.
ServiceA напрямую обращается к AuthServer для авторизации и проверки токена.
Плюсы
- Логика шлюза очень проста
- В качестве шлюза можно выбрать множество фреймворков и инструментов.
Минусы
- ServiceA и AuthService тесно связаны
- Если мне нужно добавить ServiceB, мне нужно будет выполнить какую-то двойную работу для установления связи между ServiceB и ServiceA.
- Обработка сбоев в AuthService в основном будет выполняться ServiceA.
Шлюз отвечает за авторизацию и преобразование запроса
С этой стратегией api-gateway будет обрабатывать проверку токена с помощью AuthServer перед передачей запроса в ServiceA. И он также будет обрабатывать обновление токена, когда ServiceA даст ответ без ошибки.
Плюсы
- ServiceA полностью отделен от AuthService
- Добавить еще один ServiceB будет намного проще
- Сбои AuthService будут обрабатываться шлюзом
Минусы
- Шлюз будет иметь больше обязанностей, чем просто мост для микросервисов.
- Amazon Api Gateway, скорее всего, не будет хорошим выбором, поскольку обработка авторизации и преобразования с помощью лямбда-выражений Amazon может быть очень болезненной (возможно, я ошибаюсь)
Приложение-A: проверка токена JWT
- Токен имеет действующий префикс предъявителя: предъявитель
- Срок действия токена не истек (у токена есть атрибут createdAt, который используется для определения того, старше ли токен 10 минут)
- Пользователь существует: пользователь не был удален после создания токена (токен имеет атрибут subject, который сохраняет уникальный идентификатор пользователя)
- Пароль пользователя не менялся за время жизни токена
