关键词总结：降低一致性、停止次要功能、简化功能、降级设计要点
所谓的降级设计（Degradation），本质是为了解决资源不足和访问量过大的问题。当资源和访问量出现矛盾的时候，在有限的资源下，为了能够扛住大量的请求，需要对系统进行降级操作。暂时牺牲掉一些东西，以保障整个系统的平稳运行。
牺牲哪些东西：
- 降低一致性。从强一致性变成最终一致性。
- 停止次要功能。停止访问不重要的功能，从而释放出更多的资源。
- 简化功能。把一些功能简化掉，比如，简化业务流程，或是不再返回全量数据，只返回部分数据。
降低一致性
降级之后，只能保证流程最终结果的一致性。会有两种做法，一种是简化流程的一致性，一种是降低数据的一致性。
使用异步简化流程
举个例子，电商的下单交易系统，在强一致的情况下，需要结算账单，扣除库存，扣除账户上的余额（或发起支付），最后进行发货流程，这一系列的操作。
在系统降级时，可以把这一系列的操作做成异步的。库存从单笔强一致性也变成了多笔最终一致性，如果库存不够了，就只能根据先来后到取消订单了。而支付也从最开始的下单请求时的强一致性，变成了用户到付的最终一致性。
降低数据的一致性
降低数据的一致性一般来说会使用缓存的方式，或是直接就去掉数据。
参看 缓存更新的套路
停止次要的功能
把一些不重要的功能给暂时停止掉，让系统释放出更多的资源来。比如，电商中的搜索功能，用户的评论功能，等等。等待访问的峰值过去后，再把这些功能给恢复回来。
最好不要停止次要的功能，首先可以限制次要的功能的流量，或是把次要的功能退化成简单的功能，最后如果量太大了，才会进入停止功能的状态。（首先考虑的是限流，或者退化为简单功能，而不是直接就停止）
简化功能
降级之后，必要的时候忽略非关键数据并只返回重要的数据。
降级设计的要点
- 对业务做非常仔细的梳理和分析
- 清楚地定义好降级的关键条件
比如，吞吐量过大、响应时间过慢、失败次数多过，有网络或是服务故障，等等，然后做好相应的应急预案。这些预案最好是自动化或半自动化执行的。 - 简化业务流程
梳理业务的功能哪些是必须要死保的功能，哪些是可以牺牲的功能。设计好可以简化的或是用来应急的业务流程。当系统出问题的时候，就需要走简化应急流程。 - 流水账记录
降级的时候，需要牺牲掉一致性，或是一些业务流程，在使用缓存和异步调用实现降级时，同时需要以流水账的方式记录下来，这样方便对账，以免漏掉或是和正常的流程混淆。 - 降级的功能的开关可配
在要降级的时候推送相应的配置，或者在对外服务的 API 上有所区分由上游调用者来驱动。 - 数据方面的降级，需要前端程序的配合
前端的程序可以根据后端传来的数据来决定展示哪些界面模块，将由降级未提供的数据展示界面去掉 - 降级演练
降级的功能平时不会总是会发生，属于应急的情况，所以，降级的这些业务流程和功能有可能长期不用而出现 bug 或问题，对此，需要在平时做一些演练。
参考资料：
左耳听风（极客时间）链接：
http://gk.link/a/10f5D
GitHub链接：
https://github.com/lichangke/LeetCode
CSDN首页：
https://me.csdn.net/leacock1991
欢迎大家来一起交流学习