Azure API 管理对 API 操作和其他实体等资源强制实施各种 限制。 本文介绍这些限制存在的原因，以及如何在这些约束内有效地使用该服务。
为何存在服务限制？
Azure API 管理在有限的物理基础结构上运行。 为了确保所有客户的服务可靠性能，该服务会基于以下标准施加经过校准的限制：
- Azure 平台容量和性能特征
- 服务层功能
- 典型的客户使用模式
资源限制是相互关联的并经过优化的，以防止任何单一方面中断整体服务性能。
服务限制更改 - 2026 年更新
从 2026 年 3 月开始，在接下来的几个月里，Azure API 管理会为所有层中的实例引入更新的资源限制。 下表显示了这些限制。
注释
除非另有说明，否则限制按服务实例进行。
在计算与 API 相关的资源（例如 API 操作和标签）的数量时，API Management 还包括 API 版本和修订。
| 实体/资源 | 消耗 | 开发人员 | 基本/ 基本 v2 |
标准 | 高级 |
|---|---|---|---|---|---|
| API 操作 | 3,000 | 3,000 | 10,000 | 50,000 | 75,000 |
| API 标记 | 1,500 | 1,500 | 1,500 | 2,500 | 15,000 |
| 命名值 | 5,000 | 5,000 | 5,000 | 10,000 | 18,000 |
| 日志记录器 | 100 | 100 | 100 | 200 | 400 |
| Products | 100 | 100 | 200 | 500 | 2,000 |
| 订阅 | 不适用 | 10,000 | 15,000 | 25,000 | 75,000 |
| 用户 | 不适用 | 20,000 | 20,000 | 50,000 | 75,000 |
| 每个工作区网关的工作区数 | 不适用 | 不适用 | 不适用 | 不适用 | 30 |
| 自托管网关 | 不适用 | 5 | 不适用 | 不适用 | 1001 |
1 仅适用于高级层。
有什么变化
- 对一组与服务容量和性能（例如 API作、标记、产品和订阅）直接相关的较小资源类型强制实施限制。
注释
可以随着时间的推移调整资源限制，以反映最新的服务功能。
现有经典级客户的限制策略
新限制生效后，可以继续使用预先存在的 API 管理资源，而不会中断。
- 在引入新限制时，当前使用量超过新限制的现有经典层服务将被豁免于新限制。 （v2 层中的实例已受到新的限制。
- 在新的限制生效时，祖父服务中的限制将设置为高于客户观察到的使用情况的 10%。
- 祖父按服务和服务层级应用。
- 其他现有服务和新服务在生效时受新限制的约束。
在限制内管理资源
如果达到资源限制，你可能会注意到影响，例如无法创建新资源或更新现有资源。 在某些服务操作中，还可能会遇到性能下降的问题。
以下是帮助你在这些情况下有效管理资源的准则。
改进资源管理
- 为未使用的资源实现常规清理过程。
- 有效地使用标记来标识可以合并或删除的资源。
- 查看 容量指标 以了解资源利用率和潜在瓶颈。
优化 API 和操作组织
计算 API 相关资源（如 API 操作和标记）时，API 管理还包括 API 版本和修订。 在接近这些资源的限制时，以下策略会有所帮助：
- 删除未使用的 API 版本或修订。
- 在适当情况下合并或删除操作。
- 战略性地使用 API 版本和修订。
评估服务层级
如果您经常达到资源限制或遇到容量问题，请评估当前的服务层级。 某些限制（例如 API操作的限制）因服务套餐而异。
- 请考虑添加组件或升级套餐的选项。
- 请考虑在当前层中部署其他 API 管理实例。
若要评估与这些选项相关的成本，请参阅 Azure API 管理定价。
增加额度指南
在某些情况下，可能需要增加服务限制。 在请求增加限制之前，请注意以下准则：
在请求提高限制之前，探索主动解决问题的策略。 请参阅上一部分 ：管理限制内的资源。
考虑限制增加对整体服务性能和稳定性的潜在影响。 增加限制可能会影响服务的容量，或增加某些服务作的延迟。
请求提高上限
产品团队仅考虑使用以下级别中适用于中等到大型生产工作负载的服务的客户请求提升限制。
- 标准
- 高级
限制增加请求会根据具体情况逐一评估，不能保证一定批准。 产品团队在考虑增加限制时会优先考虑 Premium 和 Premium v2 层的客户。
若要请求增加限制，请从 Azure 门户创建支持请求。 有关详细信息，请参阅 Azure 支持计划。