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

ОБЛАСТЬ ПРИМЕНЕНИЯ: Премиум | Премиум версии 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, продукты, подписки, именованные значения и связанные ресурсы. Полный список ресурсов и операций, поддерживаемых в рабочих пространствах, см. ссылку на API управления REST.
  • Управляйте доступом команд к ресурсам внутри рабочего пространства через систему управления доступом на основе ролей (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, если это поддерживается уровнем службы Меньшая изоляция; все рабочие области совместно используют емкость и конфигурацию шлюза
Шлюз рабочего пространства Премиум, Премиум 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 и шлюзов рабочих областей".

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

Ограничения рабочего пространства

  • Нельзя связывать рабочее пространство с самостоятельным шлюзом.
  • Defender for API не покрывает API в рабочих пространствах.
  • Рабочие пространства не поддерживают менеджера по удостоверению.
  • Рабочие пространства поддерживают только внутренний кэш; внешний кэш они не поддерживают.
  • Рабочие пространства не поддерживают синтетические API GraphQL.
  • Нельзя создавать API напрямую из ресурсов Azure, таких как Служба Azure OpenAI, App Service или Function Apps в портале Azure.
  • Рабочие пространства не поддерживают MCP-серверы.
  • В Azure Monitor нельзя разделять метрики запроса по рабочим пространствам; все метрики workspace агрегируются на уровне сервиса.
  • Рабочие пространства не поддерживают сертификаты CA.
  • Рабочие пространства поддерживают использование управляемых идентичностей с использованием идентичности сервиса. Чтобы узнать больше, ознакомьтесь с нашими возможностями и вопросами безопасности.

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

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

  • Шлюзы рабочего пространства не поддерживают входящие частные конечные точки доступа.
  • Шлюзы Workspace не поддерживают пользовательские имена хостов.
  • Вы можете ассоциировать рабочие пространства только с шлюзами workspace, расположенными в том же регионе и подпиской, что и ресурс управления 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 или другие рабочие пространства.

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

  • Последнее обновление: