雪崩效应是服务调用链中某节点响应变慢或失败，导致上游资源持续堆积并拖垮整体；代码中表现为正常http调用（如resttemplate.getforobject）却耗尽线程池，需通过resilience4j的record-failure-expression显式纳入耗时判断并配合timelimiter超时控制来防御。
什么是雪崩效应，它在代码里长什么样
雪崩效应不是某个报错，而是服务调用链上一个节点卡住或失败后，引发上游线程/连接/资源持续堆积，最终拖垮整个调用链。典型现象包括：java.lang.OutOfMemoryError: unable to create new native thread、HTTP 调用超时陡增、HystrixRuntimeException 大量抛出、Prometheus 上 http_client_requests_seconds_count{outcome="TIMEOUT"} 突然飙升。
它常发生在下游服务响应变慢（比如数据库慢查询、外部 API 延迟升高）但上游没做任何熔断或降级时。真实代码里，你可能只看到一段看似正常的 restTemplate.getForObject() 或 webClient.get().retrieve().bodyToMono()，但它正默默把线程池耗尽。
Spring Cloud 中最易漏掉的熔断配置项
很多人加了 @EnableCircuitBreaker 或用了 @CircuitBreaker 注解，却忘了关键开关：熔断器默认不监控慢调用，只看失败率。也就是说，下游服务从 200ms 慢到 3s，只要没抛异常，熔断器就“视而不见”。
必须显式开启响应时间阈值判断：
resilience4j.circuitbreaker.instances.myapi.sliding-window-type=TIME_BASED resilience4j.circuitbreaker.instances.myapi.sliding-window-size=60 resilience4j.circuitbreaker.instances.myapi.failure-rate-threshold=50 resilience4j.circuitbreaker.instances.myapi.wait-duration-in-open-state=30s resilience4j.circuitbreaker.instances.myapi.record-duration=10s resilience4j.circuitbreaker.instances.myapi.record-failure-expression='(#result == null || #result.status != 200 || #exception != null || T(java.time.Duration).ofMillis(#duration).compareTo(T(java.time.Duration).ofSeconds(2)) > 0)'
重点是最后一行：record-failure-expression 里必须包含对耗时的判断（如本例中超过 2 秒即记为失败），否则慢调用永远进不了熔断统计窗口。
Feign 客户端超时设置的三重陷阱
Feign 默认不启用超时控制，且它的超时参数和底层 HTTP 客户端（OkHttp / Apache HttpClient）存在两层映射关系，极易配错。
常见错误包括：
- 只配了
feign.client.config.default.connect-timeout，漏掉read-timeout—— 连接建得快，读响应卡死照样雪崩 - 用了 OkHttp，却按 Apache 的方式配
feign.httpclient.connection-timeout，实际无效 - 全局超时设了 1s，但某个接口实际需要 3s，结果被强制中断，触发大量 fallback，反而加剧下游压力
推荐做法：关闭 Feign 自带的超时（设为 -1），统一由 Resilience4j 的 TimeLimiter 控制，避免两套超时逻辑打架。例如在 @CircuitBreaker 注解旁加 @TimeLimiter(name = "myapi")，并在配置中定义 resilience4j.timelimiter.instances.myapi.timeout-duration=2s。
本地模拟雪崩的最小可行命令
不启动整套环境，也能快速验证防御逻辑是否生效。核心思路：让某一个下游服务“可控地变慢”或“随机失败”。
用 curl + sleep 快速起一个假服务：
python3 -c "from http.server import HTTPServer, BaseHTTPRequestHandler; \
class H(BaseHTTPRequestHandler): \
def do_GET(s): \
import time; time.sleep(3); \
s.send_response(200); s.end_headers(); s.wfile.write(b'ok') \
HTTPServer(('localhost', 8081), H).serve_forever()" &
然后在你的微服务里调用 http://localhost:8081，观察 CircuitBreaker.State 是否从 CLOSED 变成 OPEN，以及 fallback 方法是否被触发。注意别用 Thread.sleep() 在生产代码里模拟延迟 —— 它会直接阻塞线程，掩盖异步场景下的真实问题。
真正难处理的，是那些没有明确失败信号、只是越来越慢的依赖 —— 它们不会触发传统熔断，却最擅长悄悄拖垮系统。这类情况必须靠 record-failure-expression 和主动超时双保险，少一个都容易漏防。
