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