什么是服务降级？

面试考察点

1. 概念理解：面试官其实想看你是否真的懂 "为什么要降级"——高并发场景下系统资源就那么多，必须做取舍。

2. 实践意识：考察你是否真的在生产环境做过降级方案，还是只停留在八股文层面。知道 Sentinel、Hystrix 这些框架的差别，知道哪些服务能降、哪些不能降。

3. 架构全局观：降级从来不是单独存在的，它和限流、熔断、隔离搭在一起，才是一套完整的高可用防护。面试官想看你能不能把降级放回整个架构里去想，别只盯着一个点。

核心答案

服务降级（Service Degradation）：当系统资源紧张、负载过高、或依赖服务出现故障时，为了保证核心业务的可用性和系统整体稳定性，主动暂时关闭、简化或延迟一些非核心服务、功能或依赖的一种自我保护策略。

一句话核心思想：丢车保帅，保住核心链路，牺牲边缘功能。

举个最直观的例子：双 11 零点抢购，流量瞬间打满。这时候商品详情页的 "猜你喜欢"、"相关推荐"、评论列表这些功能，能不展示就不展示，能走缓存就走缓存；但下单、支付这条核心链路必须稳如老狗。这就是降级。

深度解析

一、为什么要降级——真实的痛点

我之前做过一个电商项目，大促的时候依赖十几个下游服务：库存、促销、优惠券、积分、推荐、评论、物流……任何一个挂了或者响应变慢，都可能把上游线程池占满，最终拖垮整个系统。

这就叫雪崩效应：一个不起眼的下游服务故障，像多米诺骨牌一样，一层层把整个调用链拉垮。

上图就是典型的雪崩传播路径：

• 起点：推荐服务这个边缘依赖响应变慢
• 扩散：订单服务调用推荐服务的线程被长时间阻塞，线程池逐渐占满
• 恶化：新的订单请求拿不到线程，全部排队超时
• 雪崩：订单服务不可用，整个交易链路瘫痪

降级要解决的就是这个问题——在雪崩发生之前，主动切断或简化对边缘依赖的调用，把资源让给核心链路。

二、降级的触发方式

降级不会自己触发，常见的触发方式分两大类：

1. 自动降级（系统自动判定，无需人工介入）

2. 手动降级（运维或开发通过开关触发）

通过配置中心（Nacos、Apollo）下发开关，实时生效。大促前预热的时候，DBA 一键把评论、推荐这些功能关掉，把资源全部让给交易链路。

经验之谈：生产环境一定要自动降级 + 手动降级结合。全自动太激进容易误杀，全手动又来不及响应。自动降级兜底，手动降级用于可预判的大流量场景。

三、降级的常见策略

降级不是光报个错就完事，得讲究策略，让系统优雅退化：

• 返回默认值：最简单的降级，比如调用用户头像服务失败，直接返回一个默认头像 URL。
• 返回兜底数据：推荐服务挂了，返回一份运营预设的热门商品列表。用户感知不到服务挂了。
• 返回缓存数据：实时数据拿不到，就返回缓存里的旧数据。虽然可能不精确，但比报错强。
• 同步转异步：积分这种非实时性要求高的操作，可以先返回成功，后续通过 MQ 异步处理。
• 功能关闭：直接屏蔽功能入口，比如商品详情页不展示评论区。

四、降级 vs 限流 vs 熔断（面试必问）

这三个概念经常被搞混，面试官特别爱追问它们的区别。我用一张表把它们讲清楚：

三个不是各干各的，实际是协同工作：

配合关系一句话总结：限流挡在门外，熔断断开下游，降级保护自己。

五、代码示例：Sentinel 实现降级

生产环境里，Sentinel 是用得最多的降级组件（阿里开源，比 Hystrix 更活跃）。看段代码就明白降级怎么落地：

@RestController
public class OrderController {

    @Autowired
    private RecommendService recommendService;

    @GetMapping("/order/detail")
    @SentinelResource(value = "getOrderDetail",
                      blockHandler = "handleBlock",     // 限流降级处理
                      fallback = "handleFallback")      // 异常降级处理
    public OrderDetailVO getOrderDetail(String orderId) {
        // 核心业务：订单详情
        OrderDetailVO order = orderService.getById(orderId);

        // 非核心业务：推荐商品（可降级）
        try {
            List<Item> recommends = recommendService.getRecommends(orderId);
            order.setRecommends(recommends);
        } catch (Exception e) {
            // 降级：推荐拿不到不影响主流程
            log.warn("推荐服务降级，orderId={}", orderId, e);
            order.setRecommends(Collections.emptyList());
        }
        return order;
    }

    // 限流/降级兜底方法，签名要和原方法一致，多一个 BlockException
    public OrderDetailVO handleBlock(String orderId, BlockException ex) {
        log.warn("订单详情被限流或降级，orderId={}", orderId);
        return OrderDetailVO.degradeDefault();
    }

    // 异常兜底方法
    public OrderDetailVO handleFallback(String orderId, Throwable e) {
        log.warn("订单详情异常降级，orderId={}", orderId, e);
        return OrderDetailVO.degradeDefault();
    }
}

配套的 Sentinel 规则配置（超时降级 + 异常比例降级）：

// 加载降级规则
private static void initDegradeRule() {
    List<DegradeRule> rules = new ArrayList<>();

    // 规则1：慢调用比例熔断（Sentinel 1.8.0+）
    // 慢调用 = 响应时间 > 200ms 的请求
    DegradeRule rtRule = new DegradeRule("getOrderDetail")
        .setGrade(CircuitBreakerStrategy.SLOW_REQUEST_RATIO.getType())
        .setCount(200)                    // 最大响应时间 maxRT：超过 200ms 算慢调用
        .setSlowRatioThreshold(0.5)       // 慢调用比例阈值：> 50%
        .setMinRequestAmount(5)           // 最小请求数
        .setStatIntervalMs(1000)          // 统计窗口：1 秒
        .setTimeWindow(10);               // 熔断持续时间：10 秒
    rules.add(rtRule);

    // 规则2：异常比例熔断，异常率 > 50% 触发熔断 10 秒
    DegradeRule exRule = new DegradeRule("getOrderDetail")
        .setGrade(CircuitBreakerStrategy.ERROR_RATIO.getType())
        .setCount(0.5)                    // 异常比例阈值：50%
        .setMinRequestAmount(5)
        .setStatIntervalMs(1000)
        .setTimeWindow(10);
    rules.add(exRule);

    DegradeRuleManager.loadRules(rules);
}

六、生产环境降级方案设计要点

这块我踩过坑，分享几个实战经验：

1. 降级要分层：网关层、服务层、数据层都要有降级预案。网关层可以降级静态页面，服务层降级非核心依赖，数据层可以主从切换或读旧数据。
2. 核心链路不能降级：下单、支付这种核心链路一旦降级就等于业务停摆，该用限流去保护，不是降级。
3. 降级要可监控、可回滚：降级一触发就得有告警，而且能一键恢复。Sentinel Dashboard、Prometheus 都可以做这件事。
4. 降级开关要有灰度能力：不要一上来全量降级，可以先按机房、按用户百分比灰度。

面试高频追问

1. 追问一：降级和熔断到底啥区别？

这两个最容易混。熔断是针对下游调用的——下游服务出问题了，我快速失败，不再真的去调用它，防止被拖死。降级范围更大，是针对自身系统的——为了保证核心功能，我主动牺牲掉一部分非核心功能。熔断往往会触发降级逻辑，但降级不一定需要熔断。

补充一点：降级其实是一个比较模糊的业务概念，限流和熔断在某种程度上都可以看作降级的一种手段。

2. 追问二：怎么决定哪些服务能降级，哪些不能？

按业务影响分级：核心交易链路（下单、支付）不能降，用限流保护；辅助功能（推荐、评论、积分）可以降；纯展示类功能（头像、标签）优先降。

3. 追问三：Sentinel 和 Hystrix 的区别？

Hystrix 已经停止维护了，Sentinel 是阿里开源的，目前主流。核心区别：Hystrix 默认推荐线程池隔离（也支持信号量隔离），隔离彻底但上下文切换开销大；Sentinel 不提供线程池隔离，通过限制并发线程数实现轻量级隔离，资源开销小，但主要支持同步调用、异步是短板。功能上 Hystrix 侧重熔断降级，Sentinel 还覆盖限流、系统自适应保护、热点参数限流。

常见面试变体

• "限流、降级、熔断的区别是什么？"
• "你们项目里是怎么做服务降级的？举一个具体的场景。"
• "如何设计一个高可用系统的降级方案？"
• "Sentinel 的降级规则有哪些？"

记忆口诀

限流挡门外，熔断断下游，降级保自己，核心不能丢。

总结

服务降级说白了就是系统在高压力下的一种自我保护机制，核心是 "取舍" 二字——牺牲非核心功能，保住核心链路。面试时把三点答透就够：降级的本质（丢车保帅）、触发方式（自动 + 手动）、和限流、熔断的协同关系。再配合 Sentinel 的代码示例，基本能让面试官觉得你是真做过，而不是背书。