后端架构

系统资源吃紧的时候,熔断和限流到底谁先动手?我们翻了 Resilience4j 的源码排了个序,不然两套逻辑真会打起来

凌晨三点订单服务崩溃,线程池满、CPU飙升,熔断器和限流器同时触发却相互冲突。问题根源在于Resilience4j中,注解模式下Bulkhead切面优先级高于CircuitBreaker,会先限流;但函数式组合时,decorate顺序决定执行先后。我们误将熔断器包在外层,导致线程池满引发的超时被熔断器计为失败,错误率虚高触发误熔断。解决方案是调整包裹顺序,让Bulkhead先执行,并统一使用注解模式,优化参数配置,最终消除误触发。

后端架构

我在 gRPC 拦截器里把重试、超时、熔断串成一条链,业务代码终于不用再贴满重复的容错片段了

gRPC 调用中重试、超时、熔断逻辑常被重复编写,导致业务代码臃肿。通过将三者拆分为独立拦截器,并按熔断→超时→重试的顺序串联成链,可形成单向流动的容错链路。熔断器避免无效调用,超时控制整体耗时,重试在时间窗口内执行。最终业务代码大幅精简,系统延迟降低,冗余容错模板被彻底消除。