云原生改变了系统的存在方式，也改变了「关系」的维护方式。这篇从云原生视角聊依赖关系映射为什么从可选变成必选。
一、云把「关系」的半衰期缩短了十倍
传统环境里架构半年一变，Excel 还能勉强跟上；云原生环境里服务实例分钟级生灭、发布以天为单位、弹性扩缩容随时改写连接关系。人工维护的关系数据半衰期从「季度」跌到「天」，这正是依赖关系映射从锦上添花变成基础设施的原因：只有自动化发现和更新，才能跟上环境的变动频率。
二、云原生环境下的三个新要求
其一，发现必须对接编排层：Kubernetes 的 Service、Deployment、Operator 资源是服务关系的事实来源，探针扫不出「逻辑拓扑」。其二，拓扑要区分层次：基础设施层（Pod/Node）、服务层（Service/网格）、业务层（链路）分层建模，告警才能在正确的粒度上关联。其三，与服务网格/trace 数据融合：网格提供东西向流量的真实连接，映射提供全局结构，两者结合才能覆盖「物理连接」与「逻辑调用」。
三、落地检查清单
□ 编排层资源已接入发现；□ 弹性扩缩容后拓扑自动更新；□ 跨命名空间/跨集群依赖可见；□ 告警自动关联上下游服务；□ 发布前能查询变更影响范围；□ 拓扑数据回流 CMDB。六项全过，依赖映射才算真正进入云原生工作流。
四、一个判断标准
拿最近一次线上故障做检验：从告警出现到确认影响范围用了多久？如果答案是「靠人拉群逐个问」，那么关系数据的建设优先级应该排到下个季度 List 的第一项。
核心要点
- 监控只回答「哪里慢」，回答不了「为什么慢、影响谁」——缺的不是指标，是系统关系的透明度。
- 依赖关系映射的本质：自动发现应用、服务器、数据库、中间件，把调用关系画成实时拓扑，替代 Excel 和过时的架构图。
- 四个验收点：发现覆盖容器与弹性扩缩容、拓扑随变更动态更新、能从技术组件映射到业务流程、支持与 CMDB 同步。
- 与调用链追踪结合，故障定位从「逐层猜」变成「沿拓扑找」，MTTR 明显缩短。
- 变更前看拓扑评估影响范围，比事后救火便宜一个数量级。
常见问题
- 什么是应用依赖关系映射？它和架构图有什么区别？
架构图是人工绘制的静态快照，三周不上色就过时；依赖关系映射是基于自动发现、持续更新的关系数据——新服务上线自动入图，下线自动移除。前者靠人维护，后者靠系统维护，这是本质差别。 - 已经有调用链追踪了，还需要依赖关系映射吗？
需要，两者互补。调用链看的是「一次请求经过了谁」，受采样率限制，没被采样的请求不产生关系数据；依赖映射看的是「系统里长期存在哪些连接关系」，基于发现与配置，覆盖面更完整。trace 擅长单次请求的深挖，映射擅长全局结构的掌控。 - 依赖关系怎么自动发现？靠什么手段？
常见手段有四类：按 IP 段做网络扫描、在主机上装采集探针、解析应用配置与连接串、从编排系统 API（如 Kubernetes）读取服务清单。成熟的做法是多手段叠加，再定期重扫以跟上变更。 - 拓扑多久更新一次才可信？
变更频繁的环境建议小时级到天级自动发现。判断标准不是间隔数字，而是两条：新资源能否自动入图、下线资源能否自动移除。凡是需要人工改图才能保持准确的方案，撑不过一个季度。 - 中小团队有必要做依赖映射吗？
服务少于 20 个、变更频率低，人脑加文档可以撑；超过 50 个服务、或每年变更上百次，人工维护的关系会系统性失真——不是记得不准，是根本记不全。这时自动映射的投入产出是划算的。
参考来源
- ITIL 4 服务管理体系（Axelos 官方）：配置管理与变更使能的框架定义，依赖关系数据是变更评估的基础。
- OpenTelemetry 官方文档：分布式追踪与依赖关系的开放标准，调用链数据的采集与语义约定。
一句话总结：依赖关系映射解决的不是「采不到指标」，而是「说不清关系」——先把系统结构变成实时数据，故障定位、影响评估、变更规划才有地基。
你们团队的系统关系现在靠什么维护？Excel、架构图，还是老师傅的记忆？评论区聊聊你踩过的「关系失真」的坑。
