4. 容量水位基础:定义与常见口径

容量水位(Capacity Watermark)是衡量服务实例资源占用与负载强度的量化指标,也是容量规划与 Error Budget 协同优化的核心输入。水位口径的选择直接决定扩容阈值、预算分配和告警灵敏度。

4.1 容量水位的定义

容量水位指服务实例在单位时间内对某一资源的实际使用量与该资源额定容量的比值,通常以百分比表示。其通用公式为:

水位(%)= 当前资源使用量 / 额定容量 × 100%

额定容量可以是物理上限(如 CPU 100%)、SLA 承诺上限(如 P99 延迟 ≤ 200ms 时的最大 QPS)或运维经验上限(如内存使用率 ≤ 80%)。

关键原则: 水位口径必须与服务的 瓶颈资源 对齐。对于计算密集型服务,CPU 是主口径;对于内存缓存型服务,内存是主口径;对于网关/代理类服务,连接数是主口径。

4.2 常见容量水位口径

下表列出 SRE 实践中四种最常用的水位口径及其适用场景、计算方式和典型阈值:

口径 单位 计算方式 适用场景 典型安全水位 典型高水位
CPU 水位 % (当前 CPU 使用率 / 100%)× 100% 计算密集型、通用微服务 ≤ 60% ≥ 80%
内存水位 % (已用内存 / 总内存)× 100% 缓存服务、大数据处理、Java 堆服务 ≤ 70% ≥ 85%
QPS 水位 % (当前 QPS / 压测最大 QPS)× 100% API 网关、在线交易、消息队列 ≤ 50% ≥ 75%
连接数水位 % (当前连接数 / 最大连接数)× 100% 数据库连接池、TCP 代理、WebSocket ≤ 60% ≥ 80%
实践建议: 不要只依赖单一水位口径。建议为每个服务定义 主口径 + 辅助口径 的组合。例如,在线交易服务以 QPS 水位为主,CPU 水位为辅;当 QPS 水位超过 75% 且 CPU 水位超过 60% 时,触发扩容。

4.3 水位口径与 Error Budget 的关联

容量水位是 Error Budget 消耗的 前置指标。当水位上升时,服务进入高负载区,延迟抖动和错误率上升的概率显著增加。下图展示了水位口径与 Error Budget 消耗之间的典型关系:

容量水位与 Error Budget 消耗关系图 容量水位与 Error Budget 消耗关系 容量水位阶梯 安全区 (0–50%) 警戒区 (50–75%) 危险区 (75–90%) 过载区 (>90%) Error Budget 消耗 低消耗 (<10%) 中等消耗 (10–30%) 高消耗 (30–60%) 预算耗尽 (>60%) 协同优化要点 • 水位进入警戒区时,应提前 审查 Error Budget 剩余量 • 水位与 Budget 同时恶化时, 优先扩容而非降级 水位口径选择建议 • 主口径:与瓶颈资源强相关 • 辅助口径:用于交叉验证

4.4 多口径协同水位模型

在实际生产环境中,单一口径无法完整描述服务的容量状态。推荐使用 多口径加权水位 模型,将多个维度的水位按权重合并为一个综合水位指标:

综合水位 = w₁ × CPU水位 + w₂ × 内存水位 + w₃ × QPS水位 + w₄ × 连接数水位

其中:w₁ + w₂ + w₃ + w₄ = 1

权重分配应根据服务的 资源瓶颈特征 动态调整。例如:

  • 计算密集型服务:w₁=0.6, w₂=0.2, w₃=0.15, w₄=0.05
  • 内存缓存型服务:w₁=0.15, w₂=0.6, w₃=0.15, w₄=0.1
  • API 网关服务:w₁=0.2, w₂=0.1, w₃=0.5, w₄=0.2
避坑提示: 不要将综合水位直接用于自动扩缩容决策。综合水位更适合 趋势监控和容量报告,而自动扩缩容应基于单一主口径 + 辅助口径的 与/或 条件触发,避免权重漂移导致误判。

4.5 水位口径的校准与更新

容量水位口径不是一成不变的。随着服务架构演进、流量模型变化和硬件升级,需要定期校准:

  1. 压测校准:每季度执行全链路压测,重新标定各口径的额定容量上限。
  2. 故障复盘校准:每次容量相关故障后,复盘水位阈值是否合理,是否出现“水位未超标但服务已过载”的情况。
  3. 业务峰值校准:大促或活动结束后,对比实际峰值水位与预期水位,调整权重和阈值。
  4. 硬件变更校准:实例规格变更(如升配 CPU、扩内存)后,立即更新额定容量基线。

下表总结了四种口径的校准频率和触发条件:

口径 校准频率 触发重新校准的条件
CPU 水位 每月 CPU 型号变更、内核参数调整、业务逻辑重构
内存水位 每月 JVM 参数调整、缓存策略变更、内存泄漏修复
QPS 水位 每季度 接口协议变更、限流策略调整、压测结果更新
连接数水位 每季度 连接池配置变更、网络拓扑调整、客户端连接策略变化