1. 课程导论：服务降级的概念、为什么需要降级、降级与熔断/限流的区别、课程目标与学习路径
1.1 服务降级的概念
服务降级（Service Degradation / Graceful Degradation）是指在系统面临过载、依赖故障或资源紧张时，主动牺牲部分非核心功能或降低服务质量，从而保障核心业务链路可用性和整体系统稳定性的策略。它不是“系统崩溃后的被动修复”，而是“有预谋的主动收缩”。
核心思想： 在有限资源下，做“减法”保“命脉”。宁可让部分用户看到“当前服务繁忙，请稍后再试”，也不能让所有用户都看到“500 Internal Server Error”。
降级策略通常分为三个层次：
- 业务降级： 关闭非核心功能（如推荐、评论、积分），仅保留下单、支付等核心交易链路。
- 功能降级： 降低功能质量（如图片压缩、视频降码率、搜索结果只返回缓存数据）。
- 系统降级： 释放资源（如关闭日志采集、关闭监控采样、减少线程池大小）。
1.2 为什么需要降级
在分布式系统架构中，故障是常态，而非异常。以下场景迫使我们必须设计降级策略：
| 场景 | 问题描述 | 无降级后果 |
|---|---|---|
| 依赖服务故障 | 数据库、缓存、第三方API不可用 | 级联故障，整个调用链雪崩 |
| 突发流量洪峰 | 秒杀、热点事件导致流量远超容量 | 系统过载，响应超时，最终崩溃 |
| 资源耗尽 | CPU、内存、连接池、线程池耗尽 | OOM、死锁、拒绝服务 |
| 发布与变更 | 新版本引入Bug或性能退化 | 全量用户受影响，回滚耗时 |
| 成本控制 | 非核心功能消耗大量计算资源 | 资源浪费，核心链路得不到保障 |
关键认知： 降级不是“失败”，而是“有管理的失败”。在SRE实践中，降级是保障SLA（服务等级协议）的最后一道防线。没有降级策略的系统，本质上是一个“裸奔”的系统。
1.3 降级与熔断、限流的区别
降级、熔断、限流是服务治理的“三驾马车”，但三者目标不同，经常被混淆。下表清晰区分：
| 维度 | 降级 | 熔断 | 限流 |
|---|---|---|---|
| 核心目标 | 保障核心功能可用 | 防止故障扩散 | 控制流量速率 |
| 触发条件 | 资源紧张、依赖故障、业务决策 | 错误率达到阈值（如50%请求失败） | QPS/TPS超过预设阈值 |
| 动作 | 关闭/简化非核心功能 | 快速失败，断开调用链路 | 排队、拒绝、限速 |
| 恢复方式 | 手动或自动恢复，通常有延迟 | 半开探测，成功后自动关闭 | 流量下降后自动恢复 |
| 典型实现 | 配置中心开关、业务逻辑分支 | Hystrix、Resilience4j、Sentinel | 令牌桶、漏桶、滑动窗口 |
| 对用户影响 | 部分功能不可用，核心功能正常 | 请求快速失败，返回降级响应 | 部分请求被限流，返回429 |
实战口诀： 限流是“挡”，熔断是“断”，降级是“退”。三者常组合使用：限流挡住大部分流量，熔断切断故障依赖，降级退回安全模式。
1.4 课程目标与学习路径
本课程旨在帮助架构师和SRE工程师建立完整的服务降级设计能力，从理论到工程落地，覆盖全生命周期。
课程目标
- 掌握降级策略设计方法论： 能够根据业务场景设计合理的降级等级和触发条件。
- 理解降级与系统架构的关系： 在微服务、分布式、云原生架构中落地降级。
- 具备工程实现能力： 使用配置中心、Sentinel、Resilience4j等工具实现降级。
- 建立优雅退出机制： 从降级到系统关闭，保证数据一致性和资源释放。
- 通过案例积累实战经验： 电商、金融、社交等场景的降级案例复盘。
学习路径
| 阶段 | 章节范围 | 核心内容 |
|---|---|---|
| 基础篇 | 第1-5章 | 概念、降级等级设计、降级策略分类、降级与架构的关系 |
| 进阶篇 | 第6-15章 | 降级实现技术（配置中心、Sentinel、Hystrix）、降级与熔断限流组合、降级测试 |
| 实战篇 | 第16-25章 | 电商、金融、社交、IoT等场景降级案例、降级自动化与编排 |
| 高阶篇 | 第26-30章 | 优雅退出机制、降级与混沌工程、降级治理平台建设 |
学习建议： 每章结束后，建议在本地搭建一个简单的Spring Boot + Sentinel环境，将章节中的降级策略动手实现一遍。理论结合实践，才能真正掌握降级设计的精髓。