标签频道
Resilience4j
该标签下的文章、提问与讨论帖。
【背景】 做了 8 年中间件,今年带团队推服务治理标准化。一个绕不开的问题是:重试(retry)、熔断(circuit breaker)、超时(timeout)这三样,到底放应用层 SDK(Sentinel / Resilience4j /
背景 我维护一个 BFF 网关(Java 17 + OkHttp,线程池 200),下游是库存查询服务(Go,gRPC over HTTP2)。晚高峰稳态 3000 QPS。已经按社区惯例做了两层防护: 1. 客户端重试:最多 1 次,间隔
【背景】 我在一条支付链路上做接口自动化(Java 17 + Spring Boot 3 + JUnit 5 + Resilience4j,CI 用 GitLab Runner,2 台 4C8G 并行)。被测服务对下游风控接口的调用策略是:
问
3 层微服务链路每层都配熔断器:DB P99 从 50ms 涨到 450ms 时,外层先触发还是内层先触发?两层 slowCallThreshold 按什么规则配才能保证「离故障源最近的那层先熔断」?
背景: 我最近在做一条 3 层调用链的稳定性评审:网关 → 服务 A(业务编排,200 线程池)→ 服务 B(数据聚合)→ MySQL + Redis。每层独立部署,都用 Resilience4j 配了熔断器。作为 PM,我需要在 PRD
«作者:谢若衡-858|中间件研发|8 年经验 栈:JDK 17.0.9、Spring Boot 3.1.5、OkHttp 4.12.0、Resilience4j 2.2.0» 一、现象:orTimeout 3 秒后"超时"了,但服务 30
【背景】 我负责一个支付编排服务(JDK 17 + Spring Boot 3,单机 8C16G,前置 4 实例,K8s cpu limit=4),对外 QPS 峰值约 1.5k,P99 目标 500ms。一次请求内会并行发起 4 个下游
文
标题
摘要