压降实战背景：理解压降及其影响

在自愈剧本设计之前，必须首先理解什么是“压降”（Pressure Drop）——这一概念源自流体力学，但在分布式系统中被引申为系统在承受压力时，关键性能指标（KPI）或服务质量（QoS）出现的可测量下降。压降是系统稳定性退化的前兆信号，也是混沌工程中触发自愈流程的核心判据。

一、什么是压降（Pressure Drop）

压降并非故障本身，而是压力与容量之间失衡的外在表现。当系统负载超过当前资源池的处理能力，或组件出现部分失效时，端到端的响应时间、吞吐量、错误率等指标会偏离基线，形成“压降曲线”。

二、压降对系统稳定性的影响

压降是系统稳定性退化的放大器。一旦出现压降，若不及时干预，会引发以下连锁效应：

• 请求排队与超时扩散：单节点处理变慢 → 请求堆积 → 客户端重试 → 上游负载雪崩。
• 资源争抢加剧：CPU 时间片、内存带宽、磁盘 IO 在争抢中进一步恶化，形成正反馈循环。
• 数据一致性风险：分布式事务在超时场景下容易产生部分提交或回滚失败，导致脏数据。
• 监控盲区：压降初期指标波动剧烈，传统固定阈值告警容易产生大量误报或漏报。

三、压降场景分类

根据系统资源模型，压降场景可分为三大类：网络压降、存储压降、计算压降。每类场景的根因、表现和自愈策略差异显著，需要分别设计检测与恢复剧本。

3.1 网络压降

网络压降是最常见且传播最快的压降类型。典型表现包括：

• TCP 重传率上升：超过 2% 即视为压降信号。
• 连接池耗尽：活跃连接数达到上限，新请求被阻塞。
• DNS 解析延迟：上游 DNS 响应时间 > 500ms。

3.2 存储压降

存储压降通常表现为 IO 延迟增加或容量不足，对数据库和缓存层影响尤为严重。

• 磁盘 IOPS 打满：平均 IO 等待时间 > 50ms。
• 慢查询堆积：数据库连接池中慢查询占比 > 20%。
• 缓存穿透：缓存命中率从 95% 骤降至 60% 以下。

3.3 计算压降

计算压降主要发生在 CPU 密集型服务或内存受限的场景，通常与代码效率或资源争抢相关。

• CPU 软锁：单核 CPU 使用率持续 100%，但系统负载不高（自旋锁或死循环）。
• 内存 OOM：堆内存使用率 > 90%，GC 频率飙升。
• 线程池耗尽：工作线程全部阻塞，新任务被拒绝。