3. 熔断降级概念与核心思想
3.1 熔断与降级：一对孪生兄弟
先说说熔断。这个词你肯定不陌生，家里电路跳闸见过吧？电流过大，保险丝烧断，电路断开——这就是熔断。在密钥服务里，道理一模一样。当某个下游接口频繁报错、响应越来越慢，我们就主动切断对它的调用，不让问题扩散。
降级呢？说白了就是"有损服务"。核心功能保住了，非核心的先放一放。比如密钥服务里的缓存密钥读取接口挂了，我们可以暂时返回一个有效期较短的本地缓存密钥，而不是直接抛异常给用户。
这两者的关系，我个人的理解是：熔断是手段，降级是目的。熔断切断有问题的调用链路，降级在这条链路上提供一个"替补方案"。没有熔断的降级是盲目的，没有降级的熔断是粗暴的。
核心关系：熔断触发降级，降级是熔断后的标准动作。两者合在一起，才能保证系统在局部故障时整体依然可用。
3.2 为什么密钥服务离不开熔断降级
密钥服务有个特点：高敏感、高频率、高依赖。一次签名请求可能依赖 HSM、KMS、数据库、缓存等多个下游。任何一个下游出问题，都可能拖垮整个调用链。
我记得有一次线上事故。一个密钥服务的下游 HSM 集群因为网络抖动，响应时间从 5ms 飙升到 30s。因为没有熔断机制，所有请求都卡在等待 HSM 响应上。线程池很快耗尽，新的请求进不来，最终整个服务挂了。更可怕的是，依赖这个密钥服务的二十多个上游服务也跟着雪崩。
那次事故之后，我做的第一件事就是给所有下游调用加上熔断降级。你想想看，一个接口响应慢了，我们把它熔断掉，让请求快速失败或者走降级路径，最多影响这个接口本身，不会拖死整个进程。
血的教训：密钥服务的故障传播速度极快，没有熔断降级，一次小故障就能演变成大规模雪崩。这不是锦上添花，是保命手段。
3.3 核心思想：三态状态机
熔断降级最经典的设计就是三态状态机。所有实现——不管是 Hystrix、Resilience4j，还是我们自研的框架——底层都跑在这个模型上。
三个状态，每个状态的行为都不一样：
- CLOSED（关闭）：正常状态。请求正常通过，同时统计错误率和响应时间。一旦指标超标，立即切换到 OPEN。
- OPEN（打开）：熔断状态。请求直接被拒绝，不走下游调用。同时启动一个超时窗口，窗口到期后进入 HALF_OPEN。
- HALF_OPEN（半开）：试探状态。放少量请求过去，看看下游恢复了没有。成功了回到 CLOSED，失败了回到 OPEN。
这套状态机的精妙之处在于——它不需要人工介入。系统自己监控、自己切断、自己试探、自己恢复。我常说，好的熔断降级设计，应该让你"忘了它的存在"。
3.4 四个关键度量指标
状态机不会凭空跳转，它靠数据驱动。下面这四个指标，是我在实际项目里反复调过的东西：
| 指标 | 说明 | 推荐初始值 |
|---|---|---|
| 错误率阈值 | 连续错误次数或错误率达到此值，触发熔断 | 50% 或 10 次连续错误 |
| 请求量阈值 | 单位时间内的最小请求量，低于此值不触发熔断 | 20 次 / 10 秒 |
| 熔断超时窗口 | 熔断后等待多久，才进入半开试探 | 10 ~ 30 秒 |
| 半开试探数 | 半开状态下允许通过的最大试探请求数 | 3 ~ 5 次 |
这里有个细节我提一下。请求量阈值很多人会忽略，但它其实很重要。你想想看，如果某个接口本来请求量就很低，偶尔一次超时就把熔断触发了，那反而会降低可用性。设置一个最小请求量，让熔断只在"有足够样本"时才做判断。
3.5 降级策略的几种常见模式
熔断是切断了，但用户还在等着呢。降级策略就是给用户一个"不至于太难看"的回应。我把常见的模式整理了一下：
| 策略 | 说明 | 密钥服务适用场景 |
|---|---|---|
| 静态降级 | 返回固定的默认值 | 非敏感配置、公共密钥 |
| 缓存降级 | 返回上一次成功获取的缓存数据 | 密钥轮转、证书查询（读多写少） |
| 异步降级 | 将请求放入队列，延迟处理 | 批量签名、大量密钥生成请求 |
| 安全拒绝 | 返回明确的"服务暂不可用"响应 | 敏感密钥操作、权限校验 |
我个人最常用的是缓存降级。密钥服务有个特点——大部分密钥都有有效期，只要缓存还在有效期内，返回缓存数据既安全又实用。我曾经在一个支付密钥服务里用这个策略，把熔断期间的可用率从 0% 拉到了 95% 以上。
经验之谈：降级策略不是越复杂越好。优先选"无状态、无副作用"的策略，比如返回缓存值或默认值。避免在降级路径里再调用其他远程服务，那容易引发二次熔断。
3.6 实践经验与避坑指南
讲了这么多理论，最后分享几个我在项目里踩过的坑。希望能帮你少走弯路。
- 粒度不要一刀切。我曾经把所有下游接口放在同一个熔断器里，结果一个慢接口拖累了所有正常接口。正确的做法是按接口维度拆分，每个接口独立熔断。
- 阈值设得太激进。一开始我把错误率阈值设成 30%，结果线上稍微有点波动就频繁熔断。后来调到 60%，反而更稳了。阈值要根据实际监控数据动态调整，别拍脑袋。
- 忘了加请求量门槛。这个前面提过，低流量场景下一定要加。不然偶尔一次失败就跳闸，比不跳闸还难受。
- 半开试探数设太多。半开状态本质是"小心翼翼的试探"，设 3 次就够了。设多了等于变相全量放行，失去了保护意义。
- 没有监控和告警。熔断器切了，你得知道。我在生产环境里给每个熔断器的状态变化都加了日志和告警，一旦触发能第一时间响应。
重要提醒：熔断降级不是"配完就忘"的东西。它需要持续调优。每次线上故障复盘后，我第一件事就是检查熔断阈值合不合理、降级策略有没有生效。把它当成活的系统来维护，而不是一次性配置。
好了，这一章的核心东西都讲完了。三态状态机、四个度量指标、五种降级策略——这些就是你设计熔断降级时手里的"工具箱"。记住了，熔断不是目的，让系统在故障时依然可控，才是我们真正想要的。