如果这是第二次看到我的文章，欢迎文末扫码订阅我哟~
本文长度为4069字，建议阅读11分钟。
也许你对降级已经有了一些认识，认真看完，我想这篇文章可能会给你带来一些新的收获～
前面两篇我们已经聊过了「熔断」（）和「限流」（），这次我们聊的就是「高可用三剑客」中剩下的「降级」。
不知道这里有多少小伙伴接触过阿里的开放平台。在每次大促的时候，阿里都会发布这样的一个公告。
这些调整就是「降级」工作，目的是为了腾出更多资源给核心程序使用，以最大化保证核心业务的可用性，因此就必然需要对非核心业务执行一些降级处理。
一、什么是「降级」
降级的目的用一句话概括就是：将有限的资源效益最大化。
什么样才是效益最大化呢？就像下面这个例子：
z哥有3个东西要买，一个3000的A、一个700的B、一个1200的C，对z哥的重要程度A>B>C。但此时，z哥手里只有3000块钱，你说z哥该怎么选才能把钱花的最多？必然是选A咯。
根据28原则，我们知道一个系统80%的效益是由最核心的20%的功能产出的。剩下的20%效益需要投入80%的资源才能达到。
这就意味着，假如系统平时需要花费100%资源做100%的事情，如果现在访问量增多3倍的话必定扛不住（）。那么，在不增加资源的情况下，我希望系统不能宕机，依旧能正常工作，必然需要让出那解决剩下20%问题的80%资源。如此一来，理论上这100%的资源就可以支撑原先5倍的访问量。副作用是功能的完整性上受损80%。
当然，在实际的场景中不会降级掉80%的功能这么夸张，毕竟还得为用户的体验考虑。
举个电商场景典型的例子，在大促的时候，最重要的是什么？转化咯～赚钱咯～ 那么这个时候如果说「评论」功能占用了很多资源，你会怎么处理？其实我们可以选择临时关闭提交评论入口、关闭翻页功能等等，让下单的过程有更多的资源来处理。
常见的降级方案表现形式无非以下三种类型。
牺牲用户体验
为了减少对「冷数据」的获取，禁用列表的翻页功能。
为了放缓流量进入的速率，增加验证码机制。
为了减少“大查询”浪费过多的资源，提高筛选条件要求（）。
用通用的静态化数据代替「千人千面」的动态数据。
甚至更简单粗暴的，直接挂一个页面显示「XX功能在XX时间内暂时关闭」。
此类方案虽然或多或少降低了用户的体验，但是在某些时期，有些功能并不是「刚需」。以此换取对系统的保护是笔划算的买卖。
牺牲功能完整性
还有一些功能是「防御性」的，如果愿意冒险“裸奔”一段时间也会带来可观的资源节约。
比如通过临时关闭「风控」、取消部分「条件是否满足」的判断（）等操作，减少这类「验证」动作以释放更多的资源。
又或者将原本info、warning级别的日志采集关闭或者直接不采集，仅采集error以及fault级别的日志。
牺牲时效性
一个事件发生后立马看到效果是一个很符合「思维惯性」的东西。但是根据之前的一篇文章（）我们知道，时效性这个东西一旦涉及到网络传输是不存在真正的“实时”的。但是为了尽可能快的将处理后的结果反映到相关的地方，你会做很多努力。比如库存的及时同步。
如果在特殊时期，能够临时降低对时效性的要求（），也是一个有不错收益的方案。
比如原先在商品页会显示当前还剩多少个库存，现在可以调整成固定显示「有货」。
以及将一些原本就是异步进行的操作，处理效率放缓，甚至暂缓一段时间。如，送积分、送券等等。
