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

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

ОТНОСИТСЯ К: Premium

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

Примечание

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

Имя хоста шлюза

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

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

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

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

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

Примечание

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

Масштабируемая емкость

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

Региональная доступность

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

    Важно

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

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

    Примечание

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

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

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

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

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

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

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