下游依赖瓶颈是什么
下游依赖瓶颈指被测系统的性能上限并非由自身决定，而是被数据库、缓存、消息队列或第三方接口拖住：自身 CPU 与内存尚有余量，但响应时间随下游波动同步变化。这类问题的排查关键是把一次请求按依赖分段计时，分清是自身处理慢还是等待下游慢，再决定优化方向。
基本信息
| 典型信号 | 自身资源利用率低但延迟高，下游监控同时吃紧 |
|---|---|
| 排查手段 | 链路追踪分段计时、下游指标联动观察、依赖调用日志 |
| 数据库侧 | 慢查询、锁等待、连接数上限、批量操作过大 |
| 中间件侧 | 缓存击穿、集群扩容不及时、消费积压 |
| 第三方侧 | 超时设置过长、重试放量、配额限制 |
| 验证方式 | 在压测中同步观测下游，避免把下游拖垮后误判为自身上限 |
典型使用场景
- 压测过不去：自身压力机与服务器指标正常，延迟却居高不下。
- 高峰抖动：活动期间数据库连接耗尽，接口批量超时。
- 第三方集成：依赖的外部接口变慢，本地超时与重试策略需要重估。
- 容量规划：判断扩容自身服务是否有用，还是要给下游加资源。
- 故障归因：排障时快速证明问题出在链路的哪一跨。
分段计时拆解
| 分段 | 观测点 | 异常判读 |
|---|---|---|
| 自身处理 | 应用内耗时与 CPU | CPU 高则为自身瓶颈 |
| 数据库调用 | SQL 耗时、连接等待 | 等待增长则连接池或慢查询 |
| 缓存调用 | 命中率、响应时间 | 命中骤降则击穿或失效 |
| 第三方调用 | 请求耗时分布、错误率 | 放大延迟或限流信号 |
| 消息队列 | 发送与消费延迟 | 积压则消费能力不足 |
压测要保下游：先确认下游能承受的量级，再决定压测强度，贸然全速会制造生产事故。
超时要成体系：连接、读、写三个超时与重试次数一起设计，否则重试风暴会放大故障。
结论要带证据：链路追踪时间线比任何口头争论都有说服力。