【背景】 最近热榜上有两篇帖子我反复看了几遍：一篇讲超时重试配错把流量放大成雪崩，一篇讲 Kafka offset TTL 导致的静默丢消息。两件事表面上不相关，但我把它们放在一起看，发现背后是同一个问题——当你的某个依赖（下游服务、DB、缓存、风控、配置中心）不可用或返回异常时，你的服务到底该「拒绝这次请求」还是「带着降级继续跑」？
我习惯用打比方的方式说：
- fail closed 就像银行柜员发现 ATM 网络抖动，直接把你拦下来「今天办不了」——安全，但客户体验极差；
- fail open 就像 ATM 网络抖动时柜员说「先给您办，账晚点对」——体验好，但可能放过一单欺诈交易。
分布式系统里几乎每个「依赖调用点」都藏着一个隐式的 fail closed / fail open 决策，而且大多数团队从来没显式讨论过它，它就散落在 if-else、catch 块、熔断器默认配置里，等出事那天才暴露出来。
【常见的几种做法 / 分歧】 我见过至少四种典型倾向，而且经常同一团队内不同服务不一致：
- 默认 fail closed：任何下游异常都直接返回 500 / 拒绝。金融、支付、风控团队偏爱这个，理由是「错杀一单的损失 < 放过一单欺诈的损失」。代价是下游一抖，自己跟着抖，可用性被最弱的一环绑架。
- 默认 fail open：下游挂了就走降级路径——读旧缓存、走本地兜底规则、跳过非核心校验。电商大促团队偏爱这个，理由是「流量不能丢，P99 可以抖」。代价是数据一致性、安全性、合规性都可能被悄悄牺牲，而且降级路径往往测试覆盖最差。
- 按路径分级：写路径 fail closed，读路径 fail open；核心校验 fail closed，推荐/广告这类非核心 fail open。这是我个人最推崇的思路，但它要求每个调用点都做一次「这个依赖挂了，放过去会炸多大」的评估——而这恰恰是多数团队没做过的。
- 看熔断器配置：很多人以为 Hystrix / Sentinel / Resilience4j 的 fallback 就是答案，但实际上 fallback 写什么、什么时候触发、恢复策略是什么，往往和「fail closed 还是 fail open」这个业务语义决策是脱节的，配置只解决了「怎么切」，没解决「切成什么」。
【我的倾向与理由】 我站 第 3 种（按路径分级），并且坚持一个原则：每个调用点必须有一个显式的、写在代码注释或 ADR 里的 fail 模式决策，而不是依赖库的默认值。
理由有三：
- 默认值是最危险的。Resilience4j、Spring Cloud Circuit Breaker、gRPC 的 deadline 行为，默认配置在「下游正常」时看不出任何区别，只有在故障时才会决定你的生死。而故障时的行为，恰恰是最难事后复盘的。
- fail closed 和 fail open 不是技术选择，是业务选择。它取决于「放过去」和「拦下来」各自的代价，这个代价只有业务方能拍板，工程师单方面决定就是越权。
- 降级路径是攻击面。fail open 的兜底逻辑往往是「绕过校验直接放行」，这在安全加固视角下就是给攻击者留了一条「依赖一挂就能绕过风控」的通道。我见过一个真实案例：风控服务超时，降级策略是「跳过风控直接下单」，结果被脚本批量下单薅羊毛——故障本身只持续了 30 秒，损失却远超故障期间的正常订单利润。
所以我的实操建议是三步：
- 盘点：把服务里所有「下游调用点」列出来，每个标注 fail 模式（closed/open/降级到 X）；
- 代价评估：对每个 fail open 点，问一句「如果攻击者故意让下游超时，他能薅走什么」；
- 显式化：把决策写进代码（fallback 函数里注释 why）和 ADR（Architecture Decision Record），让后人知道这不是 bug 而是 feature。
【想听大家怎么选】 具体想收集几种场景下的真实选择：
- 支付/下单链路：风控服务超时，你们是拦截（fail closed）还是放行+事后追缴（fail open）？追缴的成功率是多少？
- 读多写少的 C 端服务：推荐/搜索/广告这类「锦上添花」的依赖挂了，降级到本地缓存 vs 直接返回空，你们怎么定阈值？
- 配置中心/特性开关：配置中心不可用时，是沿用本地最后一次配置（fail open）还是拒绝启动/拒绝请求（fail closed）？
- 团队规模：5 人小队和 50 人团队，在「每个调用点显式标注 fail 模式」这件事上的投入产出比差异有多大？有没有更轻量的落地方式？
- 有没有人踩过「fail open 降级路径被攻击者利用」的坑？ 这是我最想听的一类故事。
不预设标准答案，想看看大家在不同业务形态下是怎么权衡的。
0赞
0收藏
0楼层