链路视角的必要性
单个服务健康不代表整条链路可用。依赖链评估要先画清调用关系，再判断每一跳的状况，并回答两个问题：链路中最容易先垮的是哪一跳，以及某一跳不可用时服务会整体失败还是降级。缺少降级设计的链路，任何一跳异常都会表现为全链路不可用。
基本信息
| 评估对象 | 服务、中间件、数据库、外部接口之间的调用关系 |
|---|---|
| 依赖类型 | 强依赖缺失即失败，弱依赖可降级处理 |
| 采集数据 | 调用拓扑、成功率、时延、超时与重试配置 |
| 关键概念 | 关键路径与爆炸半径 |
| 输出物 | 依赖清单、降级策略、故障域划分 |
典型使用场景
- 发布前评估：确认新引入的外部依赖已纳入检查，避免形成监控盲区
- 故障定位：全链路异常时逐跳核对，快速定位首个异常节点
- 降级设计：为弱依赖设置超时与兜底返回，避免下游慢拖垮上游
- 容量评估：按链路中承载能力最小的一跳确定整体容量上限
- 演练复盘：按链路做故障注入，验证降级与限流是否按设计生效
依赖链上的关键判断
| 判断项 | 考察内容 | 常见问题 |
|---|---|---|
| 依赖强度 | 缺失是否导致功能不可用 | 弱依赖被按强依赖处理 |
| 超时设置 | 逐跳超时是否小于上层预算 | 超时层层放大，最慢一跳决定整体 |
| 重试策略 | 重试是否放大下游压力 | 无上限重试形成重试风暴 |
| 降级能力 | 是否有兜底返回或缓存 | 缺少降级，故障直接透传 |
逐跳核对链路健康
逐跳核对链路健康
# 从入口开始逐跳核对，先确定第一跳异常出现在哪个环节
curl -fsS -o /dev/null -w %{http_code} http://127.0.0.1:8080/healthz
# 依赖组件连通性与响应时间，单跳超时应小于上层请求预算
redis-cli -h cache01 ping
mysql -h db01 -e 'select 1'
# 采集逐跳耗时，定位链路中最慢的一环
for target in cache01 db01 api-partner; do
echo $target $(timeout 3 ping -c 1 -W 2 $target | awk -F/ 'END {print $5}')
done逐跳超时的累加值不应超过上层请求预算，否则最慢一跳会决定整体时延上限。重试必须带退避与次数上限，否则下游变慢时放大的重试流量会让链路彻底不可用。
共享依赖是链路评估中最容易被忽略的点：多个看似独立的服务依赖同一个数据库或缓存时，该组件故障会同时击中多条链路，因此爆炸半径必须按共享组件判断，而不是按服务逐个判断。