资源和访问量出现矛盾时，将资源让给更核心的业务。
- 降低一致性
从强一致性变成最终一致性
- 停止次要功能
不重要的功能临时下线。比如，电商中的商品成交记录，用户的评价功能等
- 简化流程
简化业务流程，或者是不再返回全量数据，而是只返回部分数据
或者异步化，借助MQ
这样可能会牺牲一部分用户体验，所以最好给出较好的用户提示。
淘宝双11，银行会在支付环节成为瓶颈，业务解决方式，是预充值送红包，其实就是将用户的钱提前充入支付宝现金池中，当天交易无非就是内部的数据关联关系，降低对外部的依赖。
- 使用缓存，降低数据库的压力。降级后的系统，不再通过数据库获取数据，而是通过缓存获取数据。
- 直接去掉数据，比如，页面不显示库存，只显示有没有库存的状态
-
要对业务做非常仔细的梳理。
-
分类处理，比如吞吐量大、响应时间过慢、失败次数较多，有网络或者服务故障等等，要分类做好预案。并写成代码，可以快速地自动化或半自动化执行
-
分好等级，哪些是“必须有的”，哪些是“可以有的”，事前评估好
-
降级的时候，需要牺牲掉一致性，或是一些业务流程：对于读操作来说，使用缓存来解决，对于写操作来说，需要异步调用来解决。并且，我们需要以流水账的方式记录下来，这样方便对账，以免漏掉或是和正常的流程混淆。
-
降级的功能的开关可以是一个系统的配置开关。做成配置时，你需要在要降级的时候推送相应的配置。另一种方式是，在对外服务的 API 上有所区分（方法签名或是开关参数），这样可以由上游调用者来驱动。
-
比如：一个网关在限流时，在协议头中加入了一个限流程度的参数，让后端服务能知道限流在发生中。当限流程度达到某个值时，或是限流时间超过某个值时，就自动开始降级，直到限流好转。
-
对于数据方面的降级，需要前端程序的配合。一般来说，前端的程序可以根据后端传来的数据来决定展示哪些界面模块。比如，当前端收不到商品评论时，就不展示。为了区分本来就没有数据，还是因为降级了没有数据的两种情况，在协议头中也应该加上降级的标签。
因为降级的功能平时不会总是会发生，属于应急的情况，所以，降级的这些业务流程和功能有可能长期不用而出现 bug 或问题，对此我们平时要做些演练。