为什么需要熔断限流？从一次生产事故说起
核心观点: 熔断限流不是性能优化,而是系统稳定性的生命线。本文从一次真实生产事故出发,深度剖析为什么微服务架构必须要有熔断限流机制。 引子：2024年11月11日,一次惊心动魄的生产事故 事故背景 某电商平台,日常订单量10万单/天,流量1000 QPS。2024年双十一活动,预计流量增长3-5倍。技术团队提前扩容服务器,增加数据库连接池,准备迎接流量高峰。 然而,谁也没想到,活动开始仅10分钟,整个系统就崩溃了。 时间线复盘 10:00:00 - 活动正式开始 运营团队启动促销活动,用户涌入。前端监控显示流量快速攀升: 10:00:00 → 1,000 QPS（正常） 10:02:00 → 3,000 QPS（预期内） 10:05:00 → 8,000 QPS（超预期） 10:08:00 → 12,000 QPS（远超预期） 10:05:30 - 第一个异常信号 监控系统开始报警: [ALERT] 订单服务响应时间: 50ms → 800ms (P99) [ALERT] 订单服务线程池占用: 50/200 → 180/200 技术团队看到告警,以为是正常的流量压力,决定继续观察。 10:07:15 - 雪崩的开始 [CRITICAL] 订单服务响应时间: 800ms → 5000ms (P99) [CRITICAL] 订单服务线程池占用: 200/200 (100%,线程池耗尽) [ERROR] 用户服务调用超时: connection timeout after 5s 技术团队意识到不对劲,开始排查。日志显示: java.net.SocketTimeoutException: Read timed out at UserServiceClient.getUser(UserServiceClient.java:45) at OrderService.createOrder(OrderService.java:87) ... 原因找到了:用户服务的数据库出现慢查询(某个未加索引的查询,平时10ms,高峰期变成5秒)。 ...