3. 服务降级策略：业务降级、功能降级、数据降级、接口降级的场景与设计原则

服务降级是分布式系统在面临压力或故障时，主动牺牲部分非核心功能或数据质量，以保障核心业务可用性的关键手段。在事件驱动架构中，降级策略需要与消息流、事件处理链路深度绑定。本章将系统阐述四种降级维度的典型场景与设计原则。

3.1 降级策略的四维分类

根据降级影响的范围和深度，可将服务降级划分为四个层次：业务降级、功能降级、数据降级和接口降级。下表对比了各维度的核心差异：

3.2 业务降级：保核心、弃边缘

业务降级是最宏观的降级手段，指在系统整体资源紧张时，主动暂停或简化非核心业务流程，将计算和存储资源集中供给核心交易链路。

• 典型场景：电商大促期间，关闭“用户积分兑换”、“商品推荐日志采集”等非核心事件处理；仅保留“下单”、“支付”、“库存扣减”核心事件流。
• 设计原则：
  • 业务优先级分级：将业务场景划分为 P0/P1/P2 等级，P0 永不降级。
  • 事件过滤：在消息中间件消费端按业务类型进行过滤，低优先级事件直接丢弃或写入死信队列。
  • 补偿窗口：降级期间产生的事件需记录补偿日志，待恢复后通过事件重放机制进行回补。

# 事件驱动架构中的业务降级过滤器示例
class BusinessDegradationFilter:
    def __init__(self, config_center):
        self.config = config_center
        self.core_events = {"order_created", "payment_success", "inventory_deducted"}

    def should_process(self, event: dict) -> bool:
        if self.config.get("degradation_mode") == "business":
            # 非核心事件直接丢弃，仅保留 P0 事件
            return event.get("event_type") in self.core_events
        return True

3.3 功能降级：关模块、保响应

功能降级聚焦于系统内部的非关键功能模块。当某个功能依赖的外部服务或资源出现故障时，主动关闭该功能，避免故障扩散。

• 典型场景：商品详情页的“用户评价”模块依赖的评分服务超时，降级后直接隐藏评价区域，返回静态占位符。
• 设计原则：
  • 功能开关化：每个可降级功能对应一个配置开关，支持秒级动态切换。
  • 静默失败：降级后的功能不应抛出异常，应返回空数据或默认 UI 组件。
  • 依赖隔离：使用舱壁隔离模式，为每个功能模块分配独立的线程池或资源池。

3.4 数据降级：降精度、保写入

数据降级是在数据层面临压力时，主动降低数据写入的实时性、一致性或精度要求，以换取系统的持续写入能力。

• 典型场景：秒杀活动中，库存扣减从“强一致性”降级为“最终一致性”，允许短暂超卖，后续通过异步对账修正。
• 设计原则：
  • 一致性降级：从强一致性降级为最终一致性，从实时写入降级为批量写入。
  • 采样降级：日志、监控、埋点等数据从全量采集降级为按比例采样。
  • 缓存兜底：数据库不可用时，直接返回缓存中的过期数据，并标记数据版本。

# 数据降级：从实时写入切换为批量写入
class DataDegradationWriter:
    def __init__(self):
        self.batch_buffer = []
        self.batch_size = 100

    def write(self, record: dict):
        if self._is_degraded():
            self.batch_buffer.append(record)
            if len(self.batch_buffer) >= self.batch_size:
                self._flush_batch()
        else:
            self._write_realtime(record)

    def _is_degraded(self) -> bool:
        # 根据数据库连接池使用率或写入延迟判断
        return True  # 降级状态

3.5 接口降级：快速失败、默认返回

接口降级是最底层的降级手段，直接作用于服务对外暴露的 API 或内部 RPC 调用。当接口调用失败或超时时，返回预设的默认值或错误码，避免调用方长时间阻塞。

• 典型场景：用户信息查询接口超时，降级后直接返回“默认用户对象”（如游客身份），保证页面可渲染。
• 设计原则：
  • 默认值兜底：每个接口必须预设合理的 fallback 返回值。
  • 快速失败：设置严格的超时时间（如 50ms），超时即降级，不重试。
  • 熔断联动：接口降级通常与熔断器配合使用，熔断器打开后直接触发降级逻辑。

3.6 降级策略设计总览

下图展示了四种降级策略在事件驱动架构中的层次关系与触发链路：

3.7 降级策略的协同与优先级

在实际系统中，四种降级策略并非孤立执行，而是按优先级顺序协同工作。推荐的设计原则如下：

1. 先接口、再功能：接口降级成本最低，优先触发；若压力未缓解，再关闭非核心功能模块。
2. 再数据、后业务：数据降级可缓解存储压力；业务降级影响面最大，作为最后手段。
3. 自动降级 + 人工确认：系统自动触发降级后，需通过告警通知 SRE 确认，避免误降级。
4. 降级事件可追溯：每次降级动作必须生成降级事件（DegradationEvent），记录降级原因、维度、时间戳，供事后审计和补偿使用。