依赖的显式化：服务目录的最小可行做法

故障防治系列新篇。前面聊过雪崩防治的舱壁模式、依赖治理的度量——都默认了一个前提：你知道自己依赖谁。这篇补上那个前提：依赖怎么变得可见。多数团队的依赖关系一半在代码里、一半在人的脑子里，出事时才临时拼图。

为什么依赖总是暗的

三个结构性原因：

• 框架代管：服务发现、网关路由把依赖配置收进基础设施，写代码的人未必知道自己调的「用户服务」背后还挂着缓存和消息队列
• 人员流动：当年为什么依赖这个服务，理由随作者离职一起消失，剩下的人不敢动、也不敢断
• 跨团队盲区：依赖别的团队的服务时，往往只认识「接口」，不认识它的容量、SLA 和它自己的依赖——一层下去全是暗的

暗依赖的代价在变更和故障时集中兑现：改一个配置炸三个下游、故障排查一小时有四十分钟在画依赖图。

最小可行服务目录：五个字段

不需要上重型平台，一张表就能起步。每个服务一行，五个字段：

1. 身份：服务名、负责人（具体到人，不是组）
2. 直接依赖：同步调用、异步消息、存储——三类分开列
3. 被谁依赖：反向关系，从调用方采集，不由服务自己申报（申报必然漏）
4. 容量与 SLA：日常 QPS 峰值、承诺的可用性、降级开关在哪
5. 变更窗口：什么时候可以动、动了要通知谁

采集方式：从「申报」到「实测」

申报的目录三天就过期。可持续的做法是自动采集：

• 调用侧：从链路追踪里导出真实调用关系（Trace 里每一段跨服务调用都是一条依赖边）——每周跑一次全量导出
• 消息侧：从消息队列的消费组关系拿事件依赖
• 入口侧：网关和 DNS 记录补齐「谁从外面进来」

人工申报只留一项：依赖的理由（为什么依赖它）——这个机器采不到，却是最有价值的字段，它决定了这条依赖该不该存在。

目录建完怎么用：三个场景

1. 变更评估：改服务 A 之前，查它的「被依赖」列表——影响面从拍脑袋变成查表
2. 故障定位：告警在 D，从目录反查 D 的上游是谁、最近谁变更过——排查路径缩短一半
3. 治理排序：被依赖最多的服务（拓扑中心）优先做容量冗余和降级能力——投入产出比最高的一批

一个真实的反例

某次大促前压测，A 服务报容量不足要扩容——目录一查，A 被 11 个服务同步依赖，其中 3 个在大促场景根本用不到它（历史遗留调用）。真正的修复不是扩容 A，而是那 3 条依赖下线。没有目录，扩容是唯一选项；有了目录，砍依赖才是选项。

节奏建议

别搞全员大梳理（运动式梳理的目录活不过一个季度）。从一个故障域起步（比如最近出过事的那条链路），用链路追踪自动采，两周出第一版目录，只覆盖那一条链——然后在下次变更和故障里实际用它。用出甜头的目录才会被维护，被维护的目录才是活的。

（故障防治系列：服务雪崩 → 舱壁隔离 → 依赖度量 → 故障演练 → 配置漂移 → 本文：依赖显式化）