降级的可行性

二八原则

二八原则放在电商系统里，大概可以这样解释：电商系统80%的收益是由20%的基础功能所贡献，而剩下的20%的收益则是由80%的高阶功能所贡献。

在如今全民网购的时代，大家对于在京东上购买一件商品的步骤都不会太陌生，顺序大致如下：打开首页，搜索商品，进入商品详情页，添加购物车，登录，下单，结算，支付，一共八个步骤，分分钟搞定。

电商企业为了提升销量，收入，用户粘性，用户体验等等，会开发非常多的系统，然后一个商品详情页就成了下面这样了。这里面除去有关商品的必要性信息外，还有促销信息，库存信息，物流信息，商品评价，关注、分享和对比功能，搜索，推荐信息等等非常多的功能。

而这么多的功能，恰恰也为降级提供了可能性。在正常状态下，大家各司其职，为用户提供更好的服务体验；而当流量洪峰逼近超出我们的掌控时，通过将降级高阶功能节省的资源提供给基本功能，从而能够应付洪峰。

如上商品详情页，平时提供了丰富的功能给用户，在降级的时候，其实类似于商品评价，关注、分享、对比，搜索，推荐，广告，库存，物流都可以部分或者全部取消，仅保留供用户购买商品所必不可少的功能即可，那哪些是必不可少的功能呢，从业务和日志角度，仔细分析，相信大家都可以找到正确答案。

降级的影响

用户体验（功能和时效性）

如上述，一堆功能临时被关闭，看不到其他人对商品的评价，对比功能也没了，各种推荐商品也看不到了，对用户当然是有影响的，不然这些高阶功能怎么可能为公司赚钱呢。

好在，一般的降级，不会疯狂到对基本功能进行降级，用户起码还是可以继续购买商品的，这总比今年国庆期间系统故障酒店无法入住给用户带来的影响要小得多。

缓存是降级常用的方法，相关功能一旦进行降级仅查询缓存，对用户来说可能就是，一直刷不出自己刚刚的评论，积分和优惠券迟迟未到账，这都是可以感知到的。还有一些无法感知的时效性问题，比方说库存信息等。

对于搜索引擎来讲，最悲伤的故事莫过于发生了社会热点事件，抗不住流量被迫通过缓存来提供服务，任凭用户无数次搜索都无法找到最新的热点事件，最后转到友商那里看新闻而一去不返了。

收入

降级对收入的影响，以广告为例。降级后，如果是出静态页面或者是缓存页面，都无法准确统计点击行为，导致该部分广告收入流失。如果是推荐呢，个性化推荐降级为传统推荐模式，收入当然也会有很大影响。

基于降级的上述影响，虽然降级对可用性有较大帮助，但很多公司，还是会严格考核降级时长，同时在大促场景下，也要求不要一上来就降级，进而避免在用户体验和收入方面的影响。

常见的降级方法

各类场景的降级方法

网盘类：非付费用户限速下载，且不能传视频。网盘业务的特点是存储空间消耗大，带宽占用高，通过限制下载速度来节省带宽，限制视频来节省存储空间。

新闻类：取消数据预加载功能，减少服务端的请求数量，如下拉自动刷新功能，非首屏数据预加载功能以及详情页预加载功能。举个例子，打开头条一会后再断网，那么还是可以继续浏览一定数量的文章，且部分文章还有图片。

地图类：没有信号在线地图模式转为离线地图模式，路况信息功能不可用，但基本的定位和导航功能还是可以继续使用的。

推荐类：从千人千面的推荐效果降为传统的推荐模式，或者出默认的内容都行。如果是广告方向，还可以出公益广告，甚至不出广告都行
支付类：如果某一种支付方式异常，可以降低该支付方式的排序，或者暂时隐藏该支付方式。例如支付方式有微信和支付宝，就可以采取类似的措施。如果是支付系统自身故障，那可能就需要只读了。

电商类：页面静态化，关闭非核心功能，开启验证码策略，延长缓存失效时间，一些规则计算下放到客户端等。

搜索类：缩小搜索请求查询的数据的范围，不去检索历史数据，减少检索结果的数量，直接从缓存中返回结果，还可以将离线任务的资源临时调整给在线服务使用。

发帖类：通过缓存提供只读功能，关闭非核心功能，还可以取消登录功能。

硬件类：RaidCache以电池为后盾，在 WriteBack 模式下待写盘的数据批量写盘，以极大提升机械盘的写盘性能；当电池掉电时，为了数据安全从 WriteBack 模式切换到 WriteThrough 模式，写盘性能会急剧下降，1~2 小时后电池充电完毕即可重回 WB 模式。

客运类：长途客车凌晨2点至5点实行停车休息制度，夜间行驶速度不得超过日间限速的80%，禁止客车夜间在三级及以下山区公路行驶。类似的，国内的高铁和民航在凌晨也是不做生意的。

上述介绍了各类业务的降级方案，在极端情况下，则是一些较为通用的降级手段，如挂静态页或者维护页（起码比直接返回404强一点），还有就是将请求导流给友商而非让流量去竞争对手处，但需要评估，友商是否能抗住。

降级的最佳实践

降级三板斧

总结起来，较为通用有效的，大致是下述三种方法，三种方法间没有优劣之分，因为不同的业务场景，有效的降级手段是不同的（下面的三板斧并非笔者自己总结，摘抄于某处，但没有找到具体网址，在此说明，万分抱歉）

页面静态化
请求异步化
计算本地化

上述三板斧的具体案例，大家可以参考上面的常见的降级方法

一键降级Portal

为什么需要降级Portal呢？因为每个业务各自实现降级功能并各自管理问题：

一共有多少个降级点不知道
每个业务降级方式不同，所以具体如何降级不知道，降级的耗时也不知道
哪些功能处在降级状态下不知道
多业务组合降级基本无法实现

因此，需要统一的降级平台来解决上述问题，并将降级场景化，一旦出现问题后，执行特定预案即可，常见的场景举例如下：

单个功能异常：新上线一个功能有问题，通过降级平台立即在线上屏蔽该功能，这样的方式，远比回滚要高效和安全，并且不会影响同期上线的其他功能，潜台词就代表着，所有新上线的功能，必须实现功能开关，且功能开关必须接入到降级平台中。

计算能力不足：因为各种原因，当前计算能力不足，因此需要将非核心功能从而将计算能力让渡给核心功能。这时，需要在降级平台中，基于当前故障的严重程度，启动不同的预案，批量关闭不同级别的所有功能。在这里的潜台词就代表着，每个功能都需要按照重要性进行定级，归属于不同的级别中，并通过压测手段和演练，明确每个重要性级别能让渡的计算能力，进而制定有效的预案。

最后，一键降级可能还有以下几种误解：

一键降级不表示执行大降级，如果面对的问题非常明确，那么就可以执行对应的降级即可，只有在降级能力建设的初期或者是情况不明确的时候，才执行大降级，兜住底，然后再慢慢的针对实际情况进行恢复。
一键降级不表示立即全量生效，降级也属于变更，只要是变更就应该有灰度，因此要逐渐建立起梯度降级的能力来。即使在BAT大厂里，也多次发生过因为全量降级而引发更为严重的故障。
一键降级不表示全自动执行，降级操作是否可以自动化，这要视情况而定，降级影响小的操作自动化不是问题，但对于严重影响收入，用户体验的操作，还需要慎重一些。同时，对于自动化降级操作，一定要有刹车按钮去停止全局任何的自动化降级动作转由人工控制，波音737MAX的悲剧就不展开讨论了，但其中貌似就有飞行员无法彻底终止自动化系统介入的问题。

降级时长考核和监控

尽量减少降级时长，因为降级就意味着用户体验和收入上的损失，这在任何公司，都不应该成为常态。随着保障能力的提升，甚至于在大促活动，公司也要求，不能一上来就降级，要有更高目标的追求。因此，要需要考核全年系统处于大降级状态下的时长，尽量避免仅以单一维度的可用性来衡量团队。

基于上述原因，也需要对进入降级状态的功能数量和时长进行监控，尤其是在降级自动化的场景下，更是如此。不介入操作并不表示你不需要知晓。因此，系统一旦处于大降级状态或者陆续有模块开始进入降级状态，全员一定要知晓并开始响应。

降级的开源解决方案

限于自研的原因，该部分笔者没有太多的经验，因此只罗列一些参考内容：

Hystrix
Istio

在这里，就会出现一个非常高频的名词”熔断“，那么熔断和降级是什么关系呢，简言之就是，降级包含了非常的方式方法，具体到一个模块上，常常用熔断的机制来自动化的处理各类异常问题。

相关阅读：

从云厂商宕机史谈预案建设

预案三板斧的限流大法

创作场景

预案三板斧之降级大法