依赖治理全景图
回答“系统依赖越来越多以后，怎样避免调用链、第三方、库版本和共享组件把风险悄悄扩散”
阅读边界: 依赖治理不只是升级依赖包，也不只是画服务调用图。它要同时管理运行时依赖、构建时依赖、第三方服务、共享库、数据依赖、组织依赖和供应链风险。
一句话判断: 如果一个服务宕机、一个 SDK 升级或一个第三方接口抖动能让多个业务一起失控，依赖已经从复用资产变成系统风险。
识别依赖
分级风险
明确 owner
设定契约
监控退化
治理升级
| 依赖类型 | 常见风险 | 治理判断 |
|---|
| 同步服务依赖 | 超时、重试、级联故障、循环依赖 | 必须定义超时、熔断、降级、依赖方向和故障传播边界 |
| 异步与数据依赖 | Topic、任务、表和报表依赖不可见 | 把消息、任务和数据血缘纳入服务地图，不只看 HTTP 调用 |
| 共享库 / SDK | 版本碎片、隐性行为变更、批量升级风险 | 公共库要有版本策略、兼容承诺和灰度升级路径 |
| 第三方服务 | SLA 不可控、限流、合规与供应商锁定 | 按业务关键性设计缓存、Fallback、替代方案和退出预案 |
依赖目录
把服务、库、Topic、数据库、第三方、批任务和数据集都登记成可查询依赖，而不是只登记服务。
依赖分级
区分强依赖、弱依赖、可降级依赖、批处理依赖和人工流程依赖，决定不同治理强度。
契约与兼容
依赖的接口、事件、配置和 SDK 都要有兼容承诺，避免被上游静默破坏。
超时与隔离
同步依赖必须设置超时、重试预算、连接池隔离和故障降级，不能把慢依赖传染给主链路。
升级治理
公共库、运行时、框架和基础设施升级要有批次、回滚、验证矩阵和使用面观测。
退出预案
关键第三方和核心共享组件必须有替代方案、数据导出和降级运营预案。
| 外部依赖 | 治理动作 | 判断重点 |
|---|
| 第三方接口 / SaaS | 登记 owner、SLA、限流规则、凭证、监控、升级渠道和合同约束 | 外部系统也是生产依赖，不能只在采购或业务侧留档 |
| 关键通道 | 为支付、短信、风控、地图、实名认证等高影响通道设计备用方案 | 第三方故障不应直接等价为本系统不可用 |
| 凭证与安全 | 外部凭证要有轮换、权限最小化、泄露响应和调用审计 | 供应商治理同时也是安全和合规治理 |
| 退出计划 | 明确数据导出、替代服务、迁移窗口、成本影响和下线验收 | 没有退出方案的外部依赖会变成锁定风险 |
| 风险层级 | 判断标准 | 治理要求 |
|---|
| L0 低风险依赖 | 非核心路径、可缓存、失败可忽略或只影响内部效率。 | 登记 owner 和版本，保留基本监控，不必高强度演练。 |
| L1 可降级依赖 | 影响体验但不影响核心交易、资金、数据正确性或合规。 | 必须有超时、降级文案、默认值、缓存或排队策略。 |
| L2 强运行依赖 | 同步调用或关键异步链路失败会阻断核心业务。 | 必须有 SLO、告警、容量边界、隔离、熔断、压测和事故预案。 |
| L3 外部 / 供应商关键依赖 | 第三方不可控，故障会影响收入、资金、身份认证、通知或风控。 | 必须有供应商 SLA、备用通道、退出预案、凭证轮换、合规审计和业务告知方案。 |
| L4 组织级单点依赖 | 大量系统共同依赖同一组件、SDK、平台或人员知识。 | 必须纳入架构评审、版本治理、演练、替代路线和组织 ownership 复核。 |
| 预案项 | 最低内容 | 验收信号 |
|---|
| 升级窗口 | 影响服务、消费者清单、版本差异、灰度批次、回滚方式。 | 能按批次看到成功率、错误率、版本分布和异常消费者。 |
| 兼容策略 | 旧版本支持多久，新旧字段、错误码、SDK 行为和默认配置怎样兼容。 | 升级期间新旧消费者可以共存，不出现静默语义破坏。 |
| 故障替代 | 缓存、备用供应商、人工流程、只读模式、排队补偿或业务告知。 | 关键第三方故障时，不把外部不可用直接传递给核心用户路径。 |
| 退出路线 | 数据导出、调用迁移、合同 / 成本影响、权限回收、监控下线、文档更新。 | 依赖下线后没有未知调用、僵尸凭证、幽灵告警和无人负责的数据残留。 |
| 误区 | 为什么危险 | 修正方式 |
|---|
| 依赖图只看在线调用 | 真实事故常来自批任务、数据表、消息和人工流程 | 把运行时、构建时、数据和组织依赖合并看 |
| 共享库越统一越好 | 统一过度会形成大范围锁步升级和单点缺陷 | 公共能力要有版本策略和兼容窗口 |
| 第三方故障只能等恢复 | 等待会把外部 SLA 直接传给用户 | 提前设计缓存、降级、替代流程和业务告知 |
| 检查项 | 最低要求 |
|---|
| 依赖登记 | 上线前登记上下游、数据、消息、第三方和共享库依赖 |
| 风险分级 | 关键依赖有 owner、SLO、故障影响、降级策略和退出方案 |
| 故障隔离 | 超时、重试、限流、熔断、连接池隔离和队列积压策略明确 |
| 升级路径 | SDK / 共享库升级有兼容检查、灰度范围和回滚方案 |
| 观测看板 | 依赖错误率、延迟、调用量、版本分布和故障传播路径可见 |
| 登记字段 | 要写清楚什么 | 缺失后的后果 |
|---|
| 依赖身份 | 依赖名称、类型、owner、消费者、生产环境、版本、生命周期状态 | 故障时不知道谁在用、用的是哪个版本、谁负责升级 |
| 业务影响 | 影响路径、核心程度、用户影响、收入 / 资金 / 数据 / 合规风险 | 所有依赖看起来同等重要，资源无法优先投到关键链路 |
| 技术契约 | 接口、Topic、表、SDK API、错误码、兼容承诺、弃用时间和变更通知方式 | 上游静默变更，下游只能在事故里发现语义破坏 |
| 运行边界 | 超时、重试预算、限流、熔断、缓存、降级、排队、隔离和容量上限 | 慢依赖被重试放大，最后拖垮主链路和下游 |
| 退出与替代 | 备用方案、迁移成本、数据导出、凭证回收、监控下线和合同约束 | 依赖看似可替换，真正要换时发现没有出口 |
| 风险看板字段 | 观察什么 | 触发动作 |
|---|
| 关键依赖集中度 | 多少核心服务依赖同一组件、供应商、SDK、数据库或人员知识 | 纳入架构评审，设计隔离、替代或分阶段降依赖路线 |
| 版本分布 | 共享库、SDK、运行时和协议版本的使用面、旧版本比例和升级失败点 | 发起兼容窗口、灰度升级、弃用公告和强制迁移计划 |
| 故障传播 | 某依赖错误率、延迟、超时、队列积压如何影响下游服务 | 调整超时重试、熔断、连接池隔离、降级策略和告警阈值 |
| 外部 SLA 偏差 | 供应商可用性、限流、响应时间、错误码和支持响应是否低于承诺 | 启动供应商沟通、备用通道演练、合同复核或退出预案 |
| 未知依赖 | 调用链、网关、消息、数据库审计里出现未登记消费者或生产调用 | 补登记、确认 owner、评估安全风险，必要时阻断或迁移 |
| 相关页 | 连接关系 |
|---|
| 服务目录与系统地图 | 依赖治理需要服务目录承载 owner、依赖关系和运行入口 |
| 可靠性治理 | 关键依赖的故障传播、错误预算和降级策略属于可靠性治理的一部分 |
| 数据契约 | 接口、事件和数据依赖都要靠契约管理兼容演进 |
| 网络安全 | 第三方、供应链和开源依赖需要纳入安全扫描和合规治理 |
| 迁移工程 | 迁移前必须先识别依赖面，否则切换范围和回滚边界会被低估 |