Что такое APIG?

Функции продукта

• Управление жизненным циклом API

  Жизненный цикл API включает создание, публикацию, удаление и удаление API. Управление жизненным циклом API позволяет быстро и эффективно раскрывать сервисные возможности.

• Облачный нативный шлюз

  APIG интегрирует входящий трафик (Kubernetes Ingress) и управление микросервисами (Kubernetes Gateway API) в один шлюз, повышая производительность, упрощая архитектуру и снижая затраты на развертывание и O&M.

• Встроенный инструмент отладки

  С помощью встроенного инструмента отладки вы можете отлаживать API, используя различные HTTP-заголовки и тела запросов. Этот инструмент упрощает процесс разработки API и снижает затраты на разработку и обслуживание API.

• Управление версиями

  API может быть опубликован в разных средах. Повторная публикация API в той же среде перезапишет предыдущую версию API. APIG отображает историю публикаций (включая версию, описание, дату и время, а также среду) каждого API. Вы можете откатить API к любой исторической версии, чтобы удовлетворить требования темного запуска и обновления версии.

• Переменные среды

  Переменные среды управляемы и привязаны к конкретным средам. Переменные API заменяются значениями переменных в среде, где будет опубликован API. Вы можете создавать переменные в разных средах, чтобы вызывать разные бэкэнд‑сервисы с помощью одного API.

• Уточнённое ограничение запросов
  • Для разных требований к сервисам и уровней пользователей вы можете контролировать частоту вызова API пользователем, приложением (учетными данными) или IP‑адресом, обеспечивая стабильную работу бекенд‑сервисов.
  • Настройте различные ограничения пропускной способности запросов с параметрами пути API, запросов и заголовков.
  • Ограничение может быть точным до секунды, минуты, часа или дня.
  • Установите ограничения пропускной способности для исключённых приложений (учетных данных) и тенантов.
• Мониторинг и тревоги

  APIG обеспечивает визуализированный, в реальном времени мониторинг API и отображает несколько метрик, включая количество запросов, задержку вызова и количество ошибок. Метрики помогают вам понять использование API, позволяя выявлять потенциальные риски сервиса.

• Безопасность
  • Доступ к доменному имени может аутентифицироваться с использованием TLS 1.1 и TLS 1.2. Поддерживается двухсторонняя аутентификация mTLS.
  • Политики контроля доступа ограничивают доступ к API с конкретных IP‑адресов или учётных записей. Вы можете добавить в черный список или в белый список определённые IP‑адреса и учётные записи для доступа к вашим API.
  • Политики Circuit breaker защищают ваши бэкенд‑сервисы через деградацию, если они находятся в ненормальном состоянии.
  • Аутентификация Identity может базироваться на AK/SK, пользовательских авторизаторах на основе функций и токенах. APIG проверяет ваши backend services через сертификаты и проверяется вашими backend services с помощью signature keys.
• Каналы VPC (каналы балансировки нагрузки)

  Каналы Virtual Private Cloud (VPC) (каналы балансировки нагрузки) могут быть созданы для доступа к ресурсам в VPC и публикации backend services, развернутых в VPC. Каналы VPC балансируют API‑запросы к backend services и могут быть подключены к серверам и центрам регистрации микросервисов. Поддерживаются политики балансировки нагрузки backend и тёмного запуска.

• Мок‑ответ

  Mock backends имитируют API‑ответы для circuit breakers, деградации сервиса и перенаправления.

• HTTP2.0

  APIG поддерживает HTTP/2, который является крупным обновлением HTTP и изначально назывался HTTP 2.0. Он предоставляет возможности такие как бинарное кадрирование, мультиплексирование и компрессия заголовков, улучшая производительность передачи для достижения низкой задержки и высокой пропускной способности.

  • Бинарное кодирование

    В отличие от HTTP 1.x, где данные передаются в текстовом формате, данные в HTTP 2.0 разбиваются на сообщения и фреймы для бинарного кодирования. По сравнению с разбором строк (текст), бинарный разбор проще, менее подвержен ошибкам и обеспечивает более высокую производительность передачи.

  • Мультиплексирование

    С бинарным кодированием HTTP 2.0 больше не использует несколько соединений для одновременной обработки и отправки запросов и ответов.

    Для одного и того же доменного имени все запросы выполняются через одно соединение, и каждое соединение может обрабатывать любое количество сообщений. Сообщение состоит из одного или нескольких фреймов, которые могут передаваться в произвольном порядке и затем объединяться на основе stream ID в заголовке каждого фрейма. Это сокращает задержку и повышает эффективность.

  • Сжатие заголовков

    HTTP 2.0 использует кодировщик для уменьшения размера передаваемых заголовков. Как клиент, так и сервер хранят таблицу полей заголовков, чтобы избегать повторной передачи одинаковых заголовков, достигая высокой пропускной способности.

  Note

  • HTTP 2.0 сильно зависит от стабильности сети. Чтобы использовать HTTP 2.0, убедитесь, что ваша сеть стабильна и ваш клиент поддерживает этот протокол.
  • Если ваш шлюз не поддерживает HTTP 2.0, обратитесь в техническую поддержку для его обновления.
  • Чтобы отключить HTTP 2.0, выключите HTTP/2 в request_custom_config параметр в Параметры вкладка консоли APIG.