Некоторое время мы использовали Zuul в качестве шлюза API на сцене микросервисов, но недавно решили перейти на Kubernetes и выбрать более облачный способ.
После некоторого расследования и изучения документации Istio у нас есть несколько вопросов о выборе шлюза API в Kubernetes:
Я предполагаю, что Zuul предлагает множество функций в качестве пограничного сервиса для управления трафиком, маршрутизации и функций безопасности. Он должен объявить шлюз API основной точкой доступа внешних клиентов к микросервисам в соответствии с шаблоном архитектуры микросервисов Design. Однако Zuul должен каким-то образом обнаруживать базовые микросервисы, а для Kubernetes вам может потребоваться адаптировать Kubernetes Discovery Client, который определяет правила того, как API Gateway будет обнаруживать маршруты и передавать сетевой трафик во вложенные сервисы.
Согласно дизайну, Istio представляет собой архитектуру Service mesh и становится решением, ориентированным на Kubernetes. также с плавной интеграцией. Основная идея здесь заключается в использовании расширенной версии прокси-сервера Envoy путем внедрения sidecars в модули Kubernetes без необходимости изменения либо переписать существующее развертывание, либо использовать любые другие методы для обнаружения служб. Zuul API Gateway можно полностью заменить ресурсом Istio Gateway в качестве пограничного балансировщик нагрузки для входящих и исходящих соединений HTTP(S)/TCP. Istio содержит набор функций управления трафиком, которые можно включить в общую конфигурацию.
Вас могут заинтересовать другие фундаментальные концепции функциональных возможностей Istio, такие как:
модель авторизации;
политики аутентификации;
Istio телеметрия и политики Mixer.
Мы используем Kong Gateway. Это довольно простой шлюз на основе nginx. Простота установки и готовность к работе.
