背景 最近复盘一起下游故障：上游 64 个实例各自挂了本地熔断器，阈值都是「错误率 > 50% 且最小请求数 20」。下游其实已经半死不活，但每个实例的流量只占 1/64，单实例统计窗口里根本没攒够 20 个请求，熔断一个都没触发；等 P99 报警时，下游已经被 64 倍的总流量打穿了。反过来也有人踩过「全局状态」的坑：限流计数走 Redis，Redis 主从切换那 2 秒，限流形同虚设，雪崩直接穿透到 DB。
常见的几种做法与分歧
- 纯本地状态（Sentinel / Hystrix 默认形态）：零外部依赖、决策延迟低，但阈值必须按「单实例视角」设计，错误率类指标在长尾实例上天然失灵，QPS 类指标则要除以实例数——实例数一变（弹性扩缩容），全局行为就漂移。
- 全局共享状态（Redis 计数 / 集中式熔断决策）：总量精确，但引入一次额外网络往返：限流判断本身有了网络依赖，Redis 抖动时是 fail-open 还是 fail-close？fail-open 等于没限，fail-close 等于 Redis 成了新的单点。
- 网关层统一限流 + 服务层只做兜底：入口总量可控，但网关看到的是「请求数」，不是「资源消耗」——一个重查询接口和一个取缓存接口在网关眼里是同一个 token。
- 混合：本地快速熔断 + 全局慢速同步：本地先断，异步把错误率广播给其他实例（gossip / 事件总线），牺牲一致性换可用性。实现复杂度明显上一个台阶。
我的倾向与理由 我倾向「本地为主、全局为辅，且两者职责分开」：
- 熔断用本地：熔断的语义是「保护本实例和下游」，本地决策延迟最低，且下游挂掉时所有实例的错误率都会上升，本地统计足够触发，代价只是各实例触发时间错开几十毫秒——对下游反而是好事（半开试探不会同步）。
- 限流用全局（或网关）控总量 + 本地控每实例：限流的语义是「保护系统总量」，只有全局视角才谈得上总量；但全局限流器本身必须可降级，Redis 不可用时自动退化为本地限流（宁可限松一点，不能 fail-close 把入口打死）。
- 一个具体建议：错误率熔断的「最小请求数」不要拍脑袋，按
单实例峰值 QPS × 统计窗口反推，保证窗口内能攒够样本。64 实例、单实例峰值 50 QPS、10s 窗口 → 每实例 500 个样本，此时最小请求数设 20~50 都合理；但如果单实例峰值只有 2 QPS，20 个样本要攒 10 秒，熔断就已经慢了。
想听大家聊聊
- 你们线上熔断器是本地还是全局？出过「阈值配了但从没触发」或「一触发就全服务同时熔断」的坑吗？
- 全局限流依赖 Redis/etcd 时，fail-open / fail-close 你们怎么定的？有没有「限流器自己成为瓶颈」的实测数据（QPS 打满时多出的 RT）？
- 弹性伸缩场景下，本地阈值除以实例数这个做法，你们是怎么解决「实例数动态变化」的？
- 「slow call」（慢但成功）该不该计入熔断？按 RT 熔断和按错误率熔断，你们线上是二选一还是叠着用？
0赞
0收藏
0楼层