Как и какой инструмент следует использовать для создания API-шлюза для полиглота Microservice Platform?

Question

В случае с микросервисной архитектурой существует множество сервисов, построенных на разных стеках и взаимодействующих друг с другом, а также с клиентом через REST.

Итак, что я прошу, сделать этот шлюз единой точкой входа от клиента или потребителя e.g api.domain.com, которая перенаправит запрос в соответствующую службу на основе конечной точки, как мы знаем о назначении API.-gateway.

Ну, это возможно с помощью балансировщика нагрузки, например nginx-plus или HAProxy, просто балансируя нагрузку и передавая прокси.Но мои ожидания (mostly about authentication-authorization based) ниже:

• Потребитель будет аутентифицироваться с учетными данными, сервер вернет обратно маленький access_token (minimal e.g user_id as payload), который будет сохранен в клиентском приложении.В дальнейшем каждый запрос клиента будет отправлять этот токен как авторизацию, как это делает аутентификация на основе JWT или токена.
• Перед передачей запроса другому сервису Gateway-service декодирует этот маленький auth_token и создает другой токен авторизации (let's say Big Token) сассоциированные пользователи - вся информация (запрос от полезной нагрузки, декодированной малым токеном), которая будет передаваться в качестве Авторизации фактическому сервису и внутреннему сервису для вызова сервиса, из которого будет обслуживаться контент.будет некоторое время сохраняться в redis, чтобы уменьшить вызов API для получения информации о пользователе каждый раз.
• Запрос кэширования и балансировки нагрузки.

Я не уверен, что это возможнодостичь с помощью nginx-plus или HAproxy, вероятно, НЕТ! , потому что там у нас мало запросов к базе данных, вызовы API и кеширование в Redis и т. д. Что невозможно с помощью nginx или HAProxy или чего-либо подобного.

Я нашел две службы для Node.js/Express.js для передачи прокси Node-HTTP-Proxy and Express-Gateway , который предназначен только для api-сервисов expressjs, но здесь я использую фреймворк или языки polyglot.

Примечание: здесь сервисы построены с использованием Python flask, Django и ExpressJS, некоторые из них размещены на виртуальной машине Unix, где используется nginx в качестве балансировщика нагрузки, и немногие из них размещены в службе приложений Azure, где они используют IIS какБалансировщик нагрузки.

Спасибо за чтение и понимание, было бы замечательно, если вы все равно можете что-то предложить или порекомендовать.

Answer 1

Я действительно рекомендую Node-HTTP-Proxy .

Вы можете использовать сервер узлов для api.domain.com, который может использовать Node-HTTP-Proxy ,Он может быть использован для потребления микро-услуг, например.serviceone.com и servicetwo.com.Не имеет значения, что вы использовали для создания этих микросервисов (например, python flask, Django и ExpressJS), если вы выставили их как REST / SOAP api.

Скажем, у вас есть некоторые конечные точки, такие как serviceone.com/rone и servicetwo.com/rtwo, Вы можете сделать запрос на api.domain.com/rone или api.domain.com/rtwo, где ваш пользовательский прокси-сервер будет использовать Node-HTTP-Proxy и отправить запрос на serviceone.com/rone или servicetwo.com/rtwo.Вы можете прочитать заголовки из запроса, что-то с ним сделать и изменить заголовки перед отправкой запроса в микро-сервисы.Что бы решить вашу проблему с аутентификацией.Вы можете использовать Redis и кеширование здесь.

Хорошо сработало для меня.Надеюсь, это поможет.

Answer 2

Я бы порекомендовал Kong для случаев использования, которые вы упомянули:

1. Для конкретного способа аутентификации, который вы упомянули, вам нужно будет написать плагиниспользуя Lua.В Kong встроена поддержка многих аутентификаций, но ваши требования немного отличаются.

2. Kong кэширует все свои данные, включая потребителей в оперативной памяти.Таким образом, вам не нужно реализовывать другое решение на основе Redis.Если у вас есть новый пользователь, вам нужно будет добавить этого пользователя в качестве потребителя в Kong, используя его API администратора.

3. Kong поддерживает балансировку нагрузки.И поскольку он построен на основе Nginx, вы также можете настроить ядро ​​Nginx, если вам нужно.

4. Для кэширования запросов на уровне шлюза у Kong есть плагин для корпоративной версии.Также есть несколько плагинов, созданных сообществом с открытым исходным кодом.

Что касается пользовательской аутентификации, вам следует подумать дважды, зачем она нужна на двух уровнях.На уровне шлюза вы можете аутентифицировать и использовать ACL, базовые сервисы могут доверять предстоящим запросам.Возможно, вам потребуется реализовать промежуточное программное обеспечение уровня обслуживания для идентификации пользователя, через которого проходит Kong, для авторизации на уровне ресурсов.

Одно предупреждение : При работе с Kong я почувствовал необходимостьнадлежащей тщательной документации.

Answer 3

Я бы порекомендовал вам проверить Ambasador - https://www.getambassador.io - похоже, он будет соответствовать вашим потребностям.Другой надежный выбор, который пользуется большой поддержкой и большим сообществом, это Конг - https://konghq.com. Другие варианты: Nginx , Loopback и Тык .