依赖治理的度量：数清你的隐形单点

故障防治系列新篇。前面聊了雪崩防治的舱壁模式——它有个前提：你得知道该隔离谁。这就是依赖治理的度量问题：一个跑了三年的服务，依赖图长什么样、哪些是隐形单点、哪些依赖在拖后腿——多数团队答不上来。这篇给一套可落地的依赖度量方法。

为什么依赖会失控

依赖的增殖是无感的：一个临时需求接了个内部服务、一次重构引入了新中间件、某个同事离职前留的「先这么连着」——三年后，服务 A 的依赖列表比任何人的记忆都长。失控的代价在故障时兑现：你排障时画的依赖图，和真实的依赖图，差的那部分就是事故的藏身处。

度量的四个数据源

1. 代码静态分析：import/调用关系——准但只覆盖显式依赖，抓不到配置里写的 SDK 端点
2. 配置扫描：扫描配置中心的下游地址、数据库连接串——补上静态分析的盲区
3. 运行时追踪：链路追踪（tracing）的实际调用关系——非常真实的数据，但依赖采样率（低频调用可能漏）
4. 网络层观测：出口流量的目的地统计——非常兜底的真相，能抓到「代码和配置都没记录」的神秘调用（通常是历史遗留的僵尸依赖）

四源对齐后取并集，得到的才是真实依赖图。只靠单一来源的依赖地图，用的时候会漏。

三个核心度量指标

指标一：扇出数（Fan-out）

单个服务直接依赖的下游数量。经验阈值：>10 个直接依赖的服务要警惕——不是说一定错，是复杂度已到「一个人脑装不下」的程度，出问题的排查半径太大。

指标二：关键依赖的「无替代度」

对每个关键依赖问一句：它挂了 4 小时，我们能不能降级运行？能降级的（有缓存兜底/有备用数据源）是软依赖；不能降级的（挂了业务就停）是硬依赖。硬依赖的数量就是你的隐形单点清单——治理目标不是消灭硬依赖（不现实），是让每个硬依赖都有人盯着、有预案、优先级明确。

指标三：依赖的健康贡献度

上游视角的度量：这个依赖近 90 天给我带来了多少故障/降级/延迟劣化？把依赖按「健康贡献」排序——排前面的就是要重点治理的对象（加隔离舱壁、加重试策略、或者干脆想办法去掉）。

度量之后的治理动作

1. 僵尸清理：网络层观测到但代码里找不到的依赖——逐个确认后斩断（非常常见的发现：服务调着一个早该下线的老接口，双方都不知道）
2. 硬依赖预案化：每个硬依赖配一份降级预案并演练过——预案没演练等于没有
3. 扇出拆分：扇出 >15 的服务通常是「什么都干」的上帝服务，按依赖域拆分
4. 新增门槛：新依赖的引入要过评审——不是官僚主义，是在「依赖地图」上登记（不登记的依赖不给出网权限，网络层策略兜底）

一个真实项目的度量结果

某核心交易服务，治理前的认知：依赖 8 个下游。四源对齐后：17 个（配置里 4 个、网络层 3 个是没人知道的）。其中硬依赖 5 个、僵尸依赖 2 个。治理动作：斩僵尸、给 5 个硬依赖配预案、扇出拆分排进季度规划。

半年后同类故障（依赖抖动引发的交易异常）下降七成——不是依赖更稳了，是暴露面和控制力变了。

度量的持续化

依赖地图不是一次性项目：季度刷新四源数据、diff 新增依赖（新增的必须登记过）、硬依赖清单进值班手册（出事时值班知道哪些依赖是致命的）。把依赖治理变成持续运营而不是运动式审计——这是「有依赖地图」和「依赖地图有用」的区别。

（服务端系列：网关限流 → 熔断降级 → 灰度闭环 → 缓存一致性 → API 版本治理 → 舱壁隔离 → 本文：依赖度量 → 计划中：故障演练的常态化）