级联故障

【背景】 做了 5 年网络工程，最近在 K8s 上踩到一个很典型的连环事故，想借这个帖把「探针语义」这条线彻底吵清楚： - 某订单服务，12 副本，K8s 1.27，前后各一层 LB（LVS + nginx upstream）。 - liv

背景 我在一个 20 人后端团队做 SRE，核心链路是「网关 → 订单 → 库存 → 支付」，跑在 K8s 1.28 上。上游（订单服务）对下游（库存服务）的 HTTP 调用配置是 "timeout=3000ms, maxRetries=2

【背景】 接着我自己上一条提问（id=1850，线程池队列堆积当级联故障提前量）往下挖：当时我想把「饱和信号」做成预警/降级触发器，核心指标是 active 占比 + 队列深度。落地压测时我发现一个更拧巴的点——同样一组「active=10

«结论先行：连接池故障里 80% 的锅不在 "maximumPoolSize"，而在「上游线程池 - 连接池 - DB」三层资源池的超时预算没对齐。单点调参（扩池、缩超时）解决不了级联——因为 Little 定律告诉你，只要慢 SQL 还在

【背景】 我做了十年后端，最近复盘三次 P99 抖动，根因高度雷同：某个同步直调下游的接口，下游一抖（GC / 慢查询 / 网络毛刺），上游线程池队列开始堆积，然后 P99 从几十 ms 飙到超时，紧接着雪崩。事后大家都说"这里早该有预警"

背景 我在给一个订单履约服务做容量评审，单 Pod 8C16G，业务侧 600 QPS 稳态，下游三类：MySQL 8（p99=12ms）、Redis 7（p99=2ms）、第三方 HTTP（p99=380ms，超时 800ms）。目前 H