基础网关完全瘫痪时,yield应通过“内部try-catch+断线退避”双机制实现可控降级:1.在每个yield点做最小粒度隔离,含健康探针与带退避的fetch封装;2.退避用于暂停yield而非重试,期间持续产出降级态数据;3.yield支持核心、辅助、可缓存数据的多级降级路径;4.熔断状态需跨yield持久化并支持手动重置。

基础网关完全瘫痪时,yield(通常指异步生成器或协程中产出数据的环节)不能简单抛错中断,而应通过“内部 try-catch + 断线退避”双机制实现可控降级:既避免调用链崩溃,又防止重试雪崩,还能维持基本产出能力。
1. 在 yield 点包裹最小粒度的 try-catch
不要把整个异步生成器函数包在一个大 try 里,而应在每个可能触发远程调用的 yield 前后做隔离:
- 每次
yield前,先执行一次轻量级健康探针(如fetch('/health', { method: 'HEAD', cache: 'no-store' })),失败则跳过本次产出 - 若需真实请求,将 fetch 封装为带退避的独立函数,在其内部
try中捕获网络异常,并在catch中立即返回默认值或缓存快照,而非 throw 向上冒泡 - 确保
catch块只做三件事:记录降级日志、更新本地熔断状态、返回兜底数据(如空对象、静态模板、上一轮缓存结果)
2. 断线退避不是重试,而是“暂停 yield”
网关完全瘫痪时,重试毫无意义。此时退避算法的作用是主动抑制产出节奏,而非等待恢复:
- 首次探测失败后,启动指数退避计时器(如
minTimeout=500ms, factor=3, maxTimeout=30s),但不用于重试,而是用于控制下一次yield的最早时间点 - 在退避期间,生成器持续产出降级态数据(例如
{ status: 'degraded', timestamp: Date.now() }),保持流不断、连接不超时 - 退避期满后,不自动重连,而是先发一次探针;仅当探针成功,才恢复常规
yield;否则延长退避周期并升级告警级别
3. yield 本身支持多级降级路径
根据业务优先级,为不同数据类型配置差异化降级策略:
- 核心数据(如用户身份、订单状态):探针失败即 yield
null或抛出轻量错误(new DegradedError('auth_unavailable')),由消费方决定是否终止流 - 辅助数据(如推荐列表、统计指标):直接 yield 默认空数组或占位结构,不阻塞主流程
- 可缓存数据(如配置、地域信息):yield 上次成功响应的深拷贝副本,并标记
stale: true
4. 熔断状态需跨 yield 持久化
单次 yield 的降级不能孤立看待,要让状态在多次调用间延续:
- 使用闭包变量或 WeakMap 存储当前熔断窗口、最近失败次数、上次成功时间戳
- 当连续 3 次探针失败,触发“全链路熔断”,后续所有
yield直接走缓存+退避,跳过任何网络操作 - 熔断期间,允许外部手动调用
resetCircuit()强制恢复,适用于运维人工干预场景











