服务降级是什么？和熔断、限流有什么区别？
简化版
服务降级是在系统压力过大或依赖异常时，主动牺牲部分非核心功能，保住核心链路可用。比如推荐服务异常时返回默认推荐，评论服务异常时隐藏评论区，报表服务延迟计算。降级关注“返回什么兜底结果”，熔断关注“是否继续调用异常依赖”，限流关注“是否允许流量进入”。三者常配合使用。
详细版
降级可以分为主动降级和被动降级。主动降级通常在大促、活动、故障演练前预先关闭非核心能力；被动降级通常由熔断、超时、异常触发。
降级策略包括返回默认值、缓存值、空结果、静态页面、简化流程、异步处理、关闭非核心模块等。关键原则是按业务优先级分层：核心交易链路尽量保，体验类和辅助类功能可以牺牲。
降级不能破坏数据正确性。展示类接口可以返回旧缓存，但资金、库存、订单状态不能随意假成功。好的降级方案需要可配置、可观测、可回滚，并且提前演练。
完整版教学
一、降级的核心思想
分布式系统资源有限，依赖也会失败。当系统处在高压或故障状态时，如果仍然坚持所有功能都完整可用，结果可能是全部不可用。降级的思想是保主链路、牺牲次要能力，让系统以较低能力继续服务。
比如电商首页里，下单支付是核心，推荐、评论、排行榜是辅助。推荐服务挂了，不应该影响用户下单；评论服务慢了，可以先隐藏评论区；报表计算慢了，可以延迟更新。降级本质是业务优先级管理。
二、降级和熔断限流的区别
限流回答的是“这个请求要不要进来”。当入口流量超过系统承载能力时，限流会拒绝、排队或削峰。熔断回答的是“这个依赖还要不要调用”。当下游持续失败或变慢时，熔断器打开，停止真实调用。降级回答的是“不能完整服务时给用户什么结果”。
三者经常组合。比如推荐服务慢调用比例过高，熔断器打开；打开后不再调用推荐服务，而是走降级逻辑返回默认推荐；如果首页总体流量过高，网关还会先限流。限流挡流量，熔断切依赖，降级给兜底。
三、常见降级策略
第一是默认值，比如返回空列表、默认头像、默认文案。第二是缓存值，比如读取上一版配置、旧排行榜、上一次价格快照。第三是功能关闭，比如隐藏评论区、暂停推荐、关闭复杂筛选。第四是异步化，比如同步写改成先入队，稍后处理。第五是简化流程，比如搜索只返回核心字段，不做个性化排序。
选择策略要看业务后果。返回空列表可能影响体验，但通常安全；返回旧价格可能带来资损，就必须谨慎；异步化可以削峰，但要处理最终一致和补偿。
四、主动降级和被动降级
主动降级是预案型动作。大促前预估流量很高，可以提前关闭低价值功能，释放资源给核心链路。比如活动开始前关闭实时统计、复杂推荐、非关键日志同步。这种降级可控性更高，最好通过配置中心或治理平台一键开关。
被动降级是故障触发动作。比如接口超时、熔断打开、线程池满、错误率升高时自动走 fallback。被动降级要注意防抖和告警，不能因为短暂抖动频繁切换，也不能静默降级导致问题长期没人发现。
五、降级的风险
降级最大风险是业务语义错误。对于读多写少的展示接口，返回旧数据通常可以接受；对于资金、库存、订单状态，错误兜底可能比失败更糟糕。比如扣款接口超时后不能直接返回成功，否则可能造成账务不一致。
另一个风险是降级路径没人维护。平时主链路正常，fallback 很少被执行，到了事故时才发现缓存没数据、默认值格式不对、前端不兼容。因此降级方案必须进入测试、压测和故障演练。
六、面试追问与工程边界
面试官可能问如何设计降级预案。可以按业务分级：S0 核心交易不轻易降级，只允许失败返回和人工兜底；S1 核心读接口可用缓存；S2 体验类功能可关闭；S3 统计报表可延迟。每个接口明确触发条件、兜底结果、恢复方式和告警负责人。
还可能问降级后如何恢复。恢复不能只靠手动拍脑袋，最好结合指标观察，如错误率、延迟、下游容量、队列积压下降后逐步恢复，避免刚恢复就再次打爆系统。
七、落地设计清单
做降级设计时，第一步是业务分级。把接口和功能分成核心链路、重要链路、体验链路和后台链路。核心链路如登录、下单、支付、发货，一般只能做有限降级或快速失败；体验链路如推荐、评论、排行榜、个性化，可以返回默认值、缓存值或隐藏模块；后台链路如报表、同步、统计，可以延迟处理。
第二步是明确触发条件和恢复条件。触发可以来自错误率、慢调用比例、线程池队列、下游熔断、人工开关或大促预案；恢复不能只看故障消失，还要看下游容量、队列积压和业务指标是否稳定。第三步是验证前端兼容性。后端返回空列表、默认值或降级码时，前端要有明确展示，不能因为字段缺失造成页面白屏。
八、常见误区和业务边界
降级最容易犯的错是把失败伪装成成功。比如支付接口超时后返回支付成功，或者库存扣减失败后继续创建订单，这会把可见故障变成数据不一致。正确做法是展示类可以弱化，交易类必须谨慎，核心写操作通常宁可失败返回，也不要假成功。
另一个误区是降级逻辑长期不演练。很多 fallback 平时从不执行，线上故障时才发现缓存没有预热、默认值不合法、调用了另一个同样故障的依赖。降级路径应该像主路径一样进入测试和监控。可以定期做小流量演练，确认开关、兜底数据、告警、恢复流程都可用。 降级还要考虑“用户可解释性”。同样是返回失败，直接报系统异常会造成困惑；如果是推荐、评论、报表这类非核心能力，可以给出“暂时不可用、稍后刷新”的提示，或者在页面上自然隐藏模块。好的降级不只是后端能跑通，还要让用户感知可接受，让客服和运营也知道当前处于什么降级状态。
九、常见误区与追问
这道题不能只背概念，要把「服务降级」放回真实分布式系统里解释：谁发起、谁协调、状态如何变化、失败后怎么兜底，以及它和性能、可用性、一致性的取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 降级是在资源紧张或依赖异常时牺牲非核心能力，保证核心链路可用 | 不要停在名词解释 |
| 流程机制 | 识别核心和非核心功能 -> 设置降级开关或规则 -> 触发异常或容量阈值 -> 返回兜底结果 -> 恢复后关闭降级 | 说明触发方、参与方、状态变化和兜底 |
| 工程取舍 | 大促时关闭个性化推荐，商品详情返回基础信息，支付下单链路优先保障 | 治理组件是为了控制故障半径，不是让下游无限扛流量 |
服务降级 面试拆解：
1. 识别核心和非核心功能
2. 设置降级开关或规则
3. 触发异常或容量阈值
4. 返回兜底结果
5. 恢复后关闭降级记忆钩子：先定位治理目标，再拆限流、熔断、降级、重试、追踪、灰度和幂等边界；回答时要紧扣「服务降级」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：降级就是服务失败。 降级是主动取舍，目标是保核心体验。
- 误区：所有接口都能返回默认值。 金额、库存、权限等关键数据不能随便降级成默认成功。
- 误区：降级只在故障后手动做。 成熟系统会有自动触发、手动开关和预案演练。
- 追问：降级和熔断区别是什么？ 熔断是触发机制之一，降级是返回兜底能力的业务策略。
- 追问：降级结果怎么设计？ 缓存、默认值、静态页、稍后重试或隐藏非核心模块。
- 追问：如何防止降级误伤？ 按接口、用户、地区和功能分级，配合监控和快速回滚。
十、加强记忆
降级是“保核心、舍非核心”。限流决定请求能不能进来，熔断决定异常依赖还调不调，降级决定兜底返回什么。降级策略可以是默认值、缓存值、空结果、关闭功能、异步化和简化流程，但不能破坏资金、订单、库存等核心正确性。