Azure API 管理实例的容量

容量是最重要的 Azure Monitor 指标，在是否扩展或升级 API 管理实例以容纳更多负载方面，它可以帮助做出明智的决策。 容量的构造比较复杂，并且会施加特定的行为。

本文介绍容量的定义及其行为。 其中介绍了如何在 Azure 门户中访问容量指标，并建议何时应考虑扩展或升级 API 管理实例。

先决条件

若要执行本文中的步骤，必须提供：

• 一个有效的 Azure 订阅。

  如果没有 Azure 订阅，可在开始前创建一个试用帐户。

• API 管理实例。 有关详细信息，请参阅创建 Azure API 管理实例。

可用性

什么是容量

容量是 API 管理实例中负载的指标。 它反映资源（CPU、内存）用量和网络队列长度。 CPU 和内存用量反映以下对象的资源消耗量：

• API 管理数据平面服务（如请求处理）可以包括转发请求或运行策略。
• API 管理的管理平面服务，例如通过 Azure 门户或 Azure 资源管理器应用的管理操作，或者来自开发人员门户的加载操作。
• 选定的操作系统进程，包括在新连接上造成 TLS 握手开销的进程。
• 平台更新，例如实例基础计算资源的 OS 更新。
• 部署的 API 数量（无论是否处于活动状态）都可能会消耗额外的容量。

总容量是 API 管理实例的每个单元中容量自有值的平均值。

虽然容量指标旨在显示 API 管理实例出现的问题，但是在某些情况下，问题不会反映在容量指标的更改中。

容量指标行为

由于这种构造，在现实中，容量可能受到多种可变因素的影响，例如：

• 连接模式（是根据请求创建新连接，还是重复使用现有连接）
• 请求和响应的大小
• 在每个 API 中配置的策略数，或发送请求的客户端数。

请求中的操作越复杂，容量消耗就越高。 例如，复杂转换策略消耗的 CPU 比简单的请求转发要高得多。 后端服务响应速度较慢也会增大消耗量。

容量还可能会出现间歇性的高峰或大于零，即使未处理任何请求。 之所以发生这种情况，是因为存在系统或平台特定的操作。在决定是否缩放实例时，不应考虑这些因素。

低容量指标并不一定意味着 API 管理实例没有遇到任何问题。

使用 Azure 门户检查容量

1. 在 Azure 门户中导航到自己的 API 管理实例。

2. 在左侧菜单中的“监视”下，选择“指标”。

3. 从可用指标中选择“容量”，并保留默认的“平均值”聚合。

   提示

   如果已将实例部署到多个位置，则始终应该查看每个位置的容量指标明细，以避免解释错误。

4. 若要按位置拆分指标，请在顶部部分选择“应用拆分”，然后选择“位置”。

5. 从该部分的顶部栏中选择所需的时间范围。

   可以设置指标警报，以便在发生意外的情况时收到通知。 例如，当 API 管理实例超出预期峰值容量有 20 分钟以上时收到通知。

   提示

   可以配置警报，以便在服务容量不足时知道这种状况；或者使用 Azure Monitor 自动缩放自动添加 Azure API 管理单元。 缩放操作可能需要大约 30 分钟，因此请相应地安排规则。
   只允许缩放主要位置。

使用容量做出缩放决策

在是否扩展 API 管理实例以容纳更多负载方面，容量指标可以帮助做出决策。 下面是一般注意事项：

• 查看长期趋势和平均值。
• 忽略往往与负载提高无关的突发高峰（请参阅容量指标行为部分中的说明）。
• 一般规则是，在容量值长时间（例如 30 分钟）超过 60% - 70% 时升级或扩展实例。 不同的值可能更适合服务或方案。
• 如果仅为实例配置了 1 个单元，则在容量值长时间超过 40% 时升级或扩展实例。 这项建议的依据是需要为基础服务平台中的来宾 OS 更新预留容量。

后续步骤

• 升级和缩放 Azure API 管理服务实例
• 自动缩放 Azure API 管理实例