降级比如双十一之类的大促高峰，平台是会关闭一些服务的，比如退款服务。这就是降级的典型应用，不过它是一种手动的跨服务降级，对于整个系统来说，提供了一部分服务，但是没有提供另外一部分服务，在整个系统层面上是降级的。
好处有两个，一方面是腾出了服务器资源，可以给订单服务或支付服务；另外一方面是减少了对公共组件的压力，比如减少了对数据库的写入压力。
同样地，你也需要总结拔高一下，关键词是快慢路径。
这种思路其实可以在很多微服务里面应用。如果一个服务可以分成快路径和慢路径两种逻辑，那么在降级之前就可以先走快路径，再走慢路径。而触发了降级之后，就只允许走快路径。在前面的例子里面，从缓存里加载数据就是快路径，从数据库里面加载数据就是慢路径。 慢路径还可以是发起服务调用或者复杂计算。比如说一个服务快路径是直接查询缓存，而慢路径可能是发起很多微服务调用，拿到所有响应之后一起计算，算出来一个结果并缓存起来。那么在降级的时候，可以有效提高吞吐量。不过这种吞吐量是有损的，毕竟部分请求如果没有在缓存中找到数据，那么就会直接返回失败响应。
很自然地，你的关键服务都应该有类似的降级措施。当任何下游崩溃，或者第三方中间件崩溃，你都可以不再调用这些崩溃的下游服务或中间件，以确保提供有损服务。
如果你选择这个作为亮点方案的话，那么自然就可以将话题引导到缓存的使用上来，你就可以使用课程后面缓存相关的内容来阐述了。
