故障隔离通过服务降级在资源紧张时保全主业务，本质是让非关键路径主动退让，集中资源保障下单、支付等主链路；需满足非核心、可妥协、有兜底三条件，开关须动态细粒度生效，并与限流、熔断协同构成三层防线。
故障隔离通过服务降级，在核心资源紧张时保全主业务，本质是“让非关键路径主动退让”，把线程、连接、CPU、数据库连接池等有限资源，集中留给下单、支付、登录这类不可替代的主链路。它不是等系统崩溃后再补救，而是提前设计好“哪些可以不要”，让系统在压力下依然能稳住底线。
降级是故障隔离的业务层执行动作
隔离仓（如独立线程池、信号量）管的是资源层面的物理隔离，而服务降级管的是业务逻辑层面的策略选择。两者配合才完整：
- 当某个弱依赖（比如推荐服务）开始变慢，隔离仓可防止它吃光所有线程；
- 但若它持续拖慢聚合层响应，降级就该介入——直接跳过调用，返回缓存值或静态兜底数据；
- 这样既避免了同步等待拉长整体耗时，也防止重试把流量反打到其他健康服务上。
核心资源紧张时，降级要盯准三个关键点
不是所有功能都能随便降，得看它是否满足“非核心、可妥协、有兜底”三个条件：
- 非核心：比如商品详情页的“用户浏览历史”“相似商品推荐”，不影响下单动作；
- 可妥协：比如库存校验从“实时强一致”降级为“默认有货+异步校验”，允许极小概率超卖；
- 有兜底：支付失败时返回“系统繁忙，请稍后重试”，而不是空白页或500错误。
降级开关必须支持动态生效，不能重启
资源紧张往往突发，靠改代码、发版本来不及。真实可用的降级必须依赖配置中心（如Nacos）实时推送：
- 开关粒度要细：按接口（如/order/create）、按场景（如大促期间）、按用户等级（如VIP不降级）；
- 生效要秒级：配置变更后，应用内监听器自动刷新状态，无需重启进程；
- 要有回滚能力：降级后发现误判，10秒内可关闭开关，流量无缝恢复。
和熔断、限流协同，构成三层防线
单靠降级不够，它需要和其他机制配合形成防御纵深：
- 限流在入口拦住超额请求，防止雪崩起点；
- 熔断在调用下游时自动切断已确认故障的依赖，避免无效等待；
- 降级在业务层做最终决策：就算下游没完全挂，只要它拖慢了主链路，就主动绕过。
