Вопрос
Могу ли я заставить nginx вызывать другой микросервис внутри AKS k8s перед его маршрутизацией на запрошенный API? - цель состоит в том, чтобы ускорить запросы (меньше переходов) и упростить сборку и развертывание (меньше услуг).
Объяснение
В нашем развернутом кластере Azure AKS (Kubernetes) у нас есть дополнительный сервис, который я надеялся заменить на nginx. Это микросервис маршрутизации, который вызывает API идентификации перед выполнением маршрутизации.
Причина, по-моему, обычная, мы получаем какой-то токен аутентификации через некоторые заранее определенные заголовки (стандартные заголовки Authorization, а иногда и некоторые специальные, используемые для токенов отладки и олицетворения). ), мы вызываем из API маршрутизации в API идентификации с этими предопределенными заголовками и получаем взамен объект идентификации пользователя.
Затем мы передаем этот базовый объект идентификации пользователя в микросервисы, чтобы они имели быстрый и легкий доступ к пользователю и ролям.
Краткое объяснение будет:
- Nginx получает запрос, выгружает SSL и маршрутизирует к запрошенному сервису.
- Routing API берет заголовки авторизации и вызывает Identity API.
- Identity API проверяет информацию об авторизации и возвращает либо ошибку авторизации (при сбое аутентификации), либо сериализованный объект идентификации пользователя.
- API-интерфейс маршрутизатора либо тут же, в случае сбоя, либо возвращает его к запрошенному микросервису (путем взлома пути запроса), и присоединяет объект идентификации пользователя в качестве заголовка.
- Запрошенный микросервис может затем превратить этот объект идентификации пользователя в Принцип утверждений, например, в случае .NET Core.
Очевидно, что есть варианты объединения Router.API и UserIdentity.API, но лучше разделить разделение интересов. Я бы просто удалил Route.API, чтобы сохранить это разделение, но попросил nginx сделать эту работу за меня.