Федеративное управление API с рабочими пространствами

ОБЛАСТЬ ПРИМЕНЕНИЯ: Базовая версия 2 | Стандартная версия 2 | Премиум | Премиум версия 2

Эта статья предоставляет обзор рабочих пространств API Management и объясняет, как они позволяют децентрализованным командам разработчиков 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 Management используйте рабочие пространства для реализации федеративного управления API. Пространства работают, как "папки" внутри службы управления API.

  • Каждый рабочий пространство содержит API, продукты, подписки, именованные значения и связанные ресурсы. См. справочник REST API для управления API, чтобы получить полный список ресурсов и операций, поддерживаемых в рабочих пространствах.
  • Доступ команд к ресурсам в рабочем пространстве управляется с помощью управления доступом на основе ролей (RBAC) Azure с встроенными или пользовательскими ролями, которые могут быть назначены аккаунтам Microsoft Entra и охватываться рабочим пространством.
  • Каждая рабочая область связана с одним или несколькими шлюзами для маршрутизации трафика API в внутренние службы API в рабочей области. В зависимости от уровня служб и ваших требований рабочая область может использовать управляемый шлюз службы по умолчанию или один или несколько шлюзов рабочей области.
  • Команда платформы может применять политики, охватывающие API и продукты в рабочих областях, чтобы управлять средой выполнения API в организации. Встроенное определение политики Azure (API Management policies should inherit parent scope policies using <base/>) позволяет проверять или применять эти политики ко всем ресурсам рабочей области.
  • Команда платформы может реализовать централизованный интерфейс обнаружения API с помощью портала разработчика.
  • Каждая команда рабочей области может собирать и анализировать журналы ресурсов шлюза для мониторинга собственных API рабочей области, а команда платформы имеет федеративный доступ к журналам во всех рабочих областях в службе управления API, обеспечивая надзор, безопасность и соответствие в экосистеме API.

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

Note

  • Новое! Функция рабочих пространств теперь доступна в категориях Basic v2 и Standard v2, наряду с категориями Premium и Premium v2. Рабочие области на уровнях версии 2 могут быть связаны либо с управляемым шлюзом управления API по умолчанию, либо с отдельным ресурсом шлюза рабочих областей, обеспечивая гибкость в настройке и масштабировании рабочих областей. Сведения о стратегии поддержки уровней рабочих областей см. в записи блога.
  • Для получения информации о ценах см. цены на управление API.

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

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

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

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

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

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

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

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

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

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

Опция Доступность Преимущества Considerations
Управляемый шлюз по умолчанию Сейчас на уровнях v2 Дополнительная плата за ресурс шлюза не взимается; доступно во всех регионах, где доступен этот уровень обслуживания; рабочие области могут использовать встроенные возможности шлюза, недоступные в шлюзах рабочих областей, такие как мультирегиональные развертывания, пользовательские имена хостов или подключение через Private Link, если это поддерживается на данном уровне обслуживания. Меньшая изоляция; все рабочие области совместно используют емкость и конфигурацию шлюза
Шлюз рабочего пространства Basic v2, Standard v2, Premium, Premium v2 Строгая изоляция среды выполнения; независимое масштабирование, имя узла и сетевая конфигурация для каждого шлюза рабочей области Дополнительная стоимость; более длительное время развертывания; поддержка в меньшем количестве регионов

Управляемый шлюз по умолчанию

На уровнях версии 2 можно настроить рабочую область для маршрутизации трафика API через управляемый шлюз службы по умолчанию, помимо одного или нескольких отдельных ресурсов шлюза рабочих областей. Если рабочая область использует управляемый шлюз по умолчанию:

  • Трафик API направляется через имя узла по умолчанию службы (например, <service-name>.azure-api.net).
  • Рабочая область использует ресурсы и конфигурацию шлюза совместно с другими рабочими областями и API уровня службы.

Note

В настоящее время можно связать рабочую область с управляемым шлюзом по умолчанию только на уровнях служб версии 2 и с помощью рабочей области управления API — создание или обновление REST API.

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

Шлюз рабочей области — это автономный ресурс Azure (workspace gateway premium) с той же основной функциональностью, что и управляемый шлюз по умолчанию.

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

Ассоциирование рабочих пространств со шлюзом рабочего пространства

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

Note

Связывание нескольких рабочих областей с шлюзом рабочей области доступно только для шлюзов рабочих областей, созданных после 15 апреля 2025 г.

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

При выборе модели развертывания для рабочих областей следует учитывать надежность, безопасность и стоимость.

  • Назначьте рабочую область собственному выделенному шлюзу рабочих областей для критически важных рабочих нагрузок. Чтобы максимально повысить надежность и безопасность API, назначьте каждой критически важной рабочей области собственный шлюз, избегая общего использования с другими рабочими областями.
  • Балансируйте надежность, безопасность и затраты . Свяжите несколько рабочих областей с шлюзом рабочей области (или, если применимо, управляемый шлюз по умолчанию) для балансировки надежности, безопасности и затрат на некритичные рабочие нагрузки. Распределяйте рабочие области по крайней мере между двумя шлюзами, чтобы предотвратить проблемы, такие как исчерпание ресурсов или ошибки конфигурации, от влияния на все API в организации.
  • Используйте разные шлюзы для разных вариантов использования . Группирование рабочих областей в шлюзе рабочей области на основе вариантов использования или требований к сети. Например, можно различать внутренние и внешние API, назначив их отдельным шлюзам, каждый из которых имеет собственную конфигурацию сети.
  • Подготовьтесь к изоляции проблемных рабочих областей — используйте прокси-сервер, например Шлюз приложений Azure или Azure Front Door, перед шлюзами общих рабочих областей, чтобы упростить перенос рабочей области, вызывающей исчерпание ресурсов, на другой шлюз. Этот подход предотвращает влияние на другие рабочие области, использующие шлюз.

Note

  • Шлюз рабочей области должен находиться в том же регионе, что и основной регион Azure экземпляра API Management, и в той же подписке.
  • Все рабочие области, связанные с шлюзом рабочей области, должны находиться в одном экземпляре службы управления API.
  • С шлюзом рабочей области можно связать до 30 рабочих областей. Обратитесь в службу поддержки, чтобы увеличить этот предел.

Имя хоста шлюза рабочего пространства

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

В настоящее время шлюзы рабочих областей не поддерживают пользовательские имена узлов. Шлюз приложений Azure или Azure Front Door можно настроить, используя настраиваемое имя узла, перед шлюзом рабочей области.

Сетевая изоляция для шлюзов рабочих областей

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

Для получения подробной информации о требованиях, смотрите Network resource requirements for workspace gateways.

Note

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

Масштабирование мощности шлюзов рабочих областей

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

Региональная доступность шлюзов рабочих пространств

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

Ограничения рабочей области и шлюза рабочей области

Ограничения рабочих областей

  • Рабочая область не может быть связана с автономным шлюзом
  • API в рабочих пространствах не защищены Defender для API.
  • Рабочие области не поддерживают диспетчер учётных данных
  • Рабочие области поддерживают только внутренний кэш; внешний кэш не поддерживается
  • Рабочие области не поддерживают синтетические API GraphQL
  • Рабочие области не поддерживают создание API непосредственно из ресурсов Azure, таких как Служба Azure OpenAI, App Service, Function Apps и т. д., в портале Azure
  • Рабочие области не поддерживают серверы MCP
  • Метрики запросов нельзя разделить по рабочим пространствам в Azure Monitor; все метрики рабочих пространств агрегируются на уровне службы.
  • Рабочие области не поддерживают сертификаты центра сертификации
  • Рабочие области не поддерживают управляемые удостоверения, включая связанные с ними функции, такие как хранение секретов в Azure Key Vault и использование политики authentication-managed-identity

Ограничения шлюза рабочей области

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

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

Наследование глобальной политики в шлюзах рабочих областей

Рабочие шлюзы выполняют полную цепочку политик, включая глобальную политику уровня сервиса (global.policy.xml). Это означает, что все политики, определенные в глобальной области, оцениваются и выполняются для вызовов API, обрабатываемых шлюзами рабочих областей, так же, как и для шлюза по умолчанию. Такое поведение предусмотрено разработкой и соответствует модели вычисления политик в API Management, в которой политики применяются иерархически в следующих областях: глобальная (служба) > рабочая область > продукт > API > операция.

Рекомендации по глобальным политикам с шлюзами для рабочих пространств

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

  • Если требуется разное поведение для каждого шлюза, используйте политику choose с context.Deployment.Gateway.Id, чтобы условно выполнять политики в зависимости от того, какой шлюз обрабатывает запрос.

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

Роли управления доступом на основе ролей (RBAC) для рабочих пространств

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

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

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

Note

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

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

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

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

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

    Important

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

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

    Note

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

Перейдите из рабочих пространств предварительного просмотра

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

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

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

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

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

  • Last updated on