2. 容量度量指标：QPS、TPS、并发数、响应时间、资源利用率的采集与解读
容量规划的第一步是建立统一的度量体系。在 Multi-Cluster 环境中，由于集群间硬件差异、网络拓扑不同、中间件版本不一致，同一指标在不同集群的采集口径和解读方式可能产生偏差，进而导致容量评估失真。本章将系统定义五大核心指标，并给出标准化的采集与解读方法。
2.1 核心指标定义与业务映射
下表梳理了五大指标的定义、典型采集粒度以及业务层面的映射关系，是后续容量建模的基础。
| 指标 | 定义 | 典型采集粒度 | 业务映射 |
|---|---|---|---|
| QPS (Queries Per Second) | 每秒查询数，通常用于读密集型服务（如搜索、列表页） | 1s / 5s 窗口 | 用户每秒发起的页面浏览或搜索请求数 |
| TPS (Transactions Per Second) | 每秒事务数，通常用于写密集型或包含完整业务链路的服务（如下单、支付） | 1s / 5s 窗口 | 用户每秒完成的订单提交或支付操作数 |
| 并发数 (Concurrency) | 系统同时处理的请求/事务数量（包括排队中和正在处理的） | 实时快照 / 1min 均值 | 同时在线用户数或同时操作的用户数 |
| 响应时间 (Latency / RT) | 从请求发出到收到完整响应所经过的时间，通常关注 P50、P95、P99 | 按请求粒度记录，聚合为百分位 | 用户感知到的页面加载或操作反馈速度 |
| 资源利用率 (Utilization) | CPU、内存、磁盘 I/O、网络带宽的使用率 | 1s / 10s / 1min | 基础设施承载业务负载的饱和度 |
关键区分：QPS 与 TPS 在微服务架构中容易混淆。通常，一个 TPS 可能包含多个 QPS（如一次下单包含商品查询、库存查询、订单写入等多个查询）。在容量规划时，建议以 TPS 作为业务容量单位，以 QPS 作为组件容量单位。
2.2 指标采集架构与工具选型
在 Multi-Cluster 场景下，指标采集必须做到统一 Agent、统一传输、统一存储，否则版本漂移带来的指标口径差异将导致容量对比失效。下图展示了推荐的采集架构。
采集要点：
- 统一 Agent 版本：所有集群使用相同版本的 Prometheus Exporter 或 OpenTelemetry Collector，避免因 Agent 版本差异导致指标计算逻辑不同。
- 统一标签规范：强制注入
cluster_id、region、service_version等标签，便于后续按集群、按版本进行容量对比。 - 统一存储后端：使用 Thanos 或 VictoriaMetrics 作为全局指标存储，支持跨集群查询和长期保留。
2.3 指标解读方法论
采集到原始指标后，需要结合业务场景进行解读，才能转化为容量决策依据。以下从三个维度展开。
2.3.1 响应时间与并发数的关系：Little's Law
Little's Law 是容量规划中最基础的定量关系：
并发数 = QPS × 平均响应时间（秒）例如，某服务 QPS 为 1000，平均响应时间为 200ms，则理论并发数为 200。如果实际监控到的并发数远高于此值，说明存在请求排队或线程阻塞，系统已接近容量瓶颈。
版本漂移风险：当 Multi-Cluster 中某个集群的服务版本升级后，响应时间可能因代码变更而增加 50ms。根据 Little's Law，在 QPS 不变的情况下，并发数将线性增长，可能导致该集群率先触发限流或 OOM。容量规划时必须为版本变更预留并发缓冲。
2.3.2 资源利用率饱和度曲线
资源利用率与吞吐量之间并非线性关系。当利用率超过 70%-80% 时，响应时间通常会出现非线性增长（即“膝盖点”）。下图展示了这一典型特征。
容量规划阈值建议：
- CPU 利用率：长期均值 ≤ 70%，峰值 ≤ 85%
- 内存利用率：长期均值 ≤ 75%，避免触发 OOM Killer
- 磁盘 I/O 利用率：平均队列长度 ≤ 2，等待时间 ≤ 10ms
- 网络带宽利用率：入/出口 ≤ 60%，为突发流量预留空间
2.3.3 百分位响应时间解读
仅关注平均响应时间会掩盖长尾问题。在容量规划中，必须同时关注 P50、P95、P99 三个百分位：
- P50（中位数）：反映大多数用户的体验，用于评估系统正常负载下的性能。
- P95：反映 5% 的慢请求，通常与资源争抢或 GC 停顿相关，是容量瓶颈的早期信号。
- P99：反映极端情况，与超时、重试、资源耗尽强相关，是容量上限的预警指标。
在 Multi-Cluster 环境中，如果 Cluster A 的 P99 响应时间突然从 500ms 升至 2000ms，而 Cluster B 保持不变，应优先排查 Cluster A 的版本是否发生了变更，而非盲目扩容。
2.4 指标采集实战：Prometheus + 自定义埋点
以下是一个标准的 Prometheus 指标采集配置示例，包含 QPS、响应时间、并发数的采集与标签注入。
# prometheus.yml 片段
scrape_configs:
- job_name: 'app-capacity-metrics'
scrape_interval: 10s
static_configs:
- targets: ['app:8080']
labels:
cluster_id: 'cluster-a'
service_version: 'v2.3.1'
metrics_path: '/metrics'
relabel_configs:
- source_labels: [__address__]
target_label: instance
- source_labels: [cluster_id]
target_label: cluster
- source_labels: [service_version]
target_label: version应用层需要暴露以下自定义指标：
# HELP app_requests_total Total number of requests
# TYPE app_requests_total counter
app_requests_total{method="GET",endpoint="/api/order"} 1024000
# HELP app_request_duration_seconds Request latency in seconds
# TYPE app_request_duration_seconds histogram
app_request_duration_seconds_bucket{le="0.1"} 500000
app_request_duration_seconds_bucket{le="0.5"} 900000
app_request_duration_seconds_bucket{le="1.0"} 980000
app_request_duration_seconds_bucket{le="+Inf"} 1024000
app_request_duration_seconds_sum 204800
app_request_duration_seconds_count 1024000
# HELP app_in_flight_requests Current number of in-flight requests
# TYPE app_in_flight_requests gauge
app_in_flight_requests 42
关键查询语句（PromQL）：
- QPS：
rate(app_requests_total[1m]) - P99 响应时间：
histogram_quantile(0.99, rate(app_request_duration_seconds_bucket[5m])) - 并发数：
app_in_flight_requests - CPU 利用率：
rate(container_cpu_usage_seconds_total[1m]) / container_spec_cpu_quota
2.5 Multi-Cluster 指标对比与版本漂移检测
当多个集群运行不同版本的服务时，通过指标对比可以快速发现版本漂移导致的容量异常。以下是一个对比分析框架：
| 对比维度 | 对比指标 | 异常判定标准 | 可能原因 |
|---|---|---|---|
| 吞吐量 | QPS / TPS | 相同负载下，集群间差异 > 15% | 版本性能退化 / 配置差异 |
| 响应时间 | P50 / P95 / P99 | P99 差异 > 30% 或 P50 差异 > 20% | 代码变更 / 依赖服务版本不匹配 |
| 资源效率 | 每 QPS 消耗的 CPU 核数 | 差异 > 20% | 算法优化 / 资源泄漏 |
| 错误率 | HTTP 5xx / 业务错误码 | 差异 > 1% | 接口兼容性问题 / 数据格式变更 |
实战案例：某电商平台在双 11 压测中发现，Cluster B（新版本 v2.4.0）的 P99 响应时间比 Cluster A（旧版本 v2.3.1）高出 40%。通过指标对比发现，新版本引入了更细粒度的日志记录，导致 I/O 等待时间增加。容量规划团队据此将新版本的 CPU 预留从 2 核调整为 3 核，并推动研发优化日志异步写入，最终消除了版本漂移带来的容量风险。
2.6 本章小结
容量度量指标的采集与解读是 Multi-Cluster 容量规划的基石。核心要点包括：
- 统一 QPS、TPS、并发数、响应时间、资源利用率五大指标的定义与采集口径。
- 建立跨集群的统一采集架构，强制注入版本标签，为版本漂移检测提供数据基础。
- 运用 Little's Law 和饱和度曲线进行定量分析，设定合理的容量阈值。
- 通过百分位响应时间和集群间指标对比，主动发现版本变更带来的容量异常。