熔断机制通过统计失败率等指标在异常达阈值时快速失败以避免资源耗尽；限流保护通过qps或并发数控制入口流量；二者需与降级协同，在网关层、服务内部分层设防，并依赖压测验证与可观测性保障实效。
熔断机制：防止故障雪崩
当某个微服务依赖的下游服务持续超时或失败，Java应用若不加干预，会不断重试并堆积线程和连接，最终拖垮自身。熔断器（如Sentinel、Resilience4j或Hystrix）通过统计失败率、响应时间等指标，在异常达到阈值时自动“跳闸”，将后续请求快速失败（fallback），避免资源耗尽。
关键配置要点：
- 设置合理的失败率阈值（如50%）和最小请求数（如20次），避免误熔断
- 定义熔断开启后的休眠期（如60秒），到期后尝试半开状态，放行少量请求验证下游是否恢复
- 务必提供有意义的fallback逻辑，比如返回缓存数据、默认值或降级页面，而非简单抛异常
限流保护：控制入口流量压力
限流不是限制用户，而是防止突发流量打垮服务。Java微服务常用QPS（每秒请求数）或并发线程数作为限流维度，常见于API网关（如Spring Cloud Gateway + Sentinel）或服务内部（如@SentinelResource注解）。
落地建议：
立即学习“Java免费学习笔记（深入）”；
- 区分核心接口与非核心接口，为登录、下单等关键路径设置更宽松的限流阈值，对查询类接口可收紧
- 采用滑动窗口算法（如Sentinel的滑动时间窗）替代简单计数器，避免临界突刺问题
- 限流触发时返回429状态码及清晰提示，配合前端做友好重试或排队，而不是静默丢弃请求
组合使用：熔断+限流+降级协同防御
单一机制效果有限。例如，限流能防洪峰，但无法应对下游服务缓慢导致的线程阻塞；熔断能止损，但不解决上游过载问题。生产中需分层设防：
- 网关层做全局QPS限流和IP/用户级黑白名单，拦截恶意或异常流量
- 服务内部用熔断器隔离不稳定依赖，并配合超时控制（feign.client.config.default.connectTimeout=3000）
- 关键业务方法标注fallback方法，同时记录熔断/限流日志，接入监控告警（如Prometheus + Grafana）
生产注意事项
机制有效依赖可观测性与及时响应。上线前必须压测验证阈值合理性，避免一刀切配置；运行中要关注Sentinel控制台或Resilience4j的Metrics端点，发现频繁熔断需排查下游性能瓶颈，而非仅调高阈值。
不要把熔断当成兜底方案——它暴露的是架构脆弱点；也不要把限流当成性能优化手段——它只是最后的安全阀。
