Русские Блоги
Микросервисы, ApiGateway и Kong
3. Использование Kong
1. Микросервисы
Для некоторых традиционных крупномасштабных проектов традиционный способ будет иметь некоторые недостатки, например, новички знакомы с высокой стоимостью системы (поскольку вся система в целом будет иметь определенное участие друг с другом)
Это займет много времени, трудно реорганизовать (для внедрения новой технологии может потребоваться отодвинуть весь проект назад), заменить новую технологию непросто, и весь проект постепенно станет гигантским.
Итак, будет концепция микросервисов, Служба реализует другую функцию или функцию. Каждый независимый микросервис представляет собой небольшое приложение. Некоторые микросервисы могут предоставлять некоторые API
Некоторые другие микросервисы или клиенты. Как показано на рисунке 1 ниже (разбить каждый бизнес):
Для микросервисов в настоящее время существуют такие приложения, как Netflix, Amazon, eBay и т. Д.
Конечно, у микросервисов также есть определенные недостатки: например, если каждая служба (каждое приложение) имеет базу данных, как поддерживать транзакции базы данных. В качестве другого примера, звонки между службами могут
Он может стать недоступным из-за сетевых причин, поэтому код, который не отвечает на запрос, должен быть добавлен в код.
2. Api Gateway
Поскольку все запросы будут проходить через этот шлюз API в первую очередь, Таким образом, вы можете выполнять контроль разрешений, безопасность, распределение нагрузки, распределение запросов, мониторинг и т. Д. Здесь 。
Итак, зачем использовать этот шлюз API? Основная причина в том, что клиент может напрямую запросить каждую услугу. У каждого сервиса есть URL. Эти URL будут равны нагрузке
Из-за брандмауэра или других ограничений могут потребоваться другие протоколы. Кроме того, в будущем При рефакторинге может потребоваться разделить интерфейс или объединить интерфейс Потому что клиент и API напрямую взаимодействуют, поэтому
Поэтому, как показано на рисунке 1, шлюз API можно изменить, как показано на рисунке 3 ниже:
Конечно, у любой технологии есть недостатки, как, например, у шлюза API, она может легко стать узким местом в производительности.
3. Использование Kong
Существует много способов реализации API-шлюза, например, на JVM можно использовать такие инфраструктуры на основе NIO, как Netty, Vertx, Spring Reactor, JOSS Undertow. Одним из процессов сравнения, который не основан на JVM, является NodeJs. Другие включают Nginx Plus.
Ниже описано использование Kong.
3.1 Установить Kong
3.1 Установить Kong
Проект Kong поможет вам переключиться на API вашего конечного приложения. Порт 8001 является портом управления. Например, администратор может получить API, добавленный вами через порт 8001.
KONG — The Microservice API Gateway
Jul 20, 2018 · 8 min read
Kong is Orchestration Microservice API Gateway. Kong provides a flexible abstraction layer that securely manages communication between clients and microservices via API. Also known as an API Gateway, API middleware or in some cases Service Mesh. It is available as open-source project in 2015, its core values are high performance and extensibility.
Kong is a Lua application running in Nginx and made possible by the lua-nginx-module.
The question is, Why Kong?
But for sure, kong is template engine that will help accelerate development time and it is support configurable plugins. And communities support development and make it stable. And no need to reinvent the wheel.
A lot of authentication plugin that we could choose from Basic authentication, JWT, LDAP until the most used — Oauth2.
Security plugin that additional security layers such as ACL, CORS, Dynamic SSL, IP Restriction.
Traffic control plugin is a very useful for limited cost such as rate limiting, request size limiting, response rate limiting and others.
Analytics and monitoring plugin that visualise, inspect and monitor API traffic such as Prometheus, data dog and Runscope.
Transformation plugin that transform request and responses on the fly such as Request Transformer, Response Transformer.
Logging plugin that log request and response data using the best transport for your infrastructure: TCP, UDP, HTTP, StatsD, Syslog and others.
So, now in this article we would try basic how to setup and use KONG. To do so, it is required to have basic:
Install Kong Community Edition
Kong is available to install in multiple operating environments. For the easiest installation, we use docker, and for this tutorial is required to have basic knowledge docker. Please follow the basic tutorial installation and using docker.
Now we start install KONG.
First — Create a docker network — this network will be use for kong and our API server
Second — Start database for Kong — there is two option database : Postgres or Cassandra. For know we use postgres.
Third — Prepare database, run migration with Kong container:
Fourth — Start the Kong, when the migrations have run and your database is ready, start a kong container.
Five, Check Kong Instance.
The respond would be:
Now Kong is up and ready to be used. The next thing is prepare the API server that contain service routes and can be accessed as REST API use to be.
Setup API server routing using node.js
Now prepare the API server, for this tutorial we are going to use node.js as API server.
To make it simple, please clone the code from GitHub faren-NodeJS-API-KONG.
And it should contain like this in terminal:
Let’s build docker image and run it, by execute instruction below:
Check all docker has been run, by execute below:
Check API server by access its API. We need to get IP container on docker network kong-net. After that get into container kong shell and check the API from it.
Execute this command bellow on terminal:
Please make sure the IP on node_kong on bold font, and make sure execute curl the IP bellow, it is definitely different every machine that you’ve installed.
Above respond showing the node.js server API is alive and can serve GET method REST /api/v1/workers
Setup KONG as API-gateway to API server routing
Now we have complete KONG engine and node.js API service and start register our API to Kong. Here is the flow would be:
Routes are entry-points in Kong and define rules to match client requests. Once a Route is matched, Kong proxies the request to its associated Service. And the service that has been defined will be direct to API server that is ready to serve.
For example ( Warning: IP might very different for every machine)
We set routes path /api/v1/customers
And set the service host to http://172.19.0.4:10000, and path /api/v1/customers
To start please import postman collection file on github NodeJS-API-KONG (https://github.com/faren/NodeJS-API-KONG) — kong.postman_collection.json.
So let’s see in practice take a look postman collection that has been imported:
For this tutorial, we would like have above scenario:
REST for customers and clients.
First the all, we need to register service customer and then register match routes requested. Please make sure for the IP that on this tutorial might very different with every machine, please take a look how to get node_kong ip from docker network.
Add service: customers
Find collection Kong, folder Services, POST Services — Create:
List service
Find collection Kong, folder Services, GET Services — List:
Now we have created service customers, next we create routes for service customers.
Add Routes: customer
Find collection Kong, folder Routes, POST Routes — Create (take a notice to highlight API below):
List routes
Find collection Kong, folder Routes, GET Routes — List:
Now we can access API customer from KONG (http://localhost:9000/api/v1/customers)
Conclusion
Kong is a scalable, open source API Layer (also known as an API Gateway, or API Middleware). Kong runs in front of any RESTful API and is extended through Plugins, which provide extra functionality and services beyond the core platform.
To better understand the system, this is a typical request workflow of an API that uses Kong:
Once Kong is running, every request being made to the API will hit Kong first, and then it will be proxied to the final API. In between requests and responses Kong will execute any plugin that you decided to install, empowering your APIs. Kong effectively becomes the entry point for every API request.
The Powerful of Kong is also supported by plugins from authentication, security, traffic control, logging, and etc…
Here is my sharing how to enable and use the most functionality that common used by backend server side:
Kong Gateway
The world’s most popular API gateway. Built for hybrid and multi-cloud, optimized for microservices and distributed architectures. Get started today – download Kong Gateway for free.
Looking to download Kong Gateway? Visit download page →
Sub-millisecond performance
Looking for sub-millisecond processing latency to support thousands of transactions per second? The lightweight Kong Gateway core has you covered.
Universal deployment
Kong Gateway supports hybrid or multi-cloud infrastructure, and includes a Kubernetes-native ingress solution and support for declarative configuration management
Unlimited extensibility
Need more functionality to integrate with your IdP, add an API key to a service or simply transform requests before they hit your server? There’s a plugin for that.
“Kong came out a clear winner”
Gigaom
See where Kong stacks up for companies that experience workloads of more than 1,000 transactions per second and need a maximum latency of less than 30 milliseconds
Accelerate your microservices journey with the world’s most popular API gateway
Accelerate your microservices journey with the world’s most popular API gateway
Focus on building, not operations
Kong Gateway is part of the Konnect managed connectivity platform. Konnect delivers connectivity functionality such as API Portals and AI-based anomaly detection, while providing the flexibility of running high performance connectivity runtimes.
Expand capabilities with plugins
Use one of the many plugins developed by Kong or our community to add the functionality you need. Can’t find what you need? Build your own plugin with our built in, well-documented plugin development kit.
Be an APIOps superhero
Configure Gateway natively using an API, web UI, or with declarative configuration to manage updates via your CI/CD pipelines.
Support for multiple operating environments
We have packages that support management within Docker containers or traditional servers like Debian and RedHat.
Run natively on Kubernetes
Our Kubernetes Ingress controller uses native CRDs that allow users to declaratively configure every aspect of Gateway from plugins, health checks, load balancing and more.
Get Started in Minutes
Add your Service and Route on Kong
After installing and starting Kong, use the Admin API on port 8001 to add a new Service and Route. In this example, Kong will reverse proxy every incoming request with the specified incoming host to the associated upstream URL. You can implement very complex routing mechanisms beyond simple host matching.
Add Plugins on the Service
Then add extra functionality by using Kong Plugins. You can also create your own plugins!
. and then you can consume the Service on port 8000 by requesting the specified host. In production setup the public host DNS to point to your Kong cluster. Kong supports much more functionality, explore the Hub and the documentation.
Kong Gateway is part of the Konnect Connectivity Platform
Want to learn more about Konnect? Contact us today to schedule a demo of the Konnect Connectivity Platform from one of our technical solutions engineers.
Русские Блоги
Используйте Kong и Konga для управления микросервисами и API
В микросервисной архитектуре сервисы разбираются очень фрагментированно, что снижает степень связанности, а также увеличивает сложность унифицированного управления сервисами. Как показано слева на приведенном выше рисунке, в рамках старой системы управления службами общие функции, такие как аутентификация, ограничение тока, ведение журнала и мониторинг, должны быть реализованы в каждой службе отдельно, что лишает специалиста по обслуживанию системы глобального представления для управления ими. Особенности. Проблема, которую API-шлюз стремится решить, заключается в управлении этими общими функциями для микросервисов и улучшении масштабируемости системы на этой основе. Как показано на рисунке справа, комбинация микросервисов со шлюзом API может сделать сам сервис более сфокусированным на собственном домене и хорошо изолировать вызывающих сервисов и поставщиков сервисов.
Механизм подключаемых модулей Kong является основой его высокой масштабируемости. Kong может легко предоставлять различные подключаемые модули для маршрутизации и услуг. Основные функции, необходимые для шлюза, полностью поддерживаются Kong:
Собственное облако:Независимо от платформы Kong может работать с нуля до Kubernetes.
Динамическая маршрутизация:За Kong стоит OpenResty + Lua, поэтому он наследует характеристики динамической маршрутизации от OpenResty.
Предохранитель
медицинское обследование
Журнал:Он может записывать запросы и ответы HTTP, TCP, UDP через Kong.
Аутентификация:Контроль разрешений, черный и белый списки IP также являются функциями OpenResty.
SSL: Setup a Specific SSL Certificate for an underlying service or API.
монитор:Kong предоставляет плагины для мониторинга в реальном времени
Сертификация:Поддержка HMAC, JWT, Basic, OAuth2.0 и других распространенных протоколов
Ограничение
REST API:Управление конфигурацией через Rest API, свободное от утомительных файлов конфигурации
Доступность:Естественно поддержка распределена
высокая производительность:Благодаря неблокирующей связи nginx производительность не требует пояснений
Подключаемый механизм:Предоставляет множество готовых подключаемых модулей и имеет настраиваемый интерфейс подключаемых модулей, который легко расширять. Пользователи могут использовать Lua для разработки своих собственных подключаемых модулей.
1. Установка
Kong поддерживает множество способов установки, здесь используется установка Docker, которая относительно проста.
1.1 Установите Kong
Использовать базу данных
1. Создайте сеть Docker.
Во-первых, нам нужно создать настраиваемую сеть, чтобы несколько контейнеров могли обнаруживать и взаимодействовать друг с другом, а имя сети можно было бы назвать как угодно.
2. Запустите базу данных.
Вы можете использовать PostgreSQL или Cassandra в качестве хранилища. Здесь PostgreSQL выбран в качестве базы данных Kong.
Если вы хотите использовать Cassandra.
3. Подготовьте базу данных.
Теперь давайте подготовим нашу базу данных, запустив короткий контейнер Kong, который выполнит соответствующую миграцию и умрет!
Примечание. В приведенном выше примере, если вы используете Cassandra, вам следует обновить значение переменной среды KONG_DATABASE до cassandra.
Когда миграция будет запущена и база данных будет готова, запустите контейнер Kong, который подключится к вашему контейнеру базы данных.
Kong’s admin API is exposed on port 8001 and the gateway on port 8000
1.2 Установите Konga
Текущая версия KONG для сообщества не имеет панели управления, но доступна платная корпоративная версия, а также есть некоторые плагины, которые могут использоваться только корпоративной версией и обновленной корпоративной версией. Поэтому для пользователей, использующих версию сообщества, чтобы исключить возможность выбора панели мониторинга, сторонняя панель мониторинга с открытым исходным кодом, несомненно, является первым выбором. В настоящее время существует три панели мониторинга, которые все еще обновляются и поддерживаются на GitHub, а именно kong-dashboard, kongdash и konga.
Говоря о графическом интерфейсе управления Kong, в Интернете больше всего говорят о kong-dashboard, но последняя версия (v3.6.0), похоже, не поддерживает последнюю версию Kong. В настоящее время Konga может найти больше звезд в github. Konga не только поддерживает последнюю версию Kong (новые функции разделения услуг и маршрутов), но также поддерживает контроль разрешений администраторов и управление несколькими пулами соединений Kong. Поскольку Konga поставляется с контролем разрешений пользователей и управлением пулом соединений Kong, ему требуется некоторая обработка сохраняемости данных. По умолчанию поддерживаются базы данных mongodb, postgres и mysql. Здесь мы выбираем PostgresSQL, потому что база данных, подключенная KONG, также является PGSQL, что может сократить развертывание базы данных.
1. Как и раньше, нам нужно подготовить базу данных Konga, запустив короткий контейнер.
Когда миграция запущена, мы можем запустить Konga
After a while, Konga will be available at:
Вам необходимо зарегистрировать учетную запись администратора
Во-вторых, операция Конга
2.1 Настройка подключения
После успешного входа в систему вы увидите эту страницу:
На этом этапе вам необходимо вручную создать соединение с API управления Kong.
Если вы откроете страницу подключений, вы заметите, что подключение к ранее созданному экземпляру Kong уже существует, но еще не было активировано.
Нажмите кнопку активации. Если все настроено правильно, Konga подключится к Kong, и интерфейс будет полон крутизны.
2.2 Основные концепции
Кратко представьте некоторые основные концепции
Dashboard
Передача не удалась повторно загрузитьотменить
На панели инструментов отображается основная информация об экземпляре Kong, к которому вы в настоящее время подключены, о базовой базе данных и доступных плагинах. Более подробную информацию можно найти на странице ИНФОРМАЦИЯ.
Snapshots
Функция моментального снимка позволяет легко создавать резервные копии, восстанавливать и перемещать конфигурации Kong между узлами. Вы также можете запланировать автоматические снимки экземпляров Kong.
Settings
На странице настроек можно легко настроить Konga и установить базовые списки ACL для учетных записей пользователей. Помните, что разрешения пользователей устанавливаются глобально и относятся к учетным записям пользователей как к объектам. Однопользовательский ACL пока не поддерживается.
В-третьих, Konga создает сервисы (Services) и маршруты (Routes).
Мы будем использовать отличный онлайн-поддельный API (автор:typicodeПрилагается) для тестирования и прототипирования.
Перейдите на страницу услуги и добавьте новую услугу. Заполните форму следующим образом:
Передача не удалась повторно загрузитьотменить
После отправки сервис создан, детали следующие:
Передача не удалась повторно загрузитьотменить
API jsonplaceholder предоставляет следующие ресурсы (при условии, что у нас есть эти API):
posts
comments
albums
photos
todos
users
Нам нужно создать маршруты для этих ресурсов. Щелкните службу json-placeholder, выберите вкладку маршрутов и добавьте новый маршрут.
такие как:
If your route has /my-service in the paths property, then
/my-service/foo will be routed upstream as /foo,
/my-service/bar will be routed upstream as /bar.
I’d recommend you to go through the definition of the Route Object in Kong to gain a better understanding.
Аналогичным образом создайте второй маршрут, который отвечает на запросы POST, PUT, PATCH и DELETE.
Идите вперед, создайте нового пользователя и протестируйте его:
На данный момент мы успешно развернули Kong & Konga и смогли получить доступ к API jsonplaceholder через наш шлюз.
В-четвертых, принцип работы Kong
4.1 Порты открываются по умолчанию в конге
Порт, который принимает клиентский трафик, прокси-часть
административная часть порта API
4.2 Конфигурация Nginx Конфигурация VS Kong
Давайте посмотрим, как типичная конфигурация Nginx соответствует Kong. Ниже представлена типичная конфигурация Nginx.
Давайте посмотрим на его соответствующую конфигурацию в Kong
Все эти конфигурации динамически реализуются через его Http Restful API, без необходимости вручную перезагружать Nginx.conf. Студенты, занимающиеся развитием, очень счастливы, видя это.
В приведенной выше конфигурации задействовано несколько концепций: апстрейн, цель, служба, маршрут и другие концепции. Это несколько основных концепций Kong, с которыми мы часто сталкиваемся при использовании Kong Api. Ниже мы рассмотрим несколько его основных концепций. Вот краткое описание.
4.3 Ключевые термины Kong / анализ существительных
Target
Целевой IP-адрес / имя хоста, а его порт указывает на экземпляр внутренней службы. У каждого восходящего потока может быть несколько целей, и цели могут добавляться динамически.
Поскольку восходящий поток поддерживает историю изменений цели, цель не может быть удалена или изменена. Чтобы отключить цель, введите новое значение Targer weight = 0 или используйте DELETE для выполнения той же операции.
Service
Как следует из названия, сервисный объект является абстракцией каждой вышестоящей службы. Примерами сервисов являются микросервисы преобразования данных, API биллинга и т. Д.
Основным атрибутом службы является ее URL-адрес (где Kong должен проксировать трафик), который может быть задан как одна строка или путем указания протокола, хоста, порта и пути.
Сервисы связаны с маршрутами (у сервисов может быть много связанных с ними маршрутов). Маршрутизация является точкой входа в Kong и определяет правила, соответствующие запросам клиентов. Как только маршрут будет согласован, Kong отправит запрос соответствующей службе.
Route
Объект маршрутизации определяет правила для соответствия запросам клиентов. Каждый маршрут связан с услугой, и у услуги может быть несколько связанных с ней маршрутов. Каждый запрос, соответствующий заданному маршруту, будет проксирован для соответствующей службы. Настраиваемые поля:
Комбинация Service и Route (и разделение проблем между ними) обеспечивает мощный механизм маршрутизации, с помощью которого в Kong могут быть определены точные точки входа, чтобы инфраструктура могла маршрутизировать различные вышестоящие службы.
Consumer
Объект Consumer представляет потребителя или пользователя службы. Вы можете положиться на Kong как на основное хранилище базы данных или можете сопоставить список пользователей с базой данных, чтобы поддерживать согласованность между Kong и существующим основным хранилищем данных.
Plugin
Сущность подключаемого модуля представляет конфигурацию подключаемого модуля, которая будет выполняться в течение жизненного цикла HTTP-запроса / ответа. Как он добавляет функции к службам, работающим за Kong, например, аутентификацию или ограничение скорости.
При добавлении конфигурации подключаемого модуля к службе каждый запрос от клиента к службе запускает подключаемый модуль. Если конкретному потребителю необходимо настроить подключаемый модуль на другое значение, вы можете создать отдельный экземпляр подключаемого модуля и указать службу и потребителя в полях service и consumer.
Note:Запрошенный Клиентом трафик направляется в соответствующую Службу через Маршрут. Если подключаемый модуль настроен, подключаемый модуль будет использоваться. После того, как Служба получит трафик, он будет отправлен в соответствующую службу восходящего потока.
Пять, работа Kong API
5.1 Служба конфигурации
Добавьте сервис в Kong, отправив HTTP-запрос в Admin API:
Зарегистрируйте здесь службу с именем «foo-service», которая указывает наhttp://foo-service.com(Восходящий поток).
5.2 Правила сопоставления маршрутов
Теперь давайте обсудим, как Kong сопоставляет запросы с настроенными атрибутами (или полями) хоста, пути и методов для маршрутизации. Обратите внимание, что все три поля являются необязательными, но необходимо указать хотя бы одно из них.
Для запросов на сопоставление маршрутов:
Возникает вопрос, какова роль хоста в маршруте Kong? не имеет смысла? Какие сценарии будут использовать несколько хостов?
Это официальное объяснение:
Routing a request based on its Host header is the most straightforward way to proxy traffic through Kong, as this is the intended usage of the HTTP Host header. Kong makes it easy to do so via the hosts field of the API entity.
Очевидно, официальное описание хоста не отвечает на поставленный выше вопрос. Давайте посмотрим на объяснение хоста в Интернете:
Мы знаем, что в заголовке HTTP-запроса будет поле Host. Многие люди не очень понимают конкретную роль или использование этого поля, в том числе меня спрашивали многие люди, и я был немного смущен. Вот конкретная грамотность.
Однако концепция хоста до сих пор не упоминается. На самом деле, вы можете взглянуть на это так. Наша виртуальная машина 111.111.111.111 может фактически размещать множество веб-сайтов (в противном случае было бы неразумно, если бы можно было разместить только один веб-сайт, а затем виртуальную машину Многие ресурсы тратятся впустую), мы можем разместить www.qiniu.com, www.taobao.com и www.jd.com на виртуальной машине, но каждый раз, когда мы посещаем эти доменные имена, будут возникать проблемы. Фактически, он разрешен к IP-адресу сервера 111.111.111.111. Как я могу различать содержимое разных веб-сайтов, отображаемое в соответствии с доменным именем каждый раз? Фактически, для этого требуется концепция Хоста в заголовке запроса. Каждый Хост можно рассматривать как меня На сайте на сервере 111.111.111.111 каждый раз, когда я использую эти доменные имена для доступа к одной и той же виртуальной машине, он разрешает одну и ту же виртуальную машину. Да, но я могу различать, какой сайт на этой виртуальной машине я посещаю через разные хосты.
Давайте рассмотрим еще несколько примеров, чтобы полностью понять. Рассмотрим маршрут, настроенный следующим образом:
Ниже мы предполагаем, что запрос Host не приносит
Обратите внимание на заголовок запроса: * Connected to localhost (127.0.0.1) port 8000 (# 0); клиент установил tcp-соединение с Kong, но хост пуст, поэтому Kong не может соответствовать указанному выше маршруту.
Посмотрим на запрос на установку правильного хоста:
На этот раз конг совпал с маршрутом, так что я получил данные.
Итак, роль Хоста указана выше, теперь она полностью ясна.
