4. 容量评估核心指标：QPS、连接数、内存、CPU、延迟、错误率
在 Service Mesh 数据面（通常指 Sidecar Proxy，如 Envoy）的容量评估中，仅关注单一指标（如 QPS）会导致严重的评估偏差。数据面作为请求路径上的“中间层”，其资源消耗与业务流量特征、连接模型、协议类型强相关。以下六个指标构成了容量评估的黄金指标体系，必须联合观测与建模。
4.1 指标全景与评估优先级
下表列出了六个核心指标的定义、评估维度及在升级场景中的优先级。建议按照“先容量后质量”的顺序进行评估：先确保 CPU/内存/连接数不超限，再验证 QPS/延迟/错误率是否达标。
| 指标 | 定义 | 评估维度 | 升级优先级 |
|---|---|---|---|
| QPS | 每秒处理的请求数（含 HTTP/gRPC/TCP） | 吞吐上限、线性扩展拐点 | 高 |
| 连接数 | Sidecar 与上下游建立的 TCP/UDS 连接总数 | 连接池耗尽、FD 泄漏 | 高 |
| 内存 | Sidecar 进程 RSS + 共享内存 | 连接数 × 连接内存 + 配置内存 | 高 |
| CPU | Sidecar 进程 CPU 使用率（核·秒） | TLS 卸载、7层路由、遥测 | 高 |
| 延迟 | Sidecar 引入的 P50/P99 额外延迟 | 线程模型、请求队列深度 | 中 |
| 错误率 | 5xx、连接超时、重置比例 | 限流、熔断、配置错误 | 中 |
4.2 核心指标关联模型
六个指标并非孤立存在，它们之间存在明确的因果与约束关系。下图展示了数据面容量评估的指标关联模型，帮助理解“为什么连接数上升会导致内存上涨，进而影响延迟和错误率”。
4.3 各指标深度解读与评估方法
4.3.1 QPS（每秒请求数）
QPS 是衡量数据面处理能力的首要指标。评估时需区分 业务 QPS（客户端视角）与 Sidecar QPS（代理视角）。在升级场景中，应关注新版本 Sidecar 的 QPS 上限是否低于旧版本，以及是否存在“吞吐拐点”。
- 评估方法： 使用 wrk2 / ghz / fortio 等工具，以 100 QPS 为步进逐步加压，记录 CPU 和延迟的突变点。
- 常见陷阱： 仅测 HTTP/1.1 而忽略 gRPC 长连接场景；未考虑 Header 大小对 QPS 的影响。
4.3.2 连接数
连接数是内存和文件描述符（FD）消耗的直接驱动因素。在微服务架构中，每个 Pod 的 Sidecar 需要与集群内所有可能调用的目标服务建立连接，连接数 = 出站连接 + 入站连接 + 控制面连接。
- 评估公式： 预估连接数 = 服务数 × 实例数 × 连接复用因子（通常 0.3~0.8）。
- 升级风险： 新版本 Sidecar 可能因连接池管理算法变更，导致连接数激增 2~3 倍，直接撑爆内存。
4.3.3 内存
Sidecar 的内存消耗主要由三部分组成：连接内存（每个连接约 15-50 KB）、配置内存（Listener/Cluster/Route 配置，约 10-100 MB）、运行时缓存（DNS 缓存、TLS Session 缓存）。
Mem_total ≈ 连接数 × 30KB + 配置大小 × 1.2 + 50MB（基础开销）升级前应通过
kubectl top pod 或 Prometheus 的 container_memory_working_set_bytes 采集基线。
4.3.4 CPU
CPU 消耗与 QPS 呈近似线性关系，但存在“TLS 卸载”和“遥测上报”两个非线性因素。升级后若启用新的遥测过滤器（如 AccessLog、Metadata Exchange），CPU 可能增加 20%~40%。
- 评估方法： 在预发环境以 80% 生产 QPS 压测，观察 CPU 使用率是否超过 70%（预留 30% 给突发流量）。
- 关键配置： worker_threads 数量（默认等于 CPU 核数）、连接池线程模型。
4.3.5 延迟
数据面引入的延迟增量通常应控制在 P99 < 5ms（对于 HTTP）和 P99 < 2ms（对于内部 gRPC）。延迟评估需区分“代理延迟”和“排队延迟”。
| 延迟类型 | 来源 | 升级影响 |
|---|---|---|
| 代理延迟 | 路由匹配、Header 处理、TLS 加解密 | 新版本路由引擎优化可能降低 0.5-1ms |
| 排队延迟 | Worker 线程满载、连接池等待 | 升级后若 CPU 上限降低，排队延迟会显著增加 |
4.3.6 错误率
错误率是容量评估的“一票否决”指标。升级过程中常见的错误率来源包括：连接超时（连接池耗尽）、503 无健康上游（端点发现延迟）、重置（协议不兼容）。
- 评估标准： 升级后错误率应 ≤ 升级前基线 + 0.1%。
- 监控维度： 按状态码（5xx vs 4xx）、按上游集群、按 Sidecar 版本分组。
4.4 指标联合评估流程
在实际升级评估中，建议按照以下流程对六个指标进行联合检查，避免单一指标达标而整体容量不足的情况。
• 只关注 CPU 和内存，忽略连接数上限导致 FD 耗尽。
• 使用短连接压测（如 HTTP/1.1 无 Keep-Alive）评估长连接场景（gRPC/HTTP/2）。
• 未考虑升级后遥测和日志采集带来的额外 CPU/内存开销（通常 10%~30%）。
4.5 指标采集与监控配置参考
以下 PromQL 查询语句可用于在生产环境采集上述六个指标的基线数据，建议在升级前 7 天持续记录。
# QPS（按 Pod 粒度）
sum(rate(envoy_cluster_upstream_rq_total{namespace="prod",pod=~"myapp-.*"}[5m])) by (pod)
# 连接数（活跃连接）
envoy_cluster_upstream_cx_active{namespace="prod",pod=~"myapp-.*"}
# 内存（Working Set）
container_memory_working_set_bytes{container="istio-proxy",namespace="prod",pod=~"myapp-.*"}
# CPU 使用率（核·秒）
rate(container_cpu_usage_seconds_total{container="istio-proxy",namespace="prod",pod=~"myapp-.*"}[5m])
# 延迟（P99）
histogram_quantile(0.99, sum(rate(envoy_cluster_upstream_rq_time_bucket{namespace="prod",pod=~"myapp-.*"}[5m])) by (le))
# 错误率（5xx 比例）
sum(rate(envoy_cluster_upstream_rq_total{namespace="prod",response_code_class="5",pod=~"myapp-.*"}[5m]))
/
sum(rate(envoy_cluster_upstream_rq_total{namespace="prod",pod=~"myapp-.*"}[5m]))