4、容量基线定义
容量基线（Capacity Baseline）是指在正常业务负载下，集群或服务所消耗资源与承载流量的稳定参考值。它并非静态阈值，而是通过持续观测形成的动态参考坐标系，用于判断系统是否处于健康运行区间。
4.1 容量基线的概念
容量基线是集群在稳定运行状态下，各项资源指标与业务指标之间的对应关系集合。它回答了三个核心问题：
- 当前负载下需要多少资源——CPU、内存、网络等物理资源消耗量
- 资源与吞吐量的换算关系——每增加 1000 QPS 需要扩容多少核 CPU
- 性能拐点在哪里——超过哪个负载阈值后延迟会急剧恶化
容量基线不是一次性的压测结果，而是基于生产环境长期数据拟合出的经验模型。它随业务迭代、代码变更、基础设施调整而持续演进。
关键认知：容量基线 = 正常负载下的资源消耗快照 + 负载与资源的换算系数 + 性能拐点标记。三者缺一不可。
4.2 为什么需要容量基线
在集群升级场景中，没有容量基线的灰度迁移等同于盲飞。具体原因体现在以下四个维度：
| 维度 | 无基线的风险 | 有基线的收益 |
|---|---|---|
| 容量规划 | 升级后资源不足导致 OOM 或限流 | 提前预判新版本资源需求，预留 buffer |
| 异常检测 | 无法区分是升级导致还是业务波动 | 偏离基线即告警，快速定位回归 |
| 回滚决策 | 凭经验判断，容易误判或延迟 | 指标超基线阈值自动触发回滚 |
| 容量验证 | 升级后需要重新压测，周期长 | 灰度流量与基线对比，实时验证 |
常见误区：容量基线不等于监控告警阈值。告警阈值是容忍边界，容量基线是正常区间。两者配合使用：基线用于趋势分析，阈值用于紧急响应。
4.3 容量基线的关键指标
容量基线由四个核心指标构成，它们从不同维度描述系统的负载能力与资源效率。以下逐一说明每个指标的定义、采集方式及在升级场景中的用途。
4.3.1 QPS（每秒查询数）
QPS 是业务负载的直接度量，代表系统每秒处理的请求数量。它是容量基线的入口指标，其他资源消耗指标通常与 QPS 呈正相关关系。
- 采集方式：网关层或应用层埋点，按 1 分钟粒度聚合
- 基线用途：确定当前集群承载的峰值 QPS 与均值 QPS，作为灰度迁移的流量配比依据
- 升级关注点：新版本 QPS 处理能力是否下降，同等流量下是否出现请求堆积
4.3.2 CPU 使用率
CPU 使用率反映计算资源的消耗程度。在容器化环境中，通常以容器级别的 CPU 使用率（占 request 的比例）为基准。
- 采集方式：cgroup 统计，Prometheus node_exporter 或 cAdvisor 采集
- 基线用途：建立 QPS 与 CPU 的换算模型，例如“每 1000 QPS 消耗 0.5 核 CPU”
- 升级关注点：新版本是否存在 CPU 效率退化，同等 QPS 下 CPU 使用率是否显著升高
4.3.3 内存使用量
内存使用量包括堆内与堆外内存、缓存、连接池等。内存泄漏是升级回滚的常见原因，基线数据能帮助快速识别异常增长。
- 采集方式：容器内存 usage_bytes，JVM 通过 JMX 暴露堆内存/非堆内存
- 基线用途：确定正常负载下的内存水位，以及 GC 频率与内存回收效率
- 升级关注点：新版本内存占用是否持续增长而不回落，GC 停顿时间是否变长
4.3.4 P99 延迟
P99 延迟代表 99% 的请求在多少毫秒内完成，是用户体验的关键指标。它比平均延迟更能反映尾部延迟问题。
- 采集方式：应用层通过 Micrometer / OpenTelemetry 记录请求耗时直方图
- 基线用途：定义正常负载下的延迟分布，识别性能退化或资源争抢
- 升级关注点：新版本是否引入额外的锁竞争、网络开销或序列化耗时
实践建议：在灰度迁移期间，将新版本 Pod 的 P99 延迟与基线做实时对比。若 P99 延迟超过基线 1.5 倍且持续 3 个采集周期，应自动暂停灰度并触发告警。
4.4 容量基线指标关系图
下图展示了四个关键指标之间的关联关系，以及它们在容量基线模型中的位置：
4.5 基线数据采集与更新策略
容量基线不是一次性建立就永久有效的，它需要持续维护。以下是推荐的基线生命周期管理策略：
| 阶段 | 操作 | 周期 | 说明 |
|---|---|---|---|
| 初始建立 | 取过去 14 天生产数据的 P50/P90/P99 分位值 | 一次性 | 排除大促、故障、变更窗口等异常时段 |
| 日常更新 | 滑动窗口计算，每日凌晨更新基线 | 每日 | 保留最近 30 天的数据窗口，剔除异常点 |
| 重大变更后 | 升级完成后 48 小时重新校准基线 | 按需 | 新版本可能改变资源消耗模型，旧基线失效 |
| 定期审计 | 人工审核基线偏移趋势，调整模型参数 | 每月 | 业务增长或架构调整可能导致基线漂移 |
基线数据存储建议：将基线数据写入时序数据库（如 Prometheus 的 recording rules 或 Thanos 的 downsampling），并暴露为独立的 metric 供告警和 dashboard 使用。避免每次查询都实时计算，减少查询延迟。
4.6 灰度迁移中的基线对比流程
在集群升级的灰度迁移过程中，容量基线的核心作用是作为参考坐标系，实时判断新版本是否健康。下图展示了基线对比的完整流程：
阈值调优建议：初始阶段使用较宽松的阈值（如 P99 延迟偏差 50%），随着灰度比例增大逐步收紧。当灰度比例达到 50% 时，应将阈值收紧到 20%，确保全量切换前新版本已充分验证。