4 降级策略设计：降级粒度、降级动作、降级链路与状态管理

降级策略的设计决定了系统在模块损坏、依赖失效或资源紧张时，能以多细的颗粒度、多快的速度、多明确的方式切换到安全模式。一个成熟的降级方案需要同时回答四个维度的问题：降级到什么范围？（粒度）、降级后做什么？（动作）、降级如何传递？（链路）、降级怎么管？（状态）。本章从系统分层与模块边界出发，逐一拆解这四个子问题，并给出选型权衡、落地步骤与验收标准。

4.1 降级粒度：从服务到参数的层次切割

降级粒度直接影响可用性与业务完整性的平衡。粒度越粗（如整个服务降级），实现越简单，但影响范围大；粒度越细（如单参数异常降级），保护越精准，但复杂度剧增。按照系统分层，常见的降级粒度包括：

4.2 降级动作：拒绝、默认值与缓存策略

降级动作是降级策略执行的“输出行为”。根据系统分层和业务容忍度，三类动作各有适用边界：

• 拒绝（失败降级）：直接返回错误码或抛出异常，调用方需自行处理（如重试、丢弃）。适用于非关键读/写请求，或链路已熔断时快速失败。缺点：客户端体验差，需配合客户端降级。
• 默认值（空降级）：返回预设的静态响应（如空列表、默认图片、标准文案）。适用于展示类接口，用户看到弱结果但仍可使用其他功能。实现成本低，但需业务方提供默认值定义。
• 缓存（缓存降级）：返回当前缓存中最新的可用数据，即使缓存已过时。适用于高并发读、数据一致性要求不高的场景（如排行榜、推荐流）。需设定缓存有效期的上限，防止数据严重滞后。

4.3 降级链路：从入口到下游的决策传导

一次请求会跨越多个系统分层（网关→应用→微服务→数据库/缓存）。降级链路的设计目标是：降级决策在整个调用链上保持一致性，且不产生死锁或反复升降。

典型降级链路包含三个核心节点：

1. 链路入口（网关/API）：聚合层根据全局降级开关和负载指标，决定是否快速降级整个路由，避免流量进入脆弱下游。
2. 业务组件（应用层）：在调用远程服务前，检查本地熔断器状态（Hystrix / Resilience4j）；若熔断则直接调用 fallback 方法，不再发起网络请求。
3. 数据层降级：若缓存、数据库或消息队列出现异常，由数据访问层抛出特定降级异常；上层捕获后转换为默认动作。

链路中还需处理“级联降级”：若上游已降级，下游需同步进入低负载模式（如减少连接池数、关闭预热任务），防止流量洪峰转向其他模块。

上图展示了典型降级链路：网关接收请求后交给降级决策组件，决策组件读取状态存储（熔断器、开关）和动作配置库，决定每个下游接口采用何种降级动作。下游服务B（用户服务）已被标记为熔断，因此直接返回默认值，不再发起实际调用。虚线代表状态反馈与配置下发，保证链路全局一致。

4.4 降级状态管理：开关、熔断与自动恢复

降级策略不能是一次性配置，必须能在运行时动态调整且可审计。状态管理包括三个核心要素：

• 降级开关：支持手动开关（通过配置中心如Apollo/Nacos下发）和自动开关（基于负载、错误率、RT阈值触发）。开关应具备优先级：手动 > 自动，且手动操作需记录审计日志。
• 熔断器状态机：每个降级粒度对应一个熔断器（closed/open/half-open）。半开状态下允许探测请求，恢复后自动关闭。状态变更需持久化到redis或DB，防止进程重启后丢失。
• 降级计数与采样：滑动窗口内统计调用量、失败率、平均耗时，用于触发自动降级。这些计数应与业务监控系统共享，避免重复采集。

4.5 落地步骤与验收标准