包含工作区的联合 API 管理

适用于：基本 v2 | 标准 v2 | 高级 | 高级 v2

本文概述了 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 Management 服务中的功能类似于“文件夹”：

• 每个工作区都包含 API、产品、订阅、命名值和相关资源。 有关工作区中支持的资源和操作的完整列表，请参阅 API Management REST API 参考。
• 团队对工作区内资源的访问是通过 Azure 的基于角色的访问控制 (RBAC) 进行管理的，其中内置或自定义角色可分配给 Microsoft Entra 帐户并限定于工作区范围内。
• 每个工作区都与一个或多个网关相关联，用于将 API 流量路由到工作区中 API 的后端服务。 根据服务层级和要求，工作区可以使用服务的默认托管网关或一个或多个 工作区网关。
• 平台团队可在工作区中应用覆盖 API 和产品的策略，从而对整个组织的 API 运行时进行管理。 借助内置的 Azure Policy 定义 (API Management policies should inherit parent scope policies using <base/>)，可以审核或强制要求这些策略应用于所有工作区资源。
• 平台团队可以使用开发人员门户实现集中式 API 发现体验。
• 每个工作区团队都可以收集和分析网关资源日志来监视自己的工作区 API，而平台团队可联合访问 API 管理服务中所有工作区中的日志，从而在整个 API 生态系统中提供监督、安全性和合规性。

虽然工作区是独立于 API Management 服务和其他工作区进行管理的，但按照设计，它们可以引用一些精选的服务级资源。 请参阅下文中的工作区和其他 API Management 功能。

示例方案概述

使用Azure API 管理管理 API 的组织可能有多个开发团队来开发、定义、维护和产品化不同的 API 集。 通过使用工作区，这些团队可以使用 API 管理来管理、访问和保护其 API，独立于管理服务基础结构。

以下工作流显示了用于创建和使用工作区的示例过程。

1. 一个中心 API 平台团队，用于管理 API 管理实例创建工作区，并使用 RBAC 角色为工作区协作者分配权限。 例如，分配在工作区中创建或读取资源的权限。 团队创建或关联 API 网关与工作区以路由 API 流量。

2. 中央 API 平台团队使用 DevOps 工具为该工作区中的 API 创建 DevOps 管道。

3. 工作区成员在工作区中开发、发布、产品化和维护 API。

4. 中央 API 平台团队管理服务的基础结构，例如监视、复原能力和所有 API 策略的强制实施。

工作区网关

每个工作区都配置了一个或多个网关，以便在运行时支持该工作区内管理的 API。 根据服务层级和要求，可以使用服务 的默认托管网关 和/或一个或多个 工作区网关 （单独的网关资源）。

默认托管网关

在 v2 层级中，您可以配置工作区，使其通过服务的默认托管网关路由 API 流量，此外还可以配置一个或多个独立的工作区网关资源。 当工作区使用默认托管网关时：

• API 流量通过服务的默认主机名路由（例如 <service-name>.azure-api.net）。
• 工作区与其他工作区和服务级别 API 共享网关的容量和配置。

工作区网关

工作区网关是与默认托管网关相同的核心功能的独立Azure资源（workspace gateway premium）。

您可以独立于 API 管理服务以及彼此之间管理工作区网关。 它们允许在工作区或用例之间隔离运行时，从而提高 API 可靠性、复原能力和安全性。 它们还使运行时问题归因于工作区。

• 有关工作区网关的成本的信息，请参阅 API Management 定价。
• 有关 API Management 网关的详细比较，请参阅 API Management 网关概述。

将工作区与工作区网关相关联

根据组织的需求，可以将一个或多个工作区与工作区网关相关联。

• 工作区网关具有某些配置，例如虚拟网络、规模和主机名，以及分配给它的计算资源，包括 CPU、内存和网络资源。
• 部署在网关上的所有工作区共享配置和计算资源。
• API 或异常流量中的 Bug 可能会导致这些资源耗尽，这会影响该网关上的所有工作区。 换句话说，在网关上部署的工作区越多，一个工作区中的 API 遇到另一个工作区中 API 产生的可靠性问题的风险就越高。
• 使用 内置指标 监视工作区网关在 CPU 和内存利用率方面的性能。

为工作区选择部署模型时，请考虑可靠性、安全性和成本。

• 为任务关键型工作负荷将工作区分配到自己的专用工作区网关 - 若要最大程度地提高 API 可靠性和安全性，请将每个任务关键型工作区分配到其自己的网关，避免与其他工作区共享。
• 平衡可靠性、安全性和成本 - 将多个工作区与工作区网关（如果适用）相关联，以平衡非关键工作负荷的可靠性、安全性和成本。 在至少两个网关之间分配工作区，以帮助防止问题（例如资源耗尽或配置错误）影响组织内的所有 API。
• 对不同的用例使用不同的网关 - 根据用例或网络要求对工作区网关上的工作区进行分组。 例如，可以通过将它们分配到单独的网关来区分内部和外部 API，每个 API 都有其自己的网络配置。
• 准备隔离有问题的工作区 - 在共享工作区网关前使用代理（如Azure 应用程序网关或Azure Front Door），以简化将导致资源耗尽的工作区移到其他网关。 此方法可防止对共享网关的其他工作区造成影响。

工作区网关主机名

每个工作区网关都为关联工作区中管理的 API 提供唯一的主机名。 默认主机名遵循模式 <gateway-name>-<hash>.gateway.<region>.azure-api.net。 使用网关主机名将 API 请求路由到工作区的 API。

目前，工作区网关不支持自定义主机名。 可以在工作区网关前使用自定义主机名配置 Azure 应用程序网关或 Azure Front Door。

工作区网关的网络隔离

可以选择在专用虚拟网络中配置工作区网关资源，以隔离入站和出站流量。 如果配置此隔离，工作区网关必须在虚拟网络中使用专用子网。

有关详细要求，请参阅工作区网关的网络资源要求。

扩展工作区网关容量

通过添加或移除扩展单元来管理工作区网关的容量，这类似于某些服务层级中可添加到 API 管理实例的单位。 工作区网关的成本基于所选单元数。

工作区网关的区域可用性

有关可使用工作区网关的区域的当前列表，请参阅 v2 层和工作区网关的可用性。

工作区和工作区网关约束

工作区约束

• 工作区不能与自承载网关相关联
• Defender for API 未涵盖工作区中的 API
• 工作区不支持凭据管理器
• 工作区仅支持内部缓存;不支持外部缓存
• 工作区不支持合成的 GraphQL API
• 工作区不支持直接从Azure资源（例如Azure OpenAI 服务、应用服务、函数应用等）在Azure门户中创建 API
• 工作区不支持 MCP 服务器
• 在 Azure Monitor 中不能按工作区拆分请求指标；所有工作区指标都在服务级别聚合
• 工作区不支持 CA 证书
• 工作区不支持托管身份，包括将密钥存储在 Azure 密钥保管库 中以及使用 authentication-managed-identity 策略等相关功能

工作区网关限制

以下约束适用于托管工作区网关资源。 在服务的默认托管网关上使用工作区时，它们不适用。

• 工作区网关不支持入站专用终结点
• 工作区网关不支持自定义主机名
• 工作区只能与位于与 API 管理资源相同区域和订阅中的工作区网关相关联

工作区网关中的全局策略继承

工作区网关执行完整的策略链，包括服务级别全局策略（global.policy.xml）。 这种行为意味着，在全局作用域中定义的任何策略，都会像在默认网关上一样，对由工作区网关处理的 API 调用进行评估和执行。 此行为的设计与 API 管理策略评估模型一致，可在以下 范围内分层应用策略：全局（服务） > 工作区 > 产品 > API > 操作。

工作区网关全局策略建议

• 查看全局策略，确保它仅包含旨在应用于所有网关的策略，包括工作区网关。

• 如果需要每个网关的不同行为，请使用 选择 策略， context.Deployment.Gateway.Id 根据处理请求的网关有条件地执行策略。

• 如果您在全局范围定义了 authentication-managed-identity，但不希望工作区范围的 API 访问该令牌，请将策略移至更窄的范围（例如产品或 API 级别），而非保留在全局策略中。

适用于工作区的 RBAC 角色

Azure RBAC 用于配置工作区协作者读取和编辑工作区中的实体的权限。 有关角色的列表，请参阅如何在 API 管理中使用基于角色的访问控制。

若要管理工作区中的 API 和其他资源，请为工作区成员分配角色（或通过自定义角色授予等效权限），并将这些角色的作用域限定为 API 管理服务和工作区。 服务范围角色支持从工作区级别资源引用特定的服务级别资源。 例如，将用户组织到工作区级别组中，以控制 API 和产品可见性。

如果工作区使用专用工作区网关，则还应为负责管理该网关的成员分配一个以工作区网关资源为作用域的角色。

工作区和其他 API 管理功能

工作区相互独立，以最大限度地隔离管理访问权限和 API 运行时环境。 为了确保提高工作效率并启用平台范围的治理、可观测性、可重用性和 API 发现，存在多个例外情况。

• 资源引用 - 工作区中的资源可以引用工作区中的其他资源和服务级别中的精选资源，例如用户、授权服务器或内置用户组。 它们不能从另一个工作区引用资源。

  出于安全原因，无法从工作区级别策略（例如命名值）中引用服务级别资源，也无法通过资源名称引用，例如在 backend-id 策略中使用 。

  Important

  API 管理服务中的所有资源（例如 API、产品、标记或订阅）都需要具有唯一的名称，即使它们位于不同的工作区中也是如此。 在同一工作区、其他工作区或服务级别中，不能存在类型相同且 Azure 资源名称相同的资源。

• 开发人员门户 - 工作区是一个管理概念，不会向开发人员门户使用者呈现，包括通过开发人员门户 UI 和基础 API。 可以将工作区中的 API 和产品发布到开发人员门户，就像服务级别上的 API 和产品一样。

  Note

  API Management 支持将服务级别上定义的授权服务器分配给工作区中的 API。

从预览版工作区迁移

如果你在 Azure API 管理中创建了预览版工作区并想要继续使用它们，请通过将工作区网关与每个工作区关联来将这些工作区迁移到正式版。

若要了解详细信息，并了解可能影响预览版工作区的其他更改，请参阅工作区中断性变更（2025 年 3 月）。

删除工作区

使用Azure门户界面删除工作区时，如果关联工作区，则还会删除其所有子资源（API、产品等）和专用工作区网关。 它不会删除 API Management 实例或其他工作区。

相关内容

• 创建工作区
• 工作区中断性变更 - 2024 年 6 月
• 工作区中断性变更 - 2025 年 3 月
• 限制 - API管理 工作区