Kong – это распределенный API-шлюз с облачной архитектурой с открытым кодом от Mashape. Его производительность и масштабируемость превосходны среди аналогичных компонентов. Kong официально предоставляет множество подключаемых модулей, которые доступны напрямую. Кроме того, Kong также может расширять существующие функции с помощью подключаемых модулей.
Основное содержание этой статьи:
- Что такое собственный облачный шлюз?
- Представляем Конга
- Базовая архитектура Конга
- Создание сервисного шлюза с помощью Kong
- Несколько распространенных приложений-плагинов
- Практика с пользовательскими плагинами
Статья длинная, вторая половина содержания будет представлена в следующей статье, так что следите за обновлениями.
Что такое собственный облачный шлюз
Что такое облако
Название этой статьи: Практика шлюза API в архитектуре Cloud Native. Прежде всего, давайте поговорим о конкретном определении облачных технологий.
Pivotal является создателем облачных приложений и запустил платформу облачных приложений Pivotal Cloud Foundry и среду разработки Java с открытым исходным кодом Spring, став пионером и первопроходцем в архитектуре облачных приложений. Мэтт Стайн из Pivotal в своем определении архитектуры облачных приложений выделяет несколько основных характеристик:
- Совместимость с 12-факторными приложениями
- Архитектура, ориентированная на микросервисы
- Гибкая архитектура самообслуживания
- Совместная работа на основе API
- антихрупкость
С развитием технологий концепция облачных вычислений постоянно совершенствуется. Определение облачных технологий в будущем изменится. Эта статья относится к определению CNCF версии 1.0:
Облачные технологии позволяют организациям создавать и запускать эластично масштабируемые приложения в новых и динамичных средах, таких как общедоступные, частные и гибридные облака. Репрезентативные облачные технологии включают контейнеры, сервисные сетки, микросервисы, неизменяемую инфраструктуру и декларативные API.
Поэтому одной из важных особенностей облачных шлюзов является возможность быстрой интеграции в постоянно выпускаемые облачные среды.
Зачем вам API-шлюз?
При использовании монолитной архитектуры приложения клиент (веб- или мобильный) извлекает данные, выполняя вызов REST к серверному приложению. Балансировщик нагрузки направляет запросы к одному из N идентичных экземпляров приложения. Затем приложение запрашивает различные таблицы базы данных и возвращает ответы клиенту. В микросервисной архитектуре одно приложение разделено на несколько микросервисов, и если все микросервисы открыты напрямую, неизбежно возникнут различные проблемы с безопасностью.
Клиент может отправлять запросы напрямую к каждому микросервису, и основные проблемы заключаются в следующем:
- Требования клиента не соответствуют детализированному API, предоставляемому каждой микрослужбой.
- Некоторые сервисы используют протоколы, которые не подходят для Интернета. Может использовать двоичный RPC Thrift или протокол обмена сообщениями AMQP.
- Микросервисы сложно рефакторить. Этот тип рефакторинга очень сложен, если вы объединяете два сервиса или разделяете сервис на два или более сервисов.
Прямое воздействие различных служб на сервере на клиентские вызовы обязательно вызовет различные проблемы. При этом каждый сервис на стороне сервера имеет плохую масштабируемость и масштабируемость. Шлюз API — это базовый компонент в архитектуре микросервиса, который находится под уровнем доступа и над уровнем бизнес-сервиса.Упомянутые выше функции подходят для реализации в шлюзе API.
Что касается компонентов с открытым исходным кодом сервисного шлюза, то это Netflix Zuul, Spring Cloud Gateway, Kong, Traefik, NGINX и Envoy типа сервисного шлюза. Новый программируемый шлюз был представлен в предыдущей статье: Spring Cloud Gateway, читатели, которым нужно знать, могут проверить его.Spring Cloud Gateway. В этой статье в основном рассказывается о Kong, современном шлюзе для микросервисов.. В представлении официального веб-сайта Kong первой особенностью являются облачные атрибуты Kong: независимо от платформы, Kong может работать с «голого железа» на Kubernetes. Эта статья основана на Kong 1.2.1, и часть пользовательского подключаемого модуля будет включать в себя некоторое кодирование Lua, что подходит для разработчиков серверов, эксплуатации и технического обслуживания.
Представляем Конга
Особенно выделяется высокопроизводительный и высокодоступный API-шлюз Mashape с открытым исходным кодом и уровень управления API-сервисами — KONG (на основе NGINX). Он может расширять существующие функции с помощью подключаемых модулей. Эти подключаемые модули (написанные на lua) находятся в жизненный цикл цикла ответа на запрос API. В то же время сам KONG предоставляет базовые функции, включая базовую аутентификацию HTTP, аутентификацию по ключу, CORS, TCP, UDP, журналы файлов, ограничение текущего запроса API, переадресацию запросов и мониторинг NGINX. В настоящее время Kong управляет более чем 15 000 API в Mashape, поддерживая 200 000 разработчиков с миллиардами запросов в месяц.
-
Что такое Конг
Когда мы решаем трансформировать приложение в микросервисы, возникает и проблема взаимодействия клиента приложения с микросервисами, ведь увеличение количества сервисов напрямую приведет к увеличению сложности авторизации развертывания, балансировки нагрузки, управление коммуникациями, анализ и изменения.API GATEWAY является хорошим решением для решения вышеуказанных проблем.Функции ограничения доступа, безопасности, управления потоком, мониторинга анализа, ведения журналов, переадресации запросов, синтеза и преобразования протоколов, предоставляемые API GATEWAY, позволяют разработчикам сосредоточиться на конкретном логическом коде, вместо того, чтобы тратить время на размышления о том, как решить проблему связки приложения и других микросервисов.
-
Зачем использовать Конг
Среди многих фреймворков API GATEWAY особенно выделяется высокопроизводительный и высокодоступный API-шлюз Mashape с открытым исходным кодом и уровень управления API-сервисами — KONG (на основе NGINX). Он может расширять существующие функции с помощью подключаемых модулей. в lua) используются в API Executed в течение жизненного цикла цикла запрос-ответ. В то же время сам KONG предоставляет базовые функции, включая базовую аутентификацию HTTP, аутентификацию по ключу, CORS, TCP, UDP, журнал файлов, ограничение текущего запроса API, переадресацию запросов и мониторинг NGINX. В настоящее время Конг управляет более чем 15 000 API в Mashape, поддерживая 200 000 разработчиков с миллиардами запросов в месяц.
Базовая архитектура Конга
Kong — это высокопроизводительный и высокодоступный API-шлюз Mashape с открытым исходным кодом и уровень управления API-сервисами.Это высокодоступный сервисный шлюз, написанный на основе модуля Nginx_Lua.Поскольку Kong основан на Nginx, он может горизонтально расширять несколько серверов Kong. Благодаря настройке предварительной балансировки нагрузки запросы равномерно распределяются между каждым сервером для обработки большого количества сетевых запросов.
Конг состоит из трех основных компонентов:
- Kong Server: сервер на базе nginx, который получает запросы API.
- Apache Cassandra/PostgreSQL: используется для хранения операционных данных.
- Панель инструментов Kong: официальный рекомендуемый инструмент управления пользовательским интерфейсом, конечно, вы также можете использовать метод restfull для управления API администратора.
Kong использует механизм подключаемых модулей для настройки функций, а набор подключаемых модулей (который может быть равен 0 или N) выполняется в жизненном цикле цикла ответа на запрос API. Плагин написан на Lua, и его основные функции включают в себя: базовую аутентификацию HTTP, аутентификацию по ключу, CORS (совместное использование ресурсов между источниками), TCP, UDP, журналы файлов, ограничение текущего запроса API, переадресацию запросов и мониторинг Nginx.
Kong Gateway имеет следующие особенности:
- Масштабируемость. Горизонтальное масштабирование упрощается простым добавлением дополнительных серверов, что означает, что ваша платформа может обрабатывать любые запросы с меньшей нагрузкой;
- Модульность: можно расширить, добавив новые плагины, которые можно легко настроить через RESTful Admin API;
- Работайте в любой инфраструктуре: Kong Gateway может работать где угодно. Kong можно развернуть в облачной или локальной сетевой среде, включая настройки с одним или несколькими центрами обработки данных, а также общедоступные, частные или доступные только по приглашению API.
срок
Введение в термины, обычно используемые в Kong, которые будут часто использоваться в следующей практике.
- Маршрут: правило пересылки запроса, в соответствии с именем хоста и ПУТЬ, запрос перенаправляется в службу;
- Службы: набор нескольких восходящих потоков, который является целью пересылки маршрута;
- Потребитель: пользователь API, который записывает информацию о пользователе;
- Плагин: Плагин, который может быть глобальным или привязанным к Сервису, Маршрутизатору или Потребителю;
- Сертификат: сертификат, настроенный по протоколу https;
- Sni: привязка доменного имени и сертификата с указанием https-сертификата, соответствующего доменному имени;
- Восходящий: восходящий объект используется для представления имени виртуального хоста.При наличии нескольких служб (целей) запрос будет сбалансирован по нагрузке;
- Цель: внутренняя служба, которая, наконец, обрабатывает запрос.
Создание сервисного шлюза с помощью Kong
Запрос клиента сначала будет обрабатываться через шлюз микросервиса, и некоторые общие функциональные аспекты будут действовать в шлюзе, то есть в подключаемом модуле в Kong, а затем запрос будет перенаправлен в соответствующий Backend-сервис, как показано на следующий рисунок.
После представления концепций того, зачем нужны микросервисные шлюзы и Kong, мы проведем реальный бой и будем использовать Kong для создания шлюзов.Практика установки
В настоящее время последней версией Kong является 1.2, и установка Kong поддерживается различными способами. Официально поддерживает установку следующими способами:
В дополнение к официальным методам установки существуют также методы установки, предоставляемые сообществом.Подробнее см.:emptylogistics.com/install/.
Для удобства автор устанавливает его на основе докера. Образы, зависимости и параметры, определенные в docker-compose.yml, следующие:
version: "3.7"
services:
kong:
image: kong:1.1.2
environment:
- "KONG_DATABASE=postgres"
- "KONG_PG_HOST=kong-database"
- "KONG_CASSANDRA_CONTACT_POINTS=kong-database"
- "KONG_PROXY_ACCESS_LOG=/dev/stdout"
- "KONG_ADMIN_ACCESS_LOG=/dev/stdout"
- "KONG_PROXY_ERROR_LOG=/dev/stderr"
- "KONG_ADMIN_ERROR_LOG=/dev/stderr"
- "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl"
ports:
- 8000:8000
- 8443:8443
- 8001:8001
- 8444:8444
networks:
- kong-net
depends_on:
- kong-database
konga:
image: pantsel/konga
environment:
- "TOKEN_SECRET=blueskykong.com"
- "NODE_ENV=production"
ports:
- 8080:1337
networks:
- kong-net
depends_on:
- kong-database
kong-database:
image: postgres:9.6
ports:
- "5432:5432"
environment:
- POSTGRES_USER=kong
- POSTGRES_DB=kong
networks:
- kong-net
volumes:
- /etc/localtime:/etc/localtime:ro
- /data/data/postgresql:/var/lib/postgresql/data
networks:
kong-net:
external: true
Приведенный выше файл docker-compose.yml запустит три контейнерных сервиса: Kong, konga и kong-database. Для связи между этими тремя контейнерами необходимо увеличить сегмент сети, поместить контейнер в тот же сегмент сети и изменить соответствующую ссылку на имя контейнера для доступа:
docker network create kong-net
Запущены три службы контейнеров в дополнение к двум службам за пределами Kong: konga Kong — это панель инструментов, инструменты управления клиентами на основе js, внешний доступ к порту 8080; kong-database — это служба базы данных Kong, для хранения информации о конфигурации здесь используется postgres. Обратите внимание, что перед запуском контейнера Kong, Docker-контейнерам необходимо сохранить рабочее состояние базы данных, а выполнение операций с базой данных инициализируется следующим образом:
docker run --rm \
--network=kong-net \
-e "KONG_DATABASE=postgres" \
-e "KONG_PG_HOST=kong-database" \
kong:latest kong migrations bootstrap
После успешной инициализации базы данных снова запустите службу docker-compose.yml. Мы видим, что Kong отображает несколько портов.По умолчанию Kong прослушивает следующие порты:
- 8000: этот порт используется Kong для прослушивания входящих HTTP-запросов от клиентов и пересылки запроса на сервер верхнего уровня (Kong перенаправляет его на реальный адрес фоновой службы в соответствии с настроенными правилами).
- 8443: Этот порт используется Kong для прослушивания входящих HTTPS-запросов от клиентов. Он аналогичен функции порта 8000 и перенаправляет HTTPS-запросы. Его можно отключить, изменив файл конфигурации;
- 8001: Admin API, через этот порт администраторы могут настраивать службу мониторинга Kong, параметры плагинов, добавления, удаления, изменения и балансировку нагрузки API, а другие конфигурации управляются через порт 8001;
- 8444: через этот порт администраторы могут отслеживать HTTPS-запросы.
После того, как контейнеры все начаты, давайте проверим:
curl -i http://localhost:8001/
HTTP/1.1 200 OK
Date: Sat, 20 Jul 2019 08:39:08 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Access-Control-Allow-Origin: *
Server: kong/1.1.2
Content-Length: 5785
...
Приведенные выше результаты показывают, что установка выполнена правильно и Kong можно использовать в обычном режиме. доступhttp://localhost:8080Чтобы получить доступ к интерфейсу управления Konga, вам необходимо создать учетную запись администратора и пароль для первого входа в систему.
Для получения дополнительной информации, пожалуйста, обратитесь к документации по установке на официальном сайте. До сих пор были установлены Kong и инструменты управления, следующее войдет в конкретную практику API Gateway.
Создать сервис
Как мы уже говорили в разделе терминологии, служба — это абстракция вышестоящей службы, которая может быть приложением или конкретным интерфейсом. Kong предоставляет интерфейс управления, мы можем создать его напрямую, запросив интерфейс управления 8001, или через установленный интерфейс управления, эффект тот же.
curl -i -X POST \
--url http://localhost:8001/services/ \
--data 'name=aoho-blog' \
--data 'url=http://blueskykong.com/'
Мы создаем службу с именемaoho-blog
, указанный адрес переадресацииhttp://blueskykong.com
. В интерфейсе управления вы можете увидеть следующие записи:
Создать маршрут
После создания службы нам нужно создать определенные маршруты API. Маршруты — это правила переадресации запросов, а также переадресация запросов на основе имени хоста и пути.
curl -i -X POST \
--url http://localhost:8001/services/aoho-blog/routes \
--data 'hosts[]=blueskykong.com' \
--data 'paths[]=/api/blog'
Как и выше, в aoho-blog создается маршрут доступа к /api/blog, и соответствующие записи можно увидеть в интерфейсе управления:
После создания маршрута мы можем получить доступ к /api/blog.
По умолчанию Kong обрабатывает прокси-запросы через порт 8000. Успешный ответ означает, что Конгhttp://localhost:8000
Запрос перенаправляется на настроенный URL-адрес, а ответ пересылается нам. Следует отметить, что если адрес, предоставляемый API, не соответствует адресу, определенному предыдущим хостом (blueskykong.com), в заголовок запроса необходимо добавить заголовок, Kong выполняет эту операцию в соответствии с заголовком: Хост, определенный в приведенном выше запросе.
резюме
В этой статье в основном представлены связанные концепции облачного и облачного шлюза, а затем представлены характеристики и базовая архитектура Kong, главного героя этой статьи. Показывает, как создать сервисный шлюз с помощью Kong. Существует множество подключаемых модулей, предоставляемых официальными лицами Kong и сообществом.Ниже будет объяснено использование общих подключаемых модулей в Kong и настройка собственных подключаемых модулей Kong.
Рекомендуемое чтение
Практика шлюза API в облачной архитектуре