故障隔离的核心目标是限制错误影响半径而非杜绝单点故障；需通过分级超时、熔断降级、资源硬隔离及解耦强依赖来实现。

故障隔离的核心目标不是阻止单点出错，而是让错误停在它该停的地方——不蔓延、不传染、不拖垮其他服务。

关键不在“防崩”，而在“限传”

单点服务崩溃本身无法完全避免，真正要控制的是它的影响半径。雪崩不是因为某个服务挂了，而是因为它挂了之后，上游还在不停重试、排队、占资源，把整个调用链的线程、连接、内存全堵死。

• 同步调用必须配分级超时：连接超时（500ms内）、读超时（按P95业务耗时×1.5~2倍设），超时立即释放线程，不等、不卡、不堆积
• 避免“默认无限等待”：HTTP客户端、RPC框架、数据库连接池都要显式配置超时，不能依赖系统默认值（常为-1或30秒以上）
• 对高波动服务（如大模型、OCR、向量检索），超时值需单独设置，不能和普通API共用一套参数

用熔断切断故障传播路径

熔断不是等服务彻底宕机才触发，而是在它“变慢+出错”初期就主动断开调用，给它喘息时间，也保护上游。

• 触发条件要包含慢调用比例（如P99>3秒的请求占比超50%），不能只看错误率
• 时间窗口建议用滑动窗口（如10秒内统计），比固定窗口更灵敏、更抗脉冲干扰
• 熔断打开后，必须配套降级逻辑（返回缓存、兜底数据、空响应、友好提示），否则用户看到的只是“服务不可用”

资源层面做硬隔离

一个服务吃光全局资源，等于给所有服务埋雷。必须从线程、连接、内存、GPU显存等维度划清边界。

• 线程池隔离：每个下游依赖使用独立线程池（如Hystrix command、Resilience4j bulkhead），避免A服务慢导致B服务无可用线程
• 连接池隔离：数据库、Redis、HTTP客户端连接池不共用，maxActive/maxTotal按服务SLA单独配置
• 大模型类服务额外隔离GPU显存与推理上下文，防止单个长请求卡死整个推理实例

架构上减少强依赖耦合

很多雪崩本质是设计出来的——把非核心功能做成同步强依赖，等于给主干道装了个随时爆裂的阀门。

• 非关键路径改异步：比如日志上报、行为埋点、通知推送，走消息队列，失败可丢弃或重试，不阻塞主流程
• 拆分核心与非核心接口：登录成功后“拉取个性化推荐”不应卡住登录响应，应并行发起+超时自动放弃
• 避免共享底层资源实例：多个业务共用一个Redis集群或同一个MySQL实例，一个慢SQL就能拖垮全部