2. 容量规划基础概念
在利用 Prometheus 数据辅助网关升级之前，必须建立统一的容量规划语言。本节定义四个核心概念：容量规划、基线、容量与性能的区别以及关键术语。这些概念是后续所有基线对比和决策推导的基石。
2.1 什么是容量规划
容量规划（Capacity Planning）是预测未来资源需求并提前配置资源的过程，目标是确保系统在可接受的性能水平下处理预期负载，同时避免过度配置导致的成本浪费。
核心公式： 容量规划 = 需求预测 × 性能模型 × 成本约束
在网关升级场景中，容量规划回答三个问题：
- 当前网关能否承载未来 6-12 个月的流量峰值？
- 新网关需要多少 CPU、内存、网络带宽？
- 升级窗口内如何保证不触发容量过载？
2.2 基线（Baseline）的定义
基线是系统在正常稳态运行下各项资源指标的统计参考值。它不是单一数值，而是一个包含时间窗口、百分位和上下文标签的多维向量。
基线 vs 阈值： 基线描述“正常是什么样”，阈值定义“什么算异常”。基线是动态的，阈值通常是静态的。
在 Prometheus 语境下，基线通常由以下元素构成：
| 基线元素 | PromQL 示例 | 说明 |
|---|---|---|
| CPU 使用率 P50 | quantile(0.5, rate(node_cpu_seconds_total[5m])) |
典型负载下的 CPU 消耗 |
| 内存占用 P95 | quantile(0.95, process_resident_memory_bytes) |
内存压力峰值参考 |
| 请求延迟 P99 | histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[1m])) |
长尾延迟容忍上限 |
| 吞吐量日均值 | avg(rate(http_requests_total[24h])) |
日间业务量基准 |
2.3 容量与性能的区别
容量和性能经常被混用，但在容量规划中必须严格区分：
| 维度 | 容量（Capacity） | 性能（Performance） |
|---|---|---|
| 定义 | 系统能处理的最大负载量 | 系统处理负载时的响应速度 |
| 单位 | QPS、并发连接数、吞吐量 | 延迟（ms）、P99、TP99 |
| 关注点 | 能扛多少 | 有多快 |
| 瓶颈表现 | 请求被拒绝、连接超时 | 响应变慢、队列堆积 |
| 规划目标 | 预留足够资源应对峰值 | 优化代码和架构降低延迟 |
| Prometheus 指标 | rate(http_requests_total[5m]) |
histogram_quantile(0.99, ...) |
常见误区： 升级网关时只关注性能提升（延迟降低），却忽略了容量是否匹配。新网关可能延迟更低，但若 CPU 容量基线未对齐，高并发下仍会 OOM 或丢请求。
2.4 关键术语解释
以下术语在后续章节中高频出现，提前统一理解：
| 术语 | 英文 | 定义 | 在网关升级中的意义 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒请求数 | 网关吞吐量的核心指标 |
| P50 / P95 / P99 | Percentile | 第 50/95/99 百分位延迟 | 评估升级对长尾延迟的影响 |
| RPS | Requests Per Second | 与 QPS 同义，每秒请求数 | 容量规划中的负载单位 |
| 饱和度 | Saturation | 资源已使用量 / 总容量 | 判断网关是否接近瓶颈 |
| Headroom | Headroom / Buffer | 当前负载到容量上限的余量 | 决定升级窗口的安全边界 |
| 资源争用 | Resource Contention | 多个进程竞争同一资源 | 新网关可能引入新的争用点 |
| 线性扩展比 | Linear Scalability | 资源增加与吞吐量提升的比例 | 评估水平扩容的有效性 |
记忆口诀： “容量看上限，性能看速度，基线看常态，饱和度看余量。”
2.5 为什么这些概念对网关升级至关重要
网关升级不是简单的“换新版本”，而是一次容量与性能的再平衡。没有基线，你无法判断新网关是变好还是变差；没有容量规划，你无法确定新网关能否扛住明天的流量洪峰。
- 基线缺失 → 升级后出现性能回退，无法快速定位是配置问题还是容量不足。
- 容量与性能混淆 → 只优化了延迟，却忽略了 CPU 上限，导致高并发下 OOM。
- 术语不统一 → 开发、运维、业务方对“容量”的理解不同，决策效率低下。