4、流量指标详解：请求速率（RPS/QPS）、并发连接数、流量突增的识别与应对策略
流量（Traffic）是衡量服务系统负载与健康状态最直接的黄金信号。在可观测性体系中，流量指标不仅反映用户行为与业务规模，更是容量规划、弹性伸缩、限流降级等运维动作的核心依据。本章将深入解析请求速率（RPS/QPS）、并发连接数两大核心流量指标，并系统阐述流量突增的识别方法与应对策略。
4.1 请求速率（RPS/QPS）
请求速率是单位时间内系统接收并处理的请求数量。根据协议与业务场景的不同，通常使用 RPS（Requests Per Second，每秒请求数） 或 QPS（Queries Per Second，每秒查询数） 来度量。在 RESTful API 或 Web 服务中，RPS 与 QPS 常被混用，但在数据库或搜索引擎场景下，QPS 特指查询类操作。
4.1.1 指标定义与采集
| 指标名称 | 定义 | 典型采集方式 | 常见工具 |
|---|---|---|---|
| RPS | 每秒进入系统的完整请求数（含成功、失败、超时） | 负载均衡器连接数 / 应用层计数器 | NGINX status、HAProxy stats、Prometheus Rate |
| QPS | 每秒数据库或搜索引擎执行的查询次数 | 数据库内置监控（SHOW STATUS）、中间件指标 | MySQL Questions、Elasticsearch search.query_total |
| 成功请求速率 | 每秒返回 2xx/3xx 状态码的请求数 | 应用日志聚合 / 服务网格指标 | Istio istio_requests_total、Spring Boot Actuator |
| 错误请求速率 | 每秒返回 5xx/4xx 状态码的请求数 | 同上，按状态码过滤 | PromQL rate(http_requests_total{status=~"5.."}[1m]) |
4.1.2 指标解读与异常模式
- 平稳增长：符合业务预期，通常伴随资源利用率线性上升，属于正常模式。
- 阶梯式突增：短时间内 RPS 从 1000 跃升至 5000，可能由营销活动、热点事件或爬虫攻击引发。
- 周期性波动：每日/每周固定时段出现波峰，如早高峰、秒杀时段，需提前准备弹性资源。
- 异常陡降：RPS 突然归零或骤降 80%，通常意味着上游服务不可用、DNS 解析失败或负载均衡器故障。
- 高 RPS 低成功率：请求速率很高但 5xx 比例同步上升，表明系统已过载，正在主动拒绝或处理失败。
4.2 并发连接数
并发连接数指在某一时刻，系统同时维持的活跃连接数量。与 RPS 不同，并发连接数反映的是系统当前的 存量 负载，而非 流量 速率。高并发连接数并不一定意味着高 RPS，例如长轮询（Long Polling）或 WebSocket 场景下，连接数可能很高但请求速率较低。
4.2.1 关键指标维度
| 维度 | 说明 | 监控对象 |
|---|---|---|
| 活跃连接数 | 当前正在传输数据或等待响应的连接 | NGINX Active connections、Tomcat threads.busy |
| 空闲连接数 | 已建立但无数据传输的连接（连接池复用） | 数据库连接池 idle、HTTP Keep-Alive 连接 |
| 等待队列长度 | 因线程池/连接池满而排队等待处理的请求数 | Tomcat requestCount、线程池 queue.size |
| 连接建立速率 | 每秒新建 TCP 连接数 | NGINX Accepts、系统 netstat 统计 |
4.2.2 并发连接数与 RPS 的关系模型
并发连接数、RPS 与平均响应时间（Latency）之间存在经典的小林定律（Little's Law）：
并发连接数 = RPS × 平均响应时间（秒）该公式在稳态系统中成立。当响应时间上升时，即使 RPS 不变，并发连接数也会同步增长。因此，并发连接数的异常升高往往是响应时间劣化的先行指标。
4.3 流量突增的识别方法
流量突增（Traffic Spike）是生产环境中引发故障的首要诱因。识别突增不能仅依赖人工盯盘，必须建立基于阈值的自动化检测机制。
4.3.1 静态阈值告警
设定固定阈值，例如“RPS > 10000”触发告警。适用于业务流量相对稳定的场景，但容易在业务正常增长时产生误报。
4.3.2 动态基线检测
基于历史数据（过去 7 天或 28 天同一时段）计算动态基线，当实时指标偏离基线超过 3σ（标准差）或 200% 时触发告警。常用算法包括：
- 移动平均法：计算过去 N 个时间窗口的均值，与当前值比较。
- 指数加权移动平均（EWMA）：对近期数据赋予更高权重，适应缓慢趋势变化。
- 分位数基线：使用 P50/P95/P99 作为基线，适合长尾分布流量。
4.3.3 同比/环比对比
将当前流量与“昨日同时段”或“上周同日同时段”对比，识别异常突增。例如：
突增比例 = (当前 RPS - 昨日同时段 RPS) / 昨日同时段 RPS × 100%当突增比例超过 50% 且持续超过 5 分钟时，触发中级告警。
4.3.4 多指标联合判断
单一指标突增可能是误报，结合多个黄金信号可提高准确率：
| 场景 | RPS | 并发连接数 | 错误率 | 响应时间 | 判断结论 |
|---|---|---|---|---|---|
| 正常流量高峰 | ↑ | ↑ | → | → 或微升 | 系统健康，无需干预 |
| 过载风险 | ↑ | ↑↑ | ↑ | ↑↑ | 需立即扩容或限流 |
| 攻击流量 | ↑↑ | ↑↑↑ | ↑↑（4xx/5xx） | ↑ 或 ↓ | 触发 WAF 或 IP 黑名单 |
| 上游故障 | ↓ | ↓ | ↑↑ | N/A | 检查上游依赖与 DNS |
4.4 流量突增的应对策略
应对策略需形成自动化闭环：检测 → 决策 → 执行 → 恢复。以下按执行时机排序：
4.4.1 事前预防
- 容量规划：基于历史峰值与业务增长预测，预留 30%~50% 的冗余容量。
- 弹性伸缩策略：配置 HPA（Horizontal Pod Autoscaler）或 ASG（Auto Scaling Group），设定基于 RPS 或并发连接数的伸缩规则。
- 限流降级配置：在网关层（如 Kong、APISIX）或应用层预置限流规则，如令牌桶、漏桶算法。
4.4.2 事中应对
| 策略 | 适用场景 | 操作方式 | 风险 |
|---|---|---|---|
| 快速扩容 | RPS 突增但错误率未显著上升 | 增加 Pod 副本数 / 添加后端服务器 | 扩容速度可能跟不上流量增速 |
| 限流 | 系统已过载，错误率上升 | 网关层按 IP/用户/API 路径限流 | 可能影响正常用户 |
| 降级 | 非核心功能可牺牲 | 关闭推荐、评论等非关键服务 | 用户体验下降 |
| 流量调度 | 多区域/多集群部署 | DNS 权重调整 / 全局负载均衡切换 | 跨区域延迟增加 |
4.4.3 事后复盘
- 分析流量突增的根因：是业务活动、外部攻击还是上游重试风暴？
- 更新动态基线：将本次突增模式纳入历史数据，优化告警阈值。
- 压力测试：针对突增场景进行混沌工程或全链路压测，验证限流与扩容策略的有效性。
4.5 流量指标监控架构
下图展示了一个生产级流量指标监控与应对的架构设计，涵盖从数据采集到自动化执行的完整链路。
4.6 流量突增识别与应对流程
以下流程图展示了从指标异常检测到策略执行的标准操作流程，帮助团队建立可重复的响应机制。
4.7 关键总结
- RPS/QPS 是流量速率的直接度量，需区分入口与出口流量，并结合成功率解读。
- 并发连接数 反映系统存量负载，与 RPS 和响应时间满足 Little's Law，是过载的先行指标。
- 流量突增识别 应综合使用静态阈值、动态基线、同比环比与多指标联合判断，降低误报率。
- 应对策略 需形成事前预防、事中应对、事后复盘的闭环，优先自动化扩容与限流，避免人工决策延迟。
- 监控架构 应覆盖从流量入口到告警执行的全链路，确保指标采集、存储、告警、执行各环节低延迟且高可用。