Шлюз API в службе "Управление API Azure"
ОБЛАСТЬ ПРИМЕНЕНИЯ: все уровни Управление API
Эта статья содержит сведения о ролях и функциях компонента шлюза Управления API. В ней сравниваются шлюзы, которые можно развернуть.
Дополнительные сведения.
Общие сведения о сценариях, компонентах и концепциях Управления API см. в статье Что собой представляет Управление API Azure.
Дополнительные сведения о уровнях и функциях служб Управление API см. в следующих статье:
- уровни Управление API
- Сравнение уровней Управление API Azure на основе функций.
Роль шлюза
Шлюз Управления API (также называемый плоскость данных или среда выполнения) — это компонент службы, отвечающий за использование прокси-сервера для запросов API, применение политик и сбор данных телеметрии.
В частности, шлюз:
- выступает в качестве фасада серверных служб, принимая вызовы API и перенаправляя их в соответствующие серверные части;
- проверяет ключи API и другие учетные данные, такие как токены JWT и сертификаты, представленные запросами;
- принудительно применяет квоты использования и ограничения скорости;
- при необходимости преобразует запросы и ответы, указанные в инструкциях политики;
- если настроить, кэширует ответы, чтобы повысить задержку ответа и свести к минимуму нагрузку на серверные службы;
- создает журналы, метрики и трассировки для мониторинга, создания отчетов и устранения неполадок.
Примечание.
Все запросы к шлюзу Управление API, включая отклоненные конфигурацией политики, учитываются в соответствии с настроенными ограничениями скорости, квотами и ограничениями выставления счетов при применении на уровне служб.
Управляемые и локальные шлюзы
Управления API предлагает как управляемые, так и локальные шлюзы.
Управляемый шлюз — это компонент шлюза по умолчанию, развернутый в Azure для каждого экземпляра Управления API на каждом уровне служб. При использовании управляемого шлюза весь трафик API проходит через Azure независимо от того, где размещаются серверные части, реализующие API.
Примечание.
Из-за различий в базовой архитектуре служб шлюзы, предоставляемые на разных уровнях служб Управление API, имеют некоторые различия в возможностях. Дополнительные сведения см. в разделе Сравнение функций: управляемые и локальные шлюзы.
Локальное размещение — локальный шлюз является необязательной контейнерной версией управляемого шлюза по умолчанию, доступной на выборе уровней служб. Это полезно для гибридных и многооблачных сценариев, когда требуется запустить шлюзы из Azure в тех же средах, где размещаются серверные серверы API. Локальный шлюз позволяет клиентам с гибридной ИТ-инфраструктурой управлять API, размещенными локально и в облаках, из единой службы управления API в Azure.
Локальный шлюз упаковывается в виде контейнера Docker на базе Linux и обычно развертывается в Kubernetes, включая Службу Azure Kubernetes и Kubernetes с поддержкой Azure Arc.
Каждый локальный шлюз связан с ресурсом шлюза в облачном экземпляре Управления API, из которого он получает обновления конфигурации и сообщает о состоянии.
Внимание
Поддержка azure Управление API локального шлюза версии 0 и версии 1 образов контейнеров заканчивается 1 октября 2023 г. вместе с соответствующим API конфигурации версии 1. Используйте наше руководство по миграции для использования локального шлюза версии 2.0.0 или более поздней версии с API конфигурации версии 2. Дополнительные сведения см. в нашей документации по нерекомендуемым
Сравнение функций: управляемые и локальные шлюзы
Следующие таблицы сравнивают функции, доступные в следующих шлюзах Управление API:
- Классический — управляемый шлюз, доступный на уровнях служб "Разработчик", "Базовый", "Стандартный" и "Премиум" (прежнее название — выделенные уровни).
- Версия 2 — управляемый шлюз, доступный на уровнях "Базовый" версии 2 и "Стандартный" версии 2
- Потребление — управляемый шлюз, доступный на уровне потребления
- Локальное размещение — необязательный локальный шлюз, доступный на выборе уровней служб
Примечание.
- Некоторые функции управляемых и локальных шлюзов поддерживаются только на определенных уровнях служб или в определенных средах развертывания для локальных шлюзов.
- Для текущих поддерживаемых функций локального шлюза убедитесь, что вы обновили до последней основной версии образа контейнера локального шлюза.
- См. также ограничения локального шлюза.
Инфраструктура
| Поддерживаемые компоненты | Классическое | V2 | Потребление | Самостоятельное размещение |
|---|---|---|---|---|
| Личные домены | ✔️ | ✔️ | ✔️ | ✔️ |
| Встроенный кэш | ✔️ | ✔️ | ❌ | ❌ |
| Внешний кэш, совместимый с Redis | ✔️ | ✔️ | ✔️ | ✔️ |
| Внедрение виртуальной сети | Разработчик, Премиум | ❌ | ❌ | ✔️1,2 |
| Входящие частные конечные точки | Developer, Basic, Standard, Premium | ❌ | ❌ | ❌ |
| Интеграция исходящей виртуальной сети | ❌ | Стандартный, версия 2 | ❌ | ❌ |
| Зоны доступности | Premium | ❌ | ❌ | ✔️1 |
| Развертывание в нескольких регионах | Premium | ❌ | ❌ | ✔️1 |
| Корневые сертификаты ЦС для проверки сертификатов | ✔️ | ✔️ | ❌ | ✔️3 |
| Корневые сертификаты ЦС для проверки сертификатов | ✔️ | ✔️ | ❌ | ✔️3 |
| Сертификаты управляемого домена | Developer, Basic, Standard, Premium | ❌ | ✔️ | ❌ |
| Параметры TLS | ✔️ | ✔️ | ✔️ | ✔️ |
| HTTP/2 (клиент — шлюз) | ✔️4 | ✔️4 | ❌ | ✔️ |
| HTTP/2 (шлюз — серверная часть) | ❌ | ❌ | ❌ | ✔️ |
| Обнаружение угроз API с помощью Defender для API | ✔️ | ✔️ | ❌ | ❌ |
1 Зависит от способа развертывания шлюза, но за него отвечает клиент.
2 Подключение конечная точка конфигурации локального шлюза версии 2 требует разрешения DNS имени узла конечной точки.
3корневого сертификата ЦС для локального шлюза управляются отдельно для каждого шлюза.
Необходимо включить протокол 4 клиента.
Интерфейсы API серверной части
| Поддерживаемые компоненты | Классическое | V2 | Потребление | Самостоятельное размещение |
|---|---|---|---|---|
| Спецификация OpenAPI | ✔️ | ✔️ | ✔️ | ✔️ |
| Спецификация WSDL | ✔️ | ✔️ | ✔️ | ✔️ |
| Спецификация WADL | ✔️ | ✔️ | ✔️ | ✔️ |
| Приложение логики | ✔️ | ✔️ | ✔️ | ✔️ |
| Служба приложений | ✔️ | ✔️ | ✔️ | ✔️ |
| Приложение-функция | ✔️ | ✔️ | ✔️ | ✔️ |
| Приложение-контейнер | ✔️ | ✔️ | ✔️ | ✔️ |
| Service Fabric | Разработчик, Премиум | ❌ | ❌ | ❌ |
| Сквозная передача GraphQL | ✔️ | ✔️ | ✔️ | ✔️ |
| Синтетический GraphQL | ✔️ | ✔️ | ✔️1 | ✔️1 |
| Сквозная передача WebSocket | ✔️ | ✔️ | ❌ | ✔️ |
| Сквозная gRPC (предварительная версия) | ❌ | ❌ | ❌ | ✔️ |
| OData (предварительная версия) | ✔️ | ✔️ | ✔️ | ✔️ |
| Сквозная передача GraphQL | ✔️ | ✔️ | ✔️ | ✔️ |
| Azure OpenAI | ✔️ | ✔️ | ✔️ | ✔️ |
| Средство разбиения цепи в серверной части (предварительная версия) | ✔️ | ✔️ | ❌ | ✔️ |
| Серверный пул с балансировкой нагрузки (предварительная версия) | ✔️ | ✔️ | ✔️ | ✔️ |
1 Подписки GraphQL (предварительная версия) не поддерживаются.
Политики
Управляемые и локальные шлюзы поддерживают все доступные политики в определениях политик с приведенными ниже исключениями.
| Поддерживаемые компоненты | Классическое | V2 | Потребление | Локальноеразмещение 1 |
|---|---|---|---|---|
| Интеграция Dapr | ❌ | ❌ | ❌ | ✔️ |
| Сопоставители GraphQL и проверка GraphQL | ✔️ | ✔️ | ✔️ | ❌ |
| Получение контекста авторизации | ✔️ | ✔️ | ✔️ | ❌ |
| Квота и ограничение скорости | ✔️ | ✔️2 | ✔️3 | ✔️4 |
1 Настроенные политики, которые не поддерживаются локальным шлюзом, пропускаются во время выполнения политики.
2 Квота по политике ключей недоступна на уровнях версии 2.
2 Ограничение скорости по ключу и квоте по политикам ключей недоступно на уровне потребления.
3 Количество ограничений скорости в локальном шлюзе можно настроить для синхронизации локально (среди экземпляров шлюза между узлами кластера), например с помощью развертывания диаграмм Helm для Kubernetes или использования шаблонов развертывания портал Azure. Однако количество ограничений скорости не синхронизируется с другими ресурсами шлюза, настроенными в экземпляре Управление API, включая управляемый шлюз в облаке. Подробнее
Наблюдение
Дополнительные сведения о параметрах мониторинга см. в статье Наблюдаемость в Управлении API Azure.
| Поддерживаемые компоненты | Классическое | V2 | Потребление | Самостоятельное размещение |
|---|---|---|---|---|
| Аналитика API | ✔️ | ✔️1 | ❌ | ❌ |
| Application Insights | ✔️ | ✔️ | ✔️ | ✔️ |
| Ведение журнала через Центры событий | ✔️ | ✔️ | ✔️ | ✔️ |
| Метрики в Azure Monitor | ✔️ | ✔️ | ✔️ | ✔️ |
| Сборщик OpenTelemetry | ❌ | ❌ | ❌ | ✔️ |
| Запрос журналов в Azure Monitor и Log Analytics | ✔️ | ✔️ | ❌ | ❌2 |
| Локальные метрики и журналы | ❌ | ❌ | ❌ | ✔️ |
| Трассировка запросов | ✔️ | ❌3 | ✔️ | ✔️ |
1 Уровни версии 2 поддерживают аналитику на основе Azure Monitor.
2 Локальный шлюз в настоящее время не отправляет журналы ресурсов (журналы диагностики) в Azure Monitor. При желании можно отправлять метрики в Azure Monitor или настраивать и сохранять журналы локально, где развернут локальный шлюз.
3 Трассировка в настоящее время недоступна на уровнях версии 2.
Проверка подлинности и авторизация
Управляемые и локальные шлюзы поддерживают все доступные параметры проверки подлинности и авторизации API со следующими исключениями.
| Поддерживаемые компоненты | Классическое | V2 | Потребление | Самостоятельное размещение |
|---|---|---|---|---|
| Диспетчер учетных данных | ✔️ | ✔️ | ✔️ | ❌ |
Пропускная способность и масштабирование шлюза
Внимание
Пропускная способность зависит от количества и скорости одновременных подключений клиентов, типа и количества настроенных политик, размеров полезных данных, производительности API серверной части и других факторов. Пропускная способность локального шлюза также зависит от вычислительной емкости (ЦП и памяти) узла, на котором он выполняется. Выполняйте нагрузочное тестирование шлюза с помощью ожидаемых условий производства, чтобы точно определить ожидаемую пропускную способность.
Управляемый шлюз
Сведения о предполагаемой максимальной пропускной способности шлюза на уровнях служб Управления API приведены в статье Цены на Управление API.
Внимание
Данные о пропускной способности представлены только для информации. На них не следует полагаться при планировании емкости и бюджета. Дополнительные сведения см. в статье Цены на Управление API.
Классические уровни
- Емкость шлюза можно масштабировать путем добавления и удаления единиц масштабирования или обновления уровня служб. (Масштабирование недоступно на уровне "Разработка".)
- В уровнях "Базовый", "Стандартный" и "Премиум" при необходимости настройте автомасштабирование Azure Monitor.
- На уровне "Премиум" при необходимости добавьте и распределите емкость шлюза между несколькими регионами.
Уровни версии 2
- Емкость шлюза можно масштабировать путем добавления и удаления единиц масштабирования или обновления уровня служб.
Уровень "Потребление"
- Экземпляры службы "Управление API" на уровне "Потребление" масштабируется автоматически в соответствии с объемом трафика.
Независимый шлюз
- В таких средах, как Kubernetes, добавьте несколько реплик шлюза для обработки ожидаемого использования.
- При необходимости настройте автоматическое масштабирование в соответствии с требованиями трафика.
Связанный контент
- Дополнительные сведения о Управление API в гибридном и многооблачном мире
- Дополнительные сведения об использовании метрики емкости для принятия решений по масштабированию.
- Узнать больше о возможностях наблюдаемости службы "Управление API"