Всем привет! Меня зовут Антон, я – инженер команды, отвечающей за развитие централизованных IT-сервисов, которыми пользуются продуктовые команды в X5 Retail Group. В этой статье я расскажу о системах класса API Management и в частности о APIM Gravitee (https://www.gravitee.io), том, что это за класс систем, как они используются для обеспечения потребностей команд разработки. Статья не погружает в технические аспекты, но может быть полезна архитекторам и менеджерам, которые думают о том, чтобы попробовать использовать данный класс систем, но не знают, подойдут ли они для их задач, а также разработчикам, которые могут открыть для себя новые инструменты для удобной работы с API. 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. У данных систем есть несколько преимуществ: Абстракция: система упрощает сложность сервисов под ним и предоставляет клиентам единый опыт. Аутентификация: система позволяет пройти аутентификацию, в том числе и через сторонние службы, например Keycloak. Управление трафиком: система регулирует входящий и исходящий трафик API. Мониторинг API: система может помочь в мониторинге запросов/ответов клиента. Преобразования: система позволяет преобразовать запросы/ответы API. К минусам можно отнести: Увеличение Latency: шлюзу необходимо время для обработки запросов/ответов согласно настроенным политикам. TCO: Совокупная стоимость владения для всей цепочки поставки ценности, естественно будет больше, чем просто установить nginx и выставить его наружу.  API Gateways работают как единая точка входа в ЦОД (центр обработки данных), группу распределенных служб или сервисов (см. рис. 2). Также API Gateways могут использоваться для связи между двумя продуктами/сервисами, развернутыми в одном ЦОД. API Gateways принимают вызовы от клиентов, обрабатывают их согласно политикам/правилам и направляют их в соответствующие сервисы. Чтобы API Gateways могли максимально быстро обрабатывать запросы от клиентов их делают максимально легковесными, с использованием асинхронных фреймворков. API Gateways, как правило, работают только на седьмом уровне (L7) модели OSI. С точки зрения расположения есть два места установки 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 В 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 Вариантов немного, но выбор есть: Вручную накликал и можно работать! Импортировать из swagger файла. Импортировать из Gitа/URLа. Рассмотрим ручной вариант настройки, выбираем "->" Ручное создание API проходит 5 шагов На первом шаге указываем имя API, версию, описание и уникальный путь, по которому это API будет доступно. Второй шаг может быть в двух модификациях: В Simple mode указываем только адрес нашего backend api, например: https://backend-server/backend-api/ В 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. Поддерживается формат swagger.json Данный пункт можно пропустить и заполнить уже в созданном API. На пятом шаге мы проверяем все что заполнили И выбираем либо "Создать API без установки на шлюз", либо "Создать и запустить API" Нажимаем CREATE и получаем частично настроенный API для работы. План предоставляет собой уровень обслуживания и доступа между API и приложениями. У одного API может быть несколько планов, но только один без ключевой - "keyless". План определяет ограничения доступа, режимы проверки подписи и другие настройки для адаптации к конкретному приложению. Основные настройки: Планы привязываются к конкретному шлюзу или группе шлюзов через Tags (см. рис. 3) 2. В плане указывается какой тип Аутентификации будет использован (см. рис. 4) 3. Можно сразу указать Rate и Quota лимиты и определить список разрешенных путей для запроса (см. рис. 5) 4. В последней вкладке можно указать политики, которые будут отрабатывать на начальном этапе обработки запросов (см. рис. 6) Итак, теперь вы знаете, что такое системы Management API, зачем они нужны и какой функциональностью обладают. Надеюсь, у вас сложилось понимание, какое место в архитектуре ИТ занимает данный класс систем и как их использовать с наибольшей отдачей. В течении пары месяцев, во второй части, я расскажу и покажу, как поставить и настроить APIM Gravitee с нуля для тестового окружения. Если данная тема интересна сообществу, задавайте вопросы, постараюсь максимально на них ответить.