依赖分析

概述 在现代微服务架构中，一个看似简单的用户请求可能穿越数十个服务节点。当故障发生时，SRE 工程师面对的第一个问题往往不是"怎么修"，而是"影响范围有多大"。如果无法快速回答这个问题，故障恢复就会被拖延在无休止的排查中。 服务依赖地图（Service Dependency Map）和故障域分析（Failure Domain Analysis）是解决这一问题的工程方法论。前者解决"谁依赖谁、怎么依赖"的认知问题，后者解决"故障会扩散到哪、爆炸半径多大"的控制问题。两者结合，构成了 SRE 可靠性工程的基础设施。 从依赖拓扑的发现方法出发，深入分析故障域的识别与隔离策略，最后给出爆炸半径控制的工程实践方案。 服务依赖的复杂性本质 微服务架构下的依赖特征 单体应用时代的依赖关系是显式的、编译期的——通过 import 语句和函数调用就能完整描绘依赖图。微服务架构彻底改变了这一范式： 维度 单体应用 微服务架构 依赖发现方式 代码静态分析 运行时流量观测 依赖类型 函数调用 HTTP/gRPC/消息队列/事件总线 依赖稳定性 编译期确定 运行时动态变化 依赖可见性 IDE 可直接跳转 需要专门工具发现 故障传播路径 进程内异常栈 跨网络级联故障 依赖数量级 几十到几百 几百到几千 依赖关系的分类体系 并非所有依赖都具有相同的风险等级。一个成熟的依赖地图必须对依赖关系进行分类标注： 按调用方式分类： 同步调用：HTTP REST、gRPC、数据库查询。调用方阻塞等待响应，是级联故障的主要传播路径。 异步调用：消息队列（Kafka、RabbitMQ）、事件总线。调用方不阻塞，但消费端故障可能导致消息积压。 共享资源依赖：共用数据库、缓存集群、存储卷。资源竞争可能引发间接故障。 基础设施依赖：DNS、服务发现、配置中心。这类依赖故障影响面极广，属于关键路径。 按关键性分类： 强依赖：被依赖方不可用时，调用方无法完成核心功能。例如订单服务依赖库存服务。 弱依赖：被依赖方不可用时，调用方可降级运行。例如商品详情页依赖推荐服务。 条件依赖：在特定场景下才触发的依赖。例如促销活动期间才调用的优惠券服务。 # 依赖分类标注示例 class DependencyType: SYNC_HTTP = "sync_http" SYNC_GRPC = "sync_grpc" ASYNC_MQ = "async_mq" SHARED_DB = "shared_db" SHARED_CACHE = "shared_cache" INFRA_DNS = "infra_dns" INFRA_SERVICE_DISCOVERY = "infra_sd" class DependencyCriticality: STRONG = "strong" # 不可降级 WEAK = "weak" # 可降级 CONDITIONAL = "conditional" # 条件触发 # 依赖关系数据结构 class ServiceDependency: def __init__(self, caller, callee, dep_type, criticality): self....