降级是主动让步、资源再分配，熔断是被动止损、依赖实时指标；二者需分层设计、状态可控、协同生效，缺一不可。
微服务降级与熔断不是“加个注解就完事”的功能，而是需要分层设计、状态可控、兜底可靠的系统性能力。核心在于：降级是主动让步，熔断是被动止损；一个靠策略决策，一个靠实时指标触发。
降级要分场景做，不能一刀切
降级本质是资源再分配——把CPU、线程、数据库连接等有限资源，优先留给核心链路。常见做法有：
- 开关驱动降级：用配置中心（如Nacos、Apollo）动态控制功能开关。例如大促期间关闭“商品评价加载”“历史订单分页查询”，接口直接返回空列表或缓存快照，不走DB和远程调用。
- 自动降级：当系统关键指标超标（如JVM内存使用率＞90%、线程池活跃度＞95%、RT P99 ＞2s），自动触发预设的降级逻辑，比如跳过风控校验、简化地址解析、返回本地缓存的商品基础信息。
- 依赖失败连带降级：某个下游服务熔断后，上层服务不只是快速失败，还要主动切换行为——例如优惠券服务不可用时，下单页不报错，而是显示“暂无可用优惠”，并隐藏领券入口，避免用户反复点击重试。
熔断必须配对状态机+合理窗口
熔断不是“失败5次就拉闸”，它依赖精准的状态流转和统计口径。以Sentinel为例，关键配置逻辑如下：
- 三种触发策略选对场景：按平均响应时间（RT）适合防慢调用；按异常比例适合防崩盘（如数据库连接池满、HTTP 5xx突增）；按异常总数适合低频但关键调用（如支付回调确认）。
- 最小请求数（minRequestAmount）不能为0：否则低流量下抖动也会误熔。建议设为30～50，确保统计有代表性。
- 时间窗口（timeWindow）需匹配业务节奏：RT类熔断窗口建议设为10～30秒；异常比例类建议60秒起步，避免短时毛刺干扰；半开探测间隔不宜过长，否则恢复滞后。
- 半开状态必须有试探机制：不是等时间到了自动恢复，而是放行少量请求（如1～3个）验证下游是否真实可用。若全成功才闭合，否则重置计数器。
降级和熔断要协同，不能各自为政
单独启用其中一项效果有限，真正起作用的是组合策略：
- 熔断打开后，必须配套降级响应：不能只抛异常，要返回结构化fallback数据（如默认库存=999、支付方式仅支持余额），前端可据此渲染友好提示。
- 降级开关开启时，应同步关闭对应依赖的熔断监控：避免因主动跳过调用导致熔断器误判“调用失败率100%”。Sentinel可通过
ContextUtil.enter("resourceName", "fallback")隔离上下文。 - 网关层和业务层都要覆盖：网关做全局QPS限流+粗粒度降级（如整个活动页静态化），业务服务内做细粒度熔断（如单个Feign接口）+精准降级（如跳过某次日志上报）。
验证和运维不能缺位
上线前不验证，等于没做：
- 用混沌工程工具（如ChaosBlade）模拟下游超时、随机失败，观察熔断是否准时触发、降级是否生效、监控指标是否准确上报。
- 所有降级路径必须压测：确保fallback方法本身不耗时、不依赖故障组件、不会引发二次异常（比如降级里又去查DB，而DB正是故障源）。
- 建立熔断/降级告警：不只是“熔断器打开”，还要关联下游服务健康状态、本服务线程池水位、fallback调用量突增等维度，避免把“保护机制生效”当成“系统出问题”来救火。
