北京
大促流量冲到平时的10倍，四分钟后支付服务熔断器跳闸，错误率飙到92%，支付链路P99延迟从200毫秒涨到14.2秒。但最反直觉的是：熔断器本身没出问题，它完全按设计工作了。
这是一次真实的故障复盘。Resilience4j的默认配置在高压下暴露了什么短板，以及四个改动如何让下一次大促变得"无聊"。
技术栈很标准：Spring Cloud Gateway做网关，Keycloak管JWT认证，Resilience4j包裹所有出站调用。支付服务同步调Stripe，订单服务同步调支付。PostgreSQL存订单，Redis存熔断状态，Kafka做死信队列。六个服务，五个熔断器，共用一个紧绷的线程池。
基线流量约1000 RPS，大促峰值冲到10243。边缘层扛住了——NGINX正常，限流器优雅降级，CDN能缓存的都缓存了，网关路由也没问题。崩在支付服务这一环。
Stripe的P99延迟在高压下从健康的800毫秒涨到14.2秒。这个数字单独看不算灾难，但算笔账就明白了：每个支付线程从等不到1秒变成等14秒，固定线程池的吞吐在熔断器感知到之前早就崩了。
当时的熔断器配置：失败率阈值50%，滑动窗口100次调用，基于计数，开启状态持续30秒，半开状态允许10个试探调用。50%阈值意味着要等50次失败才跳闸。10倍流量叠加超时，用户对着转圈界面等了大概四分钟。熔断器打开时，线程池已经98%饱和。
唯一阻止全平台宕机的是第8步加的隔离舱。如果没有按端点做隔离，一个慢Stripe会吃光网关所有线程，用户登录请求会排在死掉的支付调用后面。
文档里的熔断器是个干净的三状态图。生产环境嘈杂得多：状态转换事件需要实时打日志、上监控，否则你根本不知道它什么时候从CLOSE变OPEN，又从OPEN变HALF_OPEN。
四个改动清单：滑动窗口从100调到10，失败率阈值从50%调到30%，加上基于时间的滑动窗口，以及最关键的——给每个下游端点配独立线程池。下次大促，监控曲线平得像湖面。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
