核心思路是防御性设计，重在“防”而非“救”：通过限流卡住异常源头、熔断切断失效依赖、降级保障主干可用，三者递进协同，主动拦截雪崩征兆而非被动处理异常。
核心思路不是“处理异常”，而是提前拦截异常发生的条件——当系统已出现异常征兆（如响应变慢、失败率升高、线程堆积），就主动限流、熔断、降级，避免异常扩散成雪崩。这属于防御性设计，重点在“防”而非“救”。
限流：卡住异常源头的流量入口
突发异常往往伴随请求激增（比如下游服务变慢引发上游重试风暴），此时需在最外层快速削峰：
- 网关层统一限流：用 Spring Cloud Gateway + Sentinel 或 Resilience4j，在 API 入口按 IP、用户 ID、接口路径设置 QPS 阈值（如 /order/create 接口限制 500 QPS），超限直接返回 429，不进业务逻辑
-
关键服务内嵌限流：对易出问题的模块（如短信发送、日志上报）单独加信号量或令牌桶，例如用
Semaphore(3)控制并发调用第三方短信接口的线程数，避免因短信服务抖动拖垮整个订单流程 - 拒绝策略要明确：不建议简单 sleep 或排队等待，优先选“快速失败”（返回预设提示）或“异步化”（转 MQ 延后处理），防止线程池被占满
熔断：切断已失效的依赖链路
当某个下游服务持续异常（如数据库慢查、远程接口超时），熔断器应自动跳闸，阻止请求继续打过去：
Java Linux版
下载
Java Linux版下载入口，提供 Oracle JDK 26.0.2 官方 Linux 安装包、Java 环境配置、JDBC 数据库连接和 Java 服务端开发相关信息。
- 基于失败率/响应时间触发：例如 Sentinel 设置“10 秒内失败率 ≥ 50% 且请求数 ≥ 20”即进入 OPEN 状态，后续所有请求立即失败，不发往下游
- 半开状态试探恢复：OPEN 持续 30 秒后自动转 HALF_OPEN，只放行少量请求（如 10%）探测下游是否恢复；若成功则 CLOSE，否则重置为 OPEN
- 熔断必须带 fallback：不能只抛异常，要提供兜底逻辑，比如远程获取用户信息失败时，返回缓存中的旧数据或默认头像，保证主流程可继续
降级：为非核心路径准备 Plan B
异常发生时，牺牲体验换可用性，确保主干功能不中断：
- 按业务重要性分级降级：下单页保留“提交订单”按钮，但临时隐藏“优惠券推荐”“物流预估”等非必需模块；支付页可关闭“分期选项”，但必须保障“立即支付”可用
- 降级开关要可动态控制：通过配置中心（如 Nacos）管理降级开关，运维可在监控发现 CPU > 90% 时一键开启全站降级，无需重启服务
- 降级逻辑需独立验证：降级代码不能依赖异常服务，例如远程调用失败时，fallback 方法应从本地缓存或静态配置读取默认值，避免二次失败
协同机制：三者不是孤立运行
真实场景中，它们是递进配合的保护链：
- 请求先过 限流（判断当前整体负载是否超标）
- 通过后调用下游，若下游已 熔断，则跳过远程调用，直接走降级逻辑
- 若未熔断但调用失败，且符合降级条件（如超时、特定异常码），再触发 降级
- 所有动作需记录日志和指标（如限流次数、熔断触发次数），用于事后分析根因
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
