Шлюз API в службе "Управление API Azure"

ОБЛАСТЬ ПРИМЕНЕНИЯ: все уровни Управление API

В этой статье описываются роли и функции компонента шлюза управления API. Он также сравнивает шлюзы, которые можно развернуть.

Дополнительные сведения.

• Общие сведения о сценариях, компонентах и концепциях Управления API см. в статье Что собой представляет Управление API Azure.

• Дополнительные сведения об уровнях и возможностях службы Azure API Management см. в статье Сравнение уровней Azure API Management по функциям.

Роль шлюза

Шлюз Управления API (также называемый плоскость данных или среда выполнения) — это компонент службы, отвечающий за посредничество запросов API, применение политик и сбор телеметрии.

В частности, шлюз:

• выступает в качестве фасада для задних служб, принимая вызовы API и перенаправляя их в соответствующие задние части.
• Проверяет ключи API и другие учетные данные, такие как JWTs и сертификаты , представленные запросами
• принудительно применяет квоты использования и ограничения скорости;
• при необходимости преобразует запросы и ответы, указанные в инструкциях политики;
• если настроить, кэширует ответы, чтобы повысить задержку ответа и свести к минимуму нагрузку на серверные службы;
• создает журналы, метрики и трассировки для мониторинга, создания отчетов и устранения неполадок.

Управляемые и локальные шлюзы в службе управления API

Управление API предлагает как управляемые, так и самостоятельные шлюзы.

• Встроенный управляемый шлюз — управление API предоставляет единый встроенный управляемый шлюз по умолчанию для каждого экземпляра управления API на каждом уровне служб. При использовании управляемого шлюза весь трафик API проходит через Azure независимо от того, где размещаются серверные серверы, реализующие API. На уровне "Премиум" дополнительно добавьте и распределите емкость шлюза в нескольких регионах.

  Note

  Из-за различий в базовой архитектуре служб шлюзы, предоставляемые на разных уровнях служб Управление API, имеют некоторые различия в возможностях. Дополнительные сведения см. в разделе Сравнение функций: управляемые и локальные шлюзы.

• Управляемый шлюз рабочей области — трафик API, управляемых в рабочих областях, может проходить через управляемый шлюз по умолчанию (на уровнях v2) или через связанный с рабочей областью шлюз (только на уровнях Premium). Шлюзы рабочих областей обеспечивают изоляцию трафика среды выполнения между рабочими областями, повышая надежность API. Шлюз рабочей области — это автономный Azure ресурс с теми же основными функциями, что и управляемый шлюз по умолчанию, но он не поддерживает некоторые из его функций. Рабочая область может быть связана с одним или несколькими шлюзами рабочих областей.

• Локальный шлюз . В выборе уровней служб локальный шлюз является необязательной контейнерной версией управляемого шлюза по умолчанию. Разные уровни поддерживают разное количество шлюзов, размещённых самостоятельно. Это полезно для гибридных и многооблачных сценариев, когда требуется запустить шлюзы из Azure в тех же средах, где размещаются серверные серверы API. Локальный шлюз позволяет клиентам с гибридной ИТ-инфраструктурой управлять API, размещенными локально и в облаках, из единой службы управления API в Azure.

  • Локальный шлюз упаковывается в виде контейнера Docker на базе Linux и обычно развертывается в Kubernetes, включая Службу Azure Kubernetes и Kubernetes с поддержкой Azure Arc.

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

Сравнение функций: управляемые и локальные шлюзы

Следующие таблицы сравнивают функции, доступные в следующих шлюзах Управление API:

• Классический — управляемый шлюз, доступный на уровнях служб "Разработчик", "Базовый", "Стандартный" и "Премиум" (раньше группировались как выделенные уровни).
• Версия 2 — управляемый шлюз, доступный на уровнях "Базовый" версии 2, "Стандартный" и "Премиум" версии 2
• Потребление — управляемый шлюз, доступный на уровне потребления
• Самостоятельно размещённый — необязательный шлюз, доступный в определённых уровнях обслуживания
• Рабочая область — управляемый шлюз, доступный в рабочей области в выборе уровней служб

Infrastructure

¹ Зависит от способа развертывания шлюза, но за него отвечает клиент.
² Подключение к локальной конечной точке конфигурации шлюза версии 2 требует разрешения DNS имени узла конечной точки.
³ корневых сертификата УЦ для локальных шлюзов управляются отдельно для каждого шлюза.
^{Необходимо включить протокол 4} клиента.
⁵. Настройте с помощью политики пересылки запросов.
⁶ Настройка сведений о сертификате ЦС для проверки подлинности сертификата серверной части в параметрах серверной части.
⁷ Доступно в предварительной версии для экземпляров классического уровня, созданных начиная с января 2026 года. Обратитесь в службу поддержки, чтобы активировать существующие экземпляры классического уровня.

Интерфейсы API серверной части

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

Policies

Управляемые и локальные шлюзы поддерживают все доступные политики в определениях политик с приведенными ниже исключениями. Дополнительные сведения о каждой политике см. в справочнике по политике.

¹ Настроенные политики, которые не поддерживаются самостоятельно размещённым шлюзом, пропускаются во время выполнения политики.
² Ограничение частоты запросов по ключу, квота по ключу и политики ограничения токенов LLM недоступны на уровне Consumption.
³ Счётчики ограничений скорости в самостоятельно размещённом шлюзе можно настроить для локальной синхронизации (между экземплярами шлюза на узлах кластера), например, через развертывание Helm chart для Kubernetes или с помощью шаблонов развертывания портала Azure. Однако количество ограничений скорости не синхронизируется с другими ресурсами шлюза, настроенными в экземпляре Управление API, включая управляемый шлюз в облаке. Подробнее

Мониторинг API

Дополнительные сведения о параметрах мониторинга см. в статье Наблюдаемость в Управлении API Azure.

¹ Уровни версии 2 поддерживают аналитику на основе Azure Monitor.
² Шлюз использует встроенный буфер памяти приложение Azure Insights и не предоставляет гарантии доставки.
³ Локальный шлюз в настоящее время не отправляет журналы ресурсов (журналы диагностики) в Azure Monitor. При желании можно отправлять метрики в Azure Monitor или настраивать и сохранять журналы локально, где развернут локальный шлюз.

Проверка подлинности и авторизация

Управляемые и локальные шлюзы поддерживают все доступные параметры проверки подлинности и авторизации API со следующими исключениями.

Пропускная способность и масштабирование шлюза

Управляемый шлюз

Сведения о предполагаемой максимальной пропускной способности шлюза на уровнях служб Управления API приведены в статье Цены на Управление API.

• Классические уровни

  • Емкость шлюза можно масштабировать путем добавления и удаления единиц масштабирования или обновления уровня служб. (Масштабирование недоступно на уровне разработчика.)
  • В уровнях "Базовый", "Стандартный" и "Премиум" при необходимости настройте автомасштабирование Azure Monitor.
  • На уровне "Премиум" при необходимости добавьте и распределите емкость шлюза между несколькими регионами.

• Уровни версии 2

  • Емкость шлюза можно масштабировать путем добавления и удаления единиц масштабирования или обновления уровня служб.
  • При необходимости настройте автомасштабирование Azure Monitor.

• Уровень потребления

  • Экземпляры службы "Управление API" в тарифе "Потребление" масштабируются автоматически в соответствии с объемом трафика.

Локально размещённый шлюз

• В таких средах, как Kubernetes, добавьте несколько реплик шлюза для обработки ожидаемого использования.
• При необходимости настройте автоматическое масштабирование в соответствии с требованиями трафика.

Шлюз рабочего пространства

Масштабирование емкости путем добавления и удаления единиц масштабирования в шлюзе рабочей области.

Ограничения времени исполнения шлюза

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

¹ Подключения объединяются в пул и повторно используются, если серверная часть их явно не закрывает.
^{Ограничение 2} — 1024 на уровне разработчика.
³ Содержит длинную строку запроса размером до 2048 байт.
^До максимум 60 000 подключений на экземпляр службы.

Конечная точка проверки работоспособности шлюза

На всех уровнях, кроме уровня потребления, служба "Управление API Azure" предоставляет встроенную конечную точку проверки работоспособности шлюза по пути /status-0123456789abcdef. Обратитесь к этой конечной точке, чтобы убедиться, что шлюз API доступен и работает правильно. Он не проверяет API серверной части, только сам шлюз.

Запрос к конечной точке возвращает 200 OK HTTP-ответ, когда шлюз работоспособен; сбои указывают на проблемы сети или шлюза.

• Azure использует эту конечную точку внутренне для непрерывного мониторинга уровней обслуживания и проверки работоспособности шлюза.
• Клиенты могут интегрировать запросы к этой конечной точке в собственные средства мониторинга и пробы.
• Конечная точка доступна для управляемых шлюзов (включая региональные шлюзы в развертываниях с несколькими регионами), локальные шлюзы и шлюзы рабочих областей.

Связанный контент

Дополнительные сведения:

• Управление API в гибридном и многооблачном мире
• Метрика емкости для принятия решений по масштабированию
• Возможности наблюдаемости в управлении API
• Возможности шлюза искусственного интеллекта в службе "Управление API"