Регистрация

[Тестирование IT-систем, IT-инфраструктура, API, DevOps] Что такое системы API Management

Ответить на тему
Автор Сообщение
news_bot ®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
19-Фев-2021 20:32
Цитировать

Зачем они нужны и какие функции они выполняют.Всем привет! Меня зовут Антон, я – инженер команды, отвечающей за развитие централизованных IT-сервисов, которыми пользуются продуктовые команды в X5 Retail Group.В этой статье я расскажу о системах класса 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 и выставить его наружу. 
API GatewaysAPI Gateways работают как единая точка входа в ЦОД (центр обработки данных), группу распределенных служб или сервисов (см. рис. 2). Также API Gateways могут использоваться для связи между двумя продуктами/сервисами, развернутыми в одном ЦОД. API Gateways принимают вызовы от клиентов, обрабатывают их согласно политикам/правилам и направляют их в соответствующие сервисы. Чтобы API Gateways могли максимально быстро обрабатывать запросы от клиентов их делают максимально легковесными, с использованием асинхронных фреймворков. API Gateways, как правило, работают только на седьмом уровне (L7) модели OSI.
рис. 2Типы API GatewaysС точки зрения расположения есть два места установки API Gateways:
  • Local API Gateways работают как шлюз для сервисов внутри организации.
  • DMZ API Gateways работают как шлюз для внешних потребителей и клиентов сервисов.
Для одного сервиса возможно использование обоих типов шлюзов, когда сервисом пользуются как внутренние потребители, так и внешние клиенты. В остальных случаях использование обоих типов шлюзов зачастую не целесообразно. Это связанно с основным минусом шлюзов - добавлением задержек при обработке запросов и ответов.Наиболее распространенные системыNameTagsAPIGeeEnterpriseWSO2 API ManagerEnterprise/Open sourceSAP APIEnterprise3scaleEnterpriseIBM API ManagementEnterpriseKongEnterprise/Open sourceMasheryEnterpriseMicrosoft Azure API ManagementEnterpriseMule SoftEnterpriseЦентрализованный сервис 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, OAuth2Description - просто описание плана и его особенностейRate limit - ограничение кол-ва запросов в секунду/минутуQuota - ограничение кол-ва запросов в час/день/неделя/месяцPath authorization - черный и белый список путей и методов к нимДанный пункт можно пропустить и заполнить уже в созданном API.На четвертом шаге можно загрузить файл документации по APIПоддерживается формат swagger.json
Данный пункт можно пропустить и заполнить уже в созданном API.На пятом шаге мы проверяем все что заполнили
И выбираем либо "Создать API без установки на шлюз", либо "Создать и запустить API"
Нажимаем CREATE и получаем частично настроенный API для работы.
Настройки планов План предоставляет собой уровень обслуживания и доступа между API и приложениями. У одного API может быть несколько планов, но только один без ключевой - "keyless". План определяет ограничения доступа, режимы проверки подписи и другие настройки для адаптации к конкретному приложению.Основные настройки:
  • Планы привязываются к конкретному шлюзу или группе шлюзов через Tags (см. рис. 3)

Рис. 32. В плане указывается какой тип Аутентификации будет использован (см. рис. 4)
Рис. 43. Можно сразу указать Rate и Quota лимиты и определить список разрешенных путей для запроса (см. рис. 5)
Рис. 54. В последней вкладке можно указать политики, которые будут отрабатывать на начальном этапе обработки запросов (см. рис. 6)
Рис. 6ЗаключениеИтак, теперь вы знаете, что такое системы Management API, зачем они нужны и какой функциональностью обладают. Надеюсь, у вас сложилось понимание, какое место в архитектуре ИТ занимает данный класс систем и как их использовать с наибольшей отдачей. В следующей части я буду рассказывать и показывать, как поставить и настроить одну из систем класса Management API с нуля для тестового прогона.
 ===========
 Источник:
habr.com
===========
Похожие новости: Теги для поиска: #_testirovanie_itsistem (Тестирование IT-систем), #_itinfrastruktura (IT-инфраструктура), #_api, #_devops, #_api, #_itinfrastruktura (it-инфраструктура), #_arhitektura (архитектура), #_testirovanie (тестирование), #_devops, #_development, #_produkty (продукты), #_produktivnost (продуктивность), #_infrastruktura (инфраструктура), #_menedzhment (менеджмент), #_blog_kompanii_x5_retail_group (
Блог компании X5 Retail Group
), #_testirovanie_itsistem (
Тестирование IT-систем
), #_itinfrastruktura (
IT-инфраструктура
), #_api, #_devops
Профиль  ЛС 
Показать сообщения:     
Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 16:23
Часовой пояс: UTC + 5