📚 课程目录第1章服务降级概述

第 1 章服务降级概述

说到服务降级，我得先承认一件事——我干这行头两年，根本没把它当回事。总觉得把功能做出来就够了，哪来那么多降级不降级的？直到有一次线上事故，核心接口被刷爆，整个系统像多米诺骨牌一样瘫了整整四十分钟。那之后我才真正明白：降级不是锦上添花，是保命用的。

这一章我们就把服务降级讲透。到底是什么、为什么需要、以及它和熔断、限流到底有什么区别。我保证不讲虚的，全是实践里磨出来的经验。

简单说，服务降级就是在系统压力过大或依赖出现故障时，主动放弃部分非核心功能，保证核心业务还能跑。

举个我遇到的例子：你做的电商系统，有商品详情、下单、支付、推荐。如果数据库扛不住了，你还让推荐模块去查用户画像？不，直接关掉推荐，返回一个静态“猜你喜欢”列表。下单和支付继续正常走。这就是降级。

降级不是错误，是预设的“退路”。你提前想好了：流量超标时我砍掉哪些功能，返回什么数据，记录什么日志。说白了就是——关掉几扇门，保住主厅。

    关键点： 降级是主动的、有计划的、且通常有“半秒或同步”的回退逻辑，不是系统崩溃后的被动行为。

我把它总结成三个必须降级的场景——其实你在项目中大概率也遇到过：

防止雪崩 —— 调用链中一个节点慢，连累上游全部阻塞，最终整个集群挂掉。降级能切断“病根”，不让问题扩散。
保障核心业务 —— 比如支付系统的扣款和余额查询必须保，而订单评分、用户积分这些可以暂时忽略。你想想看，用户少看几条推荐最多不爽，但扣款失败是要出大事的。
应对流量尖峰 —— 秒杀、活动、突发热点。本来系统只能扛 5000 QPS，瞬间冲到 2 万。降级非核心接口，留出资源给主流程。

我曾经踩过的坑： 某个项目只给接口配置了限流，没做降级。结果限流一刀切，把普通用户也拦在外头，接口返回了一堆“服务器忙，请稍后再试”。用户体验极差，客服电话打爆。后来加了降级策略：限流后对部分用户直接返回旧缓存，至少能看东西，不让他空手而归。

这三个词经常被混着用，但职责完全不同。我习惯用一个类比：

下面这张表帮你分清三者的区别，建议收藏：

我个人的经验： 在同一个项目中，这三者常常一起用。限流是第一道防线，挡住突发的洪峰；熔断是最后一道盾，扛不住就断；而降级是中间层的“软控制”，让你在压力下依然保持体面。

你可以把降级看作一种“策略”，限流和熔断是它的“执行工具”。例如，限流器发现流量超标后，可以触发降级开关，关闭不需要的功能。熔断器检测到下游不可用后，也可以启动降级，返回本地缓存。它们是协作关系。

根据我在多个项目里的实践，降级一般分这么几类：

你可能会问：降级返回什么？我见过最蠢的实现是直接返回 null。嗯，这里要注意——null 可能会引发空指针异常。正确的做法是返回“业务可接受的空白结果”，比如空列表、默认值、或者旧的缓存数据。

我曾经犯过的错： 在一家金融公司，我把账户总资产接口做了降级，返回了空列表。结果前端以为用户资产为 0，直接弹了“您暂无资产”。用户差点投诉到银监会。后来改成了降级时返回最近一次的缓存数据，并标记为“非实时数据”。前后端配合好了才摆平。

熔断是“断路”，限流是“限速”，降级是“换挡”。一个系统要想高可用，三者缺一不可。但降级更侧重业务层面的决策：哪些功能可以砍，砍到什么程度，以及砍完之后怎么恢复。这需要业务方和技术方一起定，不是纯技术活。

下面这张图是我自己画的关系图，帮你一眼看清三者的定位和协作：

    总结一句： 降级不是万能的，但缺少降级是万万不能的。它和限流、熔断组成高可用系统的“三驾马车”。理解这三者的差异和协作，你才能设计出真正抗打的系统。

这一章的内容就到这里。记住，降级不是认输，是战略撤退。什么时候撤、撤哪些、怎么撤，心里要有本账。后面我们会具体讲降级的参数调优和实战策略，但地基先打好——概念不清，后面写出的代码全是雷。

第 1 章 服务降级概述