Как использовать Kong Ingress Controller со службами Spring Boot

С 2003 года я использую IntelliJ в качестве основного инструмента для разработки приложений и сервисов. Девятнадцать лет назад я был впечатлен как небольшим объемом оперативной памяти, необходимой для использования IDE, так и возможностями рефакторинга, включенными в версию 1.x.

Разработка на Java не требует от меня использования продукта IntelliJ IDEA. Другие разработчики в моем текущем проекте используют Eclipse или VS Code, но эти инструменты не требуются. Когда вы сможете писать свои компоненты, сервисы и приложения с помощью простого текстового редактора и сеанса терминала, вы получите один и тот же скомпилированный код Java.

Итак, почему я трачу деньги на IntelliJ каждый год? Потому что IntelliJ IDEA призвана упростить жизнь разработчикам, а это значит, что я стал намного продуктивнее. Например, щелчок правой кнопкой мыши по классу дает мне возможность переместить класс за считанные секунды. Когда IntelliJ находит возможность удалить повторяющийся код, он создает новый общий код и правильно обновляет местоположения, зависящие от централизованного метода. IntelliJ также является отличным источником проверки во время проверки кода.

Хотя этот пример может показаться немного элементарным, мне интересно, почему больше инженеров-программистов не используют аналогичный подход при создании своих сервисов.

Spring Boot Services и Kubernetes

Предположим, ваша специализированная команда стандартизировала использование Spring Boot для сервисов API. В результате напряженной работы вашей команды и детального проектирования ваши API считаются успешными среди потребителей. Ваша организация решает использовать Kubernetes для этих сервисов.

Для каждой службы Spring Boot, которую разрабатывает ваша команда, жизненный цикл высокого уровня выглядит следующим образом:

Инициализируется служба Spring Boot и добавляется пользовательский код. Этот сервис упакован в образ Docker , который в конечном итоге развертывается в Kubernetes.

Используя Kubernetes, мы получаем следующие преимущества:

• Коллекция контейнеров Docker на основе Spring Boot помещается в «Pod», чтобы действовать как единое приложение. Это позволяет сфокусировать каждую службу Spring Boot на заданном аспекте результирующего API.

• Один или несколько модулей могут быть сгруппированы для формирования результирующей службы API, которую можно настроить для обнаружения, наблюдения, горизонтального масштабирования и балансировки нагрузки.

• Последовательные обновления и канареечное развертывание используются для обеспечения стабильной работы пользователей.

Если вы заинтересованы в использовании Kubernetes с Spring Boot, перейдите по следующему URL-адресу:

[Spring Boot Kubernetes] (https://spring.io/guides/gs/spring-boot-kubernetes/)

Основываясь на успехе этих популярных API, давайте представим, что высшее руководство хотело бы монетизировать услуги, чтобы получать доход от самых активных потребителей. Уровень бесплатного пользования по-прежнему будет доступен, но будут введены ограничения на использование API.

Хотя команда могла бы реализовать некоторую пользовательскую логику на уровне Spring Boot, это не имеет смысла. Что нам нужно, так это централизованный способ справиться с этим новым требованием.

Kong Ingress Controller спешит на помощь

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

Если вы хотите узнать больше о Конге, ознакомьтесь с моей публикацией за май прошлого года:

[Как я перестал кодировать повторяющиеся сервисные компоненты с помощью Kong] (https://hackernoon.com/use-the-kong-gateway-to-stop-coding-repetitive-service-components-i24a34bp)

Для упомянутого выше варианта использования мы могли бы обрабатывать следующие компоненты на уровне шлюза API:

• Регистрация приложения (key-auth)

• Ограничение скорости

• Централизованное ведение журнала

Поскольку Kong Gateway имеет открытый исходный код и является «лидером» в магическом квадранте Gartner 2021 года для управления API полного жизненного цикла, Kong Gateway — это безопасный способ работы с этими общими компонентами. Знание того, что Kong также предоставляет входной контроллер для использования в Kubernetes, еще больше подтверждает правильность решения о продукте.

Вы можете найти все необходимое для начала работы с Kong Ingress Controller (KIC) на этой странице GitHub:

[Kong Ingress Controller для Kubernetes] (https://github.com/Kong/kubernetes-ingress-controller/)

На приведенном ниже рисунке показан желаемый дизайн для двух сервисов:

Запросы поступают в Kubernetes для службы API №1 или №2. Kong Ingress Controller перехватывает запросы и проверяет предоставленный ключ API. На основе этой информации контроллер определяет, превысил ли потребитель, делающий запрос, свой лимит запросов.

Если лимит скорости не превышен, запрос перенаправляется в соответствующий сервис. Однако, если ограничение скорости превышено, будет возвращен HTTP-ответ 429 (слишком много запросов). Во всех случаях модуль ведения журнала можно легко настроить для отслеживания всех входящих запросов, включая все метаданные, предоставляемые потребителем API.

Ценность этого дизайна

Когда мы делаем шаг назад и смотрим на полученную архитектуру и дизайн, мы быстро видим преимущества:

• Сервисы Spring Boot — это настоящие микросервисы, каждый из которых сосредоточен на одном аспекте API.

• Docker позволяет службам Spring Boot быть автономными и распространяться в любой момент жизненного цикла разработки.

• Kubernetes предоставляет возможность группировать эти целевые образы Docker в модули, которые действуют как единое приложение. Затем эти поды группируются для отображения в качестве сервисов API в нашем примере.

• Общие компоненты, такие как регистрация приложений, ограничение скорости и ведение журнала, находятся в одном централизованном месте внутри Kong Gateway.

• Контроллер Kong Ingress становится промежуточным уровнем между Kong Gateway и Kubernetes для использования всех общих компонентов.

В результате этой модели разработчикам функциональных групп, работающим над службами Spring Boot, нужно сосредоточиться только на работе, выполняемой их владельцем продукта, для улучшения или расширения службы. Этим разработчикам не нужно беспокоиться о ключах API, ограничении скорости или любом другом общем компоненте, управляемом где-то еще.

Инженерам DevOps, поддерживающим реализацию Kubernetes, также не нужно проектировать какие-либо нестандартные аспекты дизайна для работы с этими общими компонентами. Это связано с тем, что Kong Gateway создан для удовлетворения этих потребностей и хорошо работает через Kong Ingress Controller.

Заключение

С 2021 года я стараюсь жить в соответствии со следующим заявлением о миссии, которое, как мне кажется, применимо к любому ИТ-специалисту:

«Сосредоточьте свое время на предоставлении возможностей/функциональности, которые повышают ценность вашей интеллектуальной собственности. Используйте фреймворки, продукты и услуги для всего остального».

- Дж. Вестер

В начале этого поста я говорил о том, что предпочитаю IntelliJ IDEA текстовому редактору и сеансу терминала. На самом деле основная причина напрямую связана с моей личной миссией. Продукт IDEA позволяет мне сосредоточиться на нужных вещах; тем временем он выполняет повторяющиеся задачи, связанные с написанием исходного кода.

Точно так же Spring, Docker, Kubernetes и Kong предоставили решения и платформы для достижения той же цели. Каждый аспект, отмеченный выше, может быть прослежен до единственного источника истины для данного предмета. В результате в ландшафте приложений нет дублирования сервисов или функций.

Если вы обнаружите, что выполняете один и тот же процесс во второй раз, самое время подумать о рефакторинге вашего дизайна.

Если ваш уровень обслуживания соответствует модальному модулю, который я обсуждал здесь, и вы не используете Kong Gateway или Kong Ingress Controller, они обязательно должны быть в вашем списке продуктов для просмотра, когда вы будете готовы усовершенствовать дизайн своего сервиса.

Хорошего дня!