Зачем они нужны и какие функции они выполняют.
Всем привет! Меня зовут Антон, я инженер команды, отвечающей за развитие централизованныхIT-сервисов, которыми пользуются продуктовые команды вX5RetailGroup.
В этой статье я расскажу осистемах класса API Management и в частности о APIM Gravitee (https://www.gravitee.io), том, что это за класс систем, как они используются для обеспечения потребностей команд разработки. Статья не погружает в технические аспекты, но может быть полезна архитекторам и менеджерам, которые думают о том, чтобы попробовать использоватьданный класс систем, но не знают, подойдут ли они для их задач, а также разработчикам, которые могут открыть для себя новые инструменты для удобной работы с API.
Что такое системы API Management
Определение
API Management - это процесс создания и публикации программных интерфейсов веб-приложений (API), обеспечения соблюдения их политик использования, контроля доступа, поддержки сообщества подписчиков, сбора и анализа статистики использования и отчетности о производительности.
С другой стороны, API Management - это набор инструментов и сервисов, которые позволяют разработчикам и компаниям создавать, анализировать, применять и масштабировать интерфейсы API в безопасных средах.
В данных вариантах определения понятия "API Management" мы видим, что это процессы и системы позволяющие публиковать внутренние API сервисов, прописывать им определенные политики обработки запросов и ответов, контролировать доступ и анализировать статистику использования и производительности. Также рядом могут располагаться несколько подсистем, которые организуют выполнение необязательных функций, но интересных с точки зрения других подразделений, например монетизация API.
Зачем еще один огород городить?
Необходимость этого класса систем возникла в связи с увеличением количества сервисов, которые могут предоставлять свое API как конечный продукт для других сервисов. Ничего не напоминает? Правильно - микросервисная архитектура. Для организации это возможность ускорения "цифровизации". Владельцы продукта публикуют API, документацию к ней и прочие документы типа: планов развития, лимиты и т.д. Также всем хочется контролировать качество работы API, а это уже анализ производительности, статистика использования, проведение все возможных маркетинговых исследований и простой мониторинг. Для коллег из информационной безопасности будет интересно осуществлять наблюдение за использованием API в части контроля доступа: авторизация, аутентификация, аудит, проверка по черным/белым спискам IP. Для аналитиков и тестировщиков возможно будет интересна функциональность проверки корректности запросов, проверка корректности JSON или динамическое изменение запросов, для DevOps инженеров возможность установки rate limit, чтобы не было DoS конечного сервиса, настройка кэша и возможность оптимизации сервиса под микросервисную архитектуру: Service Discovery, Load Balancing, Blue/Green или Canary deploy.
Архитектура сервиса
В архитектуру сервиса API Management обычно входят (см. рис. 1):
-
Management Core: ядро системы, которое отвечает за формирование политик, планов, работу точками входа и выхода, настроек API Gateways и API, настройку CORS, Failover, Healthcheck, формирование запросов на отображение статистики использования API и логов.
-
Web/Development Portal: отвечает за UI, отображение настроек, статистики использования API, healthcheck и логов, а также позволяет общаться разработчикам, администраторам и владельцам API.
-
API Gateways: шлюзы или прокси, они отвечают за обработку запросов от клиентов сервиса согласно установленных настроек и политик, ведение логов запросов и ответов, а также запуск healthcheck по Backend API.
-
Backend API: отвечает за обработку запросов согласно бизнес-логике конечного сервиса.
-
Databases: в части сервиса API Management, хранят данные по настройке API, API Gateways, логи запросов клиентов и ответы backend, healthcheck, данные мониторинга практически всех компонентов API Management.
рис. 1 Архитектура сервиса API Management
Плюсы и минусы систем API Management
У данных систем есть несколько преимуществ:
-
Абстракция: система упрощает сложность сервисов под ним и предоставляет клиентам единый опыт.
-
Аутентификация:система позволяет пройти аутентификацию, в том числе и через сторонние службы, например Keycloak.
-
Управление трафиком: система регулирует входящий и исходящий трафик API.
-
Мониторинг API: система может помочь в мониторинге запросов/ответов клиента.
-
Преобразования: система позволяет преобразовать запросы/ответы API.
К минусам можно отнести:
-
Увеличение Latency: шлюзу необходимо время для обработки запросов/ответов согласно настроенным политикам.
-
TCO: Совокупная стоимость владения для всей цепочки поставки ценности, естественно будет больше, чем просто установить nginx и выставить его наружу.
APIGateways
API Gateways работают как единая точка входа в ЦОД (центр обработки данных), группу распределенных служб или сервисов (см. рис. 2). Также API Gateways могут использоваться для связи между двумя продуктами/сервисами, развернутыми в одном ЦОД. API Gateways принимают вызовы от клиентов, обрабатывают их согласно политикам/правилам и направляют их в соответствующие сервисы. Чтобы API Gateways могли максимально быстро обрабатывать запросы от клиентов их делают максимально легковесными, с использованием асинхронных фреймворков. API Gateways, как правило, работают только на седьмом уровне (L7) модели OSI.
рис. 2
ТипыAPI Gateways
С точки зрения расположения есть два места установки API Gateways:
-
Local API Gatewaysработают как шлюз для сервисов внутри организации.
-
DMZ API Gatewaysработают как шлюз для внешних потребителей и клиентов сервисов.
Для одного сервиса возможно использование обоих типов шлюзов, когда сервисом пользуются как внутренние потребители, так и внешние клиенты. В остальных случаях использование обоих типов шлюзов зачастую не целесообразно. Это связанно с основным минусом шлюзов - добавлением задержек при обработке запросов и ответов.
Наиболее распространенные системы
|
Name |
Tags |
|
APIGee |
Enterprise |
|
WSO2 API Manager |
Enterprise/Open source |
|
SAP API |
Enterprise |
|
3scale |
Enterprise |
|
IBM API Management |
Enterprise |
|
Kong |
Enterprise/Open source |
|
Mashery |
Enterprise |
|
Microsoft Azure API Management |
Enterprise |
|
Mule Soft |
Enterprise |
Централизованный сервис Gravitee
В X5 Retail Group в свое время выбрали для использования систему APIM Gravitee (https://www.gravitee.io). Основной сценарий использования нашими командами публикация API в локальной сети и в DMZ.
Немного цифр об этом сервисе на текущий момент:
-
23 продуктивных команд зарегистрировано
-
69 API Gateways для обслуживания запросов
-
400 Гб логов за сутки
-
350 RPS в среднем по больнице за сутки
-
30 000 000+ запросов обрабатывается за сутки
Функциональность
Рассмотрим базовую функциональность, предоставленную системой APIM Gravitee.
-
Identity provider: Аутентификация внешних пользователей можешь осуществляться на основе следующих систем и сервисов:
-
MongoDB (по умолчанию для новых пользователей, которые приглашаются);
-
In-memory (по умолчанию для пользователя admin);
-
LDAP / Active Directory;
-
OpenID Connect IdP (Azure AD, Google);
-
Fetchers: стянуть настройки для новой версии API и документацию можно через:
-
File (Swagger, OpenAPI);
-
HTTP;
-
GIT;
-
Policies: политики предназначены для изменения поведения, обрабатываемых шлюзом запросов и ответов. Каждый запрос и ответ обрабатывается согласно настроенной цепочке политик. Политики можно рассматривать как прокси-контроллер, гарантирующий выполнение данного бизнес-правила во время обработки. Примеры политик:
-
API Key - политика авторизации с использованием API-ключа;
-
Rate-limiting - политика ограничения скорости или квот для предотвращения флудинга backend;
-
Transform Headers/Transform Query Parameters - политика преобразований параметров заголовка или запроса;
-
etc.
Политик обработки запросов в Gravitee Gateway более 30 штук и с каждой версией их число увеличивается. Так же можно сделать свои политики. Но стоит учитывать, что чем больше политик "навешано", тем медленнее будет обрабатываться запрос и тем больше ресурсов будет использовано.
-
Reporters: сборщики логов используются экземпляром шлюза для сообщения о событиях. Типы сборщиков логов:
-
Reporter file;
-
Elasticsearch;
-
Accesslog;
Типы событий, которые можно собрать:
-
Метрики запроса/ответа например, время ответа, длина содержимого, api-ключ;
-
Мониторинг метрик например, процессора, использования кучи, кол-во открытых файлов и т.д.;
-
Показатели проверки работоспособности например, состояние, код ответа;
-
Repositories: репозиторий - это подключаемый компонент хранилища для настройки API, конфигураций политик, аналитики, аудита и так далее. Можно использовать следующие репозитории:
-
MongoDB (по умолчанию);
-
Redis;
-
Elasticsearch;
-
PostgreSQL (коннектор через JDBC и надо использовать другой дистрибутив);
-
Resources: ресурсы, которые можно использовать при работе:
-
OAuth2 (подключение к OAuth2 как источнику данных для аутентификации);
-
Cache (создание локального кэша на шлюзе);
-
LDAP (подключение к LDAP как источнику данных для аутентификации);
-
Services: сервисы, которые может предоставлять сам шлюз:
-
Sync (Синхронизация состояния шлюза с конфигурацией из репозитория управления);
-
local-registry (Локальный реестр используется для загрузки API в формате json из файловой системы. Таким образом, вам не нужно настраивать свой API с помощью веб-консоли или rest API (но вам нужно знать и понимать формат json API, чтобы он работал.));
-
health-check (Сервис для проверки состояния других сервисов);
-
monitor (Сервис извлекает метрики, такие как метрики os / process / jvm, и отправляет их в базовую службу отчетов);
-
Notifiers: сервис нотификаций используется для отправки уведомлений. В настоящее время единственным доступным каналом является электронная почта, но в ближайшее время запланированы другие, включая Slack.
-
Email;
-
Alerts: оповещение используется для отправки триггеров или событий в механизм оповещений, которые могут быть обработаны для отправки уведомления с помощью настроенного плагина Notifier.
-
Vertx;
А так как система с открытыми исходниками:https://github.com/gravitee-io, то при знании Java, можно написать свои собственные плагины и использовать как вздумается.
Настройки API
Настройка нового API проходит несколько этапов:
-
Создание API
-
Настройка планов
-
Привязываем API к шлюзам
Создание API
На странице создания API можно выбрать, как и из чего создать скелет нового API
Вариантов немного, но выбор есть:
-
Вручную накликал и можно работать!
-
Импортировать из swagger файла.
-
Импортировать из Git
а/URLа.
Рассмотрим ручной вариант настройки, выбираем "->"
Ручное создание API проходит 5 шагов
На первом шаге указываем имя API, версию, описание и уникальный путь, по которому это API будет доступно.
Второй шаг может быть в двух модификациях:
В Simple mode указываем только адрес нашего backend api, например:https://msk-dpro-sre000.x5.ru:8443/testbackend/
В Advanced mode необходимо указатьадрес нашего backend api, используемые tenant и sharding tags.
tenant- область выделенная в Elasticsearch для логов запросов и событий.
sharding tags- теги, согласно которым связываются API и Gateways
На третьем шаге можно указать Plan
Plan - это указание ограничений, которые будут влиять на обработку запросов, проходящих через данный Gateway.
Name -имяплана
Security type -типплана: Keyless(public), API Key, JWT, OAuth2
Description - просто описание плана и его особенностей
Rate limit - ограничение кол-ва запросов в секунду/минуту
Quota -ограничение кол-ва запросов в час/день/неделя/месяц
Path authorization - черный и белый список путей и методов к ним
Данный пункт можно пропустить и заполнить уже в созданном API.
На четвертом шаге можно загрузить файл документации по API
Поддерживается формат swagger.json
Данный пункт можно пропустить и заполнить уже в созданном API.
На пятом шаге мы проверяем все что заполнили
И выбираем либо "Создать API без установки на шлюз", либо "Создать и запустить API"
Нажимаем CREATE и получаем частично настроенный API для работы.
Настройки планов
План предоставляет собой уровень обслуживания и доступа между API и приложениями. У одного API может быть несколько планов, но только один без ключевой - "keyless". План определяет ограничения доступа, режимы проверки подписи и другие настройки для адаптации к конкретному приложению.
Основные настройки:
-
Планы привязываются к конкретному шлюзу или группе шлюзов через Tags (см. рис. 3)
Рис. 3
2. В плане указывается какой тип Аутентификации будет использован (см. рис. 4)
Рис. 4
3. Можно сразу указать Rate и Quota лимиты и определить список разрешенных путей для запроса (см. рис. 5)
Рис. 5
4. В последней вкладке можно указать политики, которые будут отрабатывать на начальном этапе обработки запросов (см. рис. 6)
Рис. 6
Заключение
Итак, теперь вы знаете, что такое системы Management API, зачем они нужны и какой функциональностью обладают. Надеюсь, у вас сложилось понимание, какое место в архитектуре ИТ занимает данный класс систем и как их использовать с наибольшей отдачей.В следующей частия буду рассказывать и показывать, как поставить и настроить одну из систем класса Management API с нуля для тестового прогона.
