可以先介绍降级的基本概念，比如前面的大促和APP首页的例子。如果之前和面试官没有聊过熔断，可以在这里补充熔断里面讨论判断服务健康的要点，结合自己公司内部使用降级的例子，或是不是自己亲手落地但是自己也了解详情的案例。

我在公司也用了降级来保护我维护的服务。举例来说，正常情况下我的服务都会全量采集各种监控指标。那么在系统触及性能瓶颈的时候，我就会调整采集的比率。甚至在关键的时候，我会直接停用掉所有的指标采集，将资源集中在提供服务上。

讲完一个案例后，可以进一步总结常规的降级思路。

如果不了解细节的话，可以大方承认这就是听说过的措施，并没有实际落地。

最关键的问题就是抖动，可以将熔断与降级结合，总结升华一下。

总的来说，在任何的故障处理里面，都要考虑恢复策略会不会引起抖动问题

如果某个服务里同时提供了读服务和写服务，并且读服务明显比写服务更重要，这时候降级写服务。
假如我有一个针对商家的服务，商家调用这些 API 来录入一些数据，比如他们门店的基本信息，上传一些门店图片等。同时我还有一个针对 C 端普通用户的服务，这个服务就是把商家录入的数据展示在商家门店的首页上。所以你可以看到在这个场景下，读服务 QPS 更高，也更加重要。
那么如果这两个服务是一起部署的，在需要降级的时候，就可以考虑将针对商家的写服务停掉，将资源都腾出来给针对 C 端用户的读服务。所以你可以介绍这个方案，关键词是降级写服务。