限流与熔断在单体服务里也该有

现象与影响

当某个非核心接口突遭爬虫高频请求时，单体服务内的 Tomcat 线程池（如 maxThreads=200）会被迅速耗尽。此时，日志疯狂打印 HikariCP 获取数据库连接超时的警告，导致同进程内的核心交易接口排队阻塞无法响应。最终整个应用假死，健康检查探针失败，Pod 被强制重启，引发全量业务中断。

根因分析

单体服务所有模块共享一个进程和线程池，某个慢接口（如导出报表）打满 Tomcat 的 200 个工作线程后，订单接口也拿不到线程，整服务雪崩。jstack 抓快照能看到大量线程 BLOCKED 在同一慢查询上。限流与熔断并非微服务专属，单体内同样需要靠信号量隔离业务路径，防止局部故障耗尽全局资源。

改进建议

建议引入 Resilience4j 替代手写逻辑。通过 AOP 切面对核心业务方法实现无侵入式限流，按 QPS 动态调整本地阈值。熔断需配置基于异常比例与慢调用率的降级策略。同时，将限流拒绝数与熔断状态暴露为 Micrometer 指标，接入 Prometheus 监控，实现单体架构下的可视化高可用保障。