包含工作区的联合 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 运行时，提高了可靠性、复原能力和安全性

工作区如何启用联合 API 管理

在 Azure API 管理中，使用工作区可实现联合 API 管理。 工作区在 API Management 服务中的功能类似于“文件夹”：

• 每个工作区都包含 API、产品、订阅、命名值和相关资源。 有关工作区中支持的资源和操作的完整列表，请参阅 API Management REST API 参考。
• 团队对工作区内资源的访问是通过 Azure 的基于角色的访问控制 (RBAC) 进行管理的，其中内置或自定义角色可分配给 Microsoft Entra 帐户并限定于工作区范围内。
• 每个工作区都与一个或多个工作区网关相关联，该网关用于将 API 流量路由到工作区中 API 的后端服务。
• 平台团队可以对工作区中的 API 应用 API 策略，通过查看所有工作区的日志来监视平台，并通过开发人员门户实现集中式 API 发现体验。

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

示例方案概述

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

下面是用于创建和使用工作区的示例工作流。

1. 管理 API 管理实例的中心 API 平台团队会创建一个工作区，并使用 RBAC 角色向工作区协作者分配权限，例如在工作区中创建或读取资源的权限。 还会为工作区创建工作区范围的 API 网关。

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

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

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

工作区网关

每个工作区都与一个或多个工作区网关相关联，以启用在工作区内管理的 API 的运行时。 工作区网关是一个独立的 Azure 资源，其核心功能与 API Management 服务中内置的网关相同。

工作区网关独立于 API Management 服务进行管理，并且彼此独立。 它们支持对工作区或用例之间的运行时进行隔离，提高了 API 的可靠性、复原能力和安全性，并使运行时问题能够归因于各个工作区。

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

网关主机名

工作区到工作区网关的每个关联都会为该工作区中管理的 API 创建一个唯一的主机名。 默认主机名遵循模式 <workspace-name>-<hash>.gateway.<region>.azure-api.net。 目前，工作区网关不支持自定义主机名。

网络隔离

还可以选择在专用虚拟网络中配置工作区网关，以隔离入站和/或出站流量。 如果配置，则该工作区网关必须使用虚拟网络中的专用子网。

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

扩展容量

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

区域可用性

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

网关约束

工作区网关目前存在以下约束：

• 工作区网关必须与 API 管理实例的主要 Azure 区域位于同一区域，并在同一订阅中。
• 工作区不能与自承载网关相关联
• 工作区网关不支持入站专用终结点
• 无法为工作区网关中的 API 分配自定义主机名
• Defender for API 未涵盖工作区中的 API
• 工作区网关不支持 API Management 服务的凭据管理器
• 工作区网关仅支持内部缓存；不支持外部缓存
• 工作区网关不支持合成 GraphQL API 和 WebSocket API
• 工作区网关不支持从 Azure 资源（例如 Azure OpenAI 服务、应用服务、函数应用等）直接创建 API
• 在 Azure Monitor 中不能按工作区拆分请求指标；所有工作区指标都在服务级别聚合
• Azure Monitor 日志在服务级别聚合；工作区级日志不可用
• 工作区网关不支持 CA 证书
• 工作区网关不支持自动缩放
• 工作区网关不支持托管标识及相关功能，例如在 Azure Key Vault 中存储机密和使用 authentication-managed-identity 策略

适用于工作区的 RBAC 角色

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

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

工作区和其他 API 管理功能

工作区被设计为自包含的，可以最大限度地隔离管理访问和 API 运行时。 有几个例外可以确保更高的工作效率，并实现平台级治理、可观察性、可重用性和 API 发现。

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

  出于安全原因，无法从工作区级别策略引用服务级别资源（例如命名值）或按资源名称引用，例如 set-backend-service 策略中的 backend-id。

  重要

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

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

  注意

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

从预览版工作区迁移

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

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

删除工作区

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

相关内容

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