Прочитать на английском

Поделиться через

Управление федеративными API с рабочими областями

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: Premium

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

Почему организации должны федеративно управлять API?

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

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

Федеративное управление API обеспечивает следующие возможности:

  • Централизованное управление API и наблюдаемость
  • Единый портал разработчика для эффективного обнаружения и подключения API
  • Разделенные административные разрешения между командами API, повышение производительности и безопасности
  • Разделение среды выполнения API между командами API, повышение надежности, устойчивости и безопасности

Включение федеративного управления API рабочими областями

В Azure Управление API используйте рабочие области для реализации федеративного управления API. Рабочие области, такие как "папки" в службе Управление API:

  • Каждая рабочая область содержит API, продукты, подписки, именованные значения и связанные ресурсы. Полный список ресурсов и операций, поддерживаемых в рабочих областях, см. в справочнике по REST API Управление API.
  • Доступ Teams к ресурсам в рабочей области управляется с помощью управления доступом на основе ролей Azure (RBAC) со встроенными или настраиваемыми ролями, которые можно назначить учетным записям Microsoft Entra и области для рабочей области.
  • Каждая рабочая область связана с одним или несколькими шлюзами рабочих областей для маршрутизации трафика API в внутренние службы API в рабочей области.
  • Команда платформы может применять политики API, охватывающие API в рабочих областях, отслеживать платформу, просматривая журналы для всех рабочих областей и реализуя централизованный интерфейс обнаружения API с помощью портала разработчика.

Концептуальная схема службы Управление API с рабочими областями.

Примечание

  • Последние функции рабочей области поддерживаются в Управление API REST API версии 2023-09-01-preview или более поздней версии.
  • Сведения о ценах см. в Управление API ценах.

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

Обзор сценария-примера

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

Ниже приведен пример рабочего процесса для создания и использования рабочей области.

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

  2. Центральная группа платформы API использует средства DevOps для создания конвейера DevOps для API в этой рабочей области.

  3. Участники рабочей области разрабатывают, публикуют, продуктизуют и поддерживают API в рабочей области.

  4. Центральная группа платформы API управляет инфраструктурой службы, например мониторингом, устойчивостью и применением политик всех API.

Шлюз рабочей области

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

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

  • Сведения о стоимости шлюзов рабочих областей см. в Управление API ценах.
  • Подробное сравнение шлюзов Управление API см. в Управление API обзоре шлюзов.

Примечание

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

Имя узла шлюза

Каждая связь рабочей области с шлюзом рабочей области создает уникальное имя узла для API, управляемых в этой рабочей области. Имена узлов по умолчанию соответствуют шаблону <workspace-name>-<hash>.gateway.<region>.azure-api.net. В настоящее время пользовательские имена узлов не поддерживаются для шлюзов рабочих областей.

Сетевая изоляция

При необходимости шлюз рабочей области можно настроить в частной виртуальной сети для изоляции входящего и /или исходящего трафика. При настройке шлюз рабочей области должен использовать выделенную подсеть в виртуальной сети.

Подробные требования см. в разделе "Требования к сетевым ресурсам" для шлюзов рабочих областей.

Примечание

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

Изменение масштаба емкости

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

Доступность в регионах

Текущий список регионов, где доступны шлюзы рабочих областей, см. в разделе "Доступность уровней 2" и шлюзов рабочих областей.

Ограничения шлюза

Следующие ограничения в настоящее время применяются к шлюзам рабочих областей:

  • Шлюз рабочей области должен находиться в том же регионе, что и основной регион Azure экземпляра Управление API и в той же подписке.
  • Рабочая область не может быть связана с локальным шлюзом
  • Шлюзы рабочих областей не поддерживают входящие частные конечные точки
  • API-интерфейсы в шлюзах рабочих областей не могут быть назначены пользовательскими именами узлов
  • API в рабочих областях не охватываются Api Defender для API
  • Шлюзы рабочих областей не поддерживают диспетчер учетных данных службы Управление API
  • Шлюзы рабочих областей поддерживают только внутренний кэш; внешний кэш не поддерживается
  • Шлюзы рабочих областей не поддерживают искусственные API GraphQL и API WebSocket
  • Шлюзы рабочих областей не поддерживают создание API непосредственно из ресурсов Azure, таких как Служба Azure OpenAI, Служба приложений, приложения-функции и т. д.
  • Метрики запросов не могут быть разделены по рабочей области в Azure Monitor; Все метрики рабочей области агрегируются на уровне обслуживания
  • Журналы Azure Monitor агрегируются на уровне обслуживания; Журналы уровня рабочей области недоступны
  • Шлюзы рабочих областей не поддерживают сертификаты ЦС
  • Шлюзы рабочих областей не поддерживают автомасштабирование
  • Шлюзы рабочих областей не поддерживают управляемые удостоверения, включая связанные функции, такие как хранение секретов в Azure Key Vault и использование authentication-managed-identity политики

Роли RBAC для рабочих областей

Azure RBAC используется для настройки разрешений участников совместной работы рабочей области для чтения и редактирования сущностей в рабочей области. Список ролей см. в разделе "Использование управления доступом на основе ролей" в Управление API.

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

Примечание

Чтобы упростить управление, настройте группы Microsoft Entra для назначения разрешений рабочей области нескольким пользователям.

Рабочие области и другие функции Управление API

Рабочие области предназначены для самостоятельного разделения административного доступа и среды выполнения API. Существует несколько исключений, позволяющих обеспечить более высокую производительность и включить управление на уровне платформы, наблюдаемость, возможность повторного использования и обнаружение API.

  • Ссылки на ресурсы. Ресурсы в рабочей области могут ссылаться на другие ресурсы в рабочей области и выбранные ресурсы на уровне обслуживания, такие как пользователи, серверы авторизации или встроенные группы пользователей. Они не могут ссылаться на ресурсы из другой рабочей области.

    По соображениям безопасности невозможно ссылаться на ресурсы уровня обслуживания из политик уровня рабочей области (например, именованных значений) или по именам ресурсов, например backend-id в политике set-backend-service .

    Важно!

    Все ресурсы в службе Управление API (например, API, продукты, теги или подписки) должны иметь уникальные имена, даже если они находятся в разных рабочих областях. Не может быть ресурсов одного типа и с тем же именем ресурса Azure в той же рабочей области, в других рабочих областях или на уровне обслуживания.

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

    Примечание

    Управление API поддерживает назначение серверов авторизации, определенных на уровне обслуживания API в рабочих областях.

Миграция из рабочих областей предварительной версии

Если вы создали рабочие области предварительной версии в Azure Управление API и хотите продолжить их использование, перенесите рабочие области в общедоступную версию, связав шлюз рабочей области с каждой рабочей областью.

Дополнительные сведения и сведения о других изменениях, которые могут повлиять на рабочие области предварительной версии, см. в статьях о критических изменениях рабочих областей (март 2025 г.).

Удаление рабочей области

При удалении рабочей области удаляются все дочерние ресурсы (API, продукты и т. д.) и связанный с ним шлюз, если вы удаляете рабочую область с помощью интерфейса портал Azure. Он не удаляет экземпляр Управление API или другие рабочие области.

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