都是套路：高并发系统的降级特技

《都是套路：高并发系统的降级特技》要点：
本文介绍了都是套路：高并发系统的降级特技，希望对您有用。如果有疑问，可以联系我们。

作者简介：

张开涛

京东集团技术研发,2014年加入京东,开发过京东商品详情页、详情页统一服务架构与开发工作,设计并开发了多个亿级访问量系统.

工作之余喜欢写技术博客,有《跟我学 Spring》、《跟我学Spring MVC》、《跟我学Shiro》、《跟我学Nginx+Lua开发》等系列教程.

开篇：

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流.之前已经有一些文章介绍过缓存和限流了.本文将详细聊聊降级.

当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时,仍然需要保证服务还是可用的,即使是有损服务.

系统可以根据一些关键数据进行自动降级,也可以配置开关实现人工降级.本文将介绍一些笔者在实际工作中遇到的或见到过的一些降级方案供大家参考.

降级的最终目的是保证核心服务可用,即使是有损的.而且有些服务是无法降级的(如加入购物车、结算).

降级预案

在进行降级之前要对系统进行梳理,看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护,哪些可降级；比如可以参考日志级别设置预案：

一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时,可以自动降级；

警告：有些服务在一段时间内成功率有波动(如在95~100%之间),可以自动降级或人工降级,并发送告警；

错误：比如可用率低于90%,或者数据库连接池被打爆了,或者访问量突然猛增到系统能承受的最大阀值,此时可以根据情况自动降级或者人工降级；

严重错误：比如因为特殊原因数据错误了,此时需要紧急人工降级.

降级的类别

• 降级按照是否自动化可分为：自动开关降级和人工开关降级.
• 降级按照功能可分为：读服务降级、写服务降级.
• 降级按照处于的系统层次可分为：多级降级.

降级的功能点

降级的功能点主要从服务端链路考虑,即根据用户访问的服务调用链路来梳理哪里需要降级：

页面降级：在大促或者某些特殊情况下,某些页面占用了一些稀缺服务资源,在紧急情况下可以对其整个降级,以达到丢卒保帅；

页面片段降级：比如商品详情页中的商家部分因为数据错误了,此时需要对其进行降级；

页面异步请求降级：比如商品详情页上有推荐信息/配送至等异步加载的请求,如果这些信息响应慢或者后端服务有问题,可以进行降级；

服务功能降级：比如渲染商品详情页时需要调用一些不太重要的服务：相关分类、热销榜等,而这些服务在异常情况下直接不获取,即降级即可；

读降级：比如多级缓存模式,如果后端服务有问题,可以降级为只读缓存,这种方式适用于对读一致性要求不高的场景；

写降级：比如秒杀抢购,我们可以只进行Cache的更新,然后异步同步扣减库存到DB,保证最终一致性即可,此时可以将DB降级为Cache.

爬虫降级：在大促活动时,可以将爬虫流量导向静态页或者返回空数据从而降级保护后端稀缺资源.

降级策略

1、自动开关降级

自动降级是根据系统负载、资源使用情况、SLA等指标进行降级.

超时降级

当访问的数据库/http服务/远程调用响应慢或者长时间响应慢,且该服务不是核心服务的话可以在超时后自动降级；

比如商品详情页上有推荐内容/评价,但是推荐内容/评价暂时不展示对用户购物流程不会产生很大的影响；

对于这种服务是可以超时降级的.如果是调用别人的远程服务,和对方定义一个服务响应最大时间,如果超时了则自动降级.

之前总结过一些的文章《使用httpclient必须知道的参数设置及代码写法、存在的风险》和《dbcp配置及jdbc超时设置总结》.在实际场景用一定主要配置好超时时间和超时重试次数和机制.

统计失败次数降级

有时候依赖一些不稳定的API,比如调用外部机票服务,当失败调用次数达到一定阀值自动降级；然后通过异步线程去探测服务是否恢复了,则取消降级.

故障降级

比如要调用的远程服务挂掉了(网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常),则可以直接降级.

降级后的处理方案有：

默认值(比如库存服务挂了,返回默认现货)

兜底数据(比如广告挂了,返回提前准备好的一些静态页面)

缓存(之前暂存的一些缓存数据)

限流降级

当我们去秒杀或者抢购一些限购商品时,此时可能会因为访问量太大而导致系统崩溃,此时开发者会使用限流来进行限制访问量,当达到限流阀值,后续请求会被降级；

降级后的处理方案可以是：

排队页面(将用户导流到排队页面等一会重试)

无货(直接告知用户没货了)

错误页(如活动太火爆了,稍后重试)

2、人工开关降级

• 在大促期间通过监控发现线上的一些服务存在问题,这个时候需要暂时将这些服务摘掉；
• 还有有时候通过任务系统调用一些服务,但是服务依赖的数据库可能存在：网卡被打满了、挂掉了或者很多慢查询,此时需要暂停下任务系统让服务方进行处理；
• 还有发现突然调用量太大,可能需要改变处理方式(比如同步转换为异步)；

此时就可以使用开关来完成降级.

开关可以存放到配置文件、存放到数据库、存放到Redis/ZooKeeper；如果不是存放在本地,可以定期同步开关数据(比如1秒同步一次).然后通过判断某个KEY的值来决定是否降级.

另外对于新开发的服务想上线进行灰度测试；但是不太确定该服务的逻辑是否正确,此时就需要设置开关,当新服务有问题可以通过开关切换回老服务.

还有多机房服务,如果某个机房挂掉了,此时需要将一个机房的服务切到另一个机房,此时也可以通过开关完成切换.

还有一些是因为功能问题需要暂时屏蔽掉某些功能,比如商品规格参数数据有问题,数据问题不能用回滚解决,此时需要开关控制降级.

3、读服务降级

对于读服务降级一般采用的策略有：

暂时切换读(降级到读缓存、降级到走静态化)

暂时屏蔽读(屏蔽读入口、屏蔽某个读服务)

在《应用多级缓存模式支撑海量读服务》中曾经介绍过读服务,即：

接入层缓存→应用层本地缓存→分布式缓存→RPC服务/DB

我们会在接入层、应用层设置开关,当分布式缓存、RPC服务/DB有问题自动降级为不调用.当然这种情况适用于对读一致性要求不高的场景.

页面降级、页面片段降级、页面异步请求降级都是读服务降级,目的是丢卒保帅(比如因为这些服务也要使用核心资源、或者占了带宽影响到核心服务)或者因数据问题暂时屏蔽.

还有一种是页面静态化场景：

（编辑：ASP站长网）