细说降级

2 8月

什么是降级

当出现大流量或者其他情况时我们需要保护我们的系统,这里有三大利器:缓存、降级和限流。

降级是一种利用有限资源,保障系统核心功能高可用、有损的架构方法。降级的最终目的是保证核心服务可用,即使是有损的,同时有些服务是无法降级的。

实施降级

实施降级需要综合分析系统情况和业务情况,要判断是否可以“丢卒保帅”,同时梳理出核心链路,保护核心业务。

考虑到影响业务的范围降级可以分为以下几种:

页面降级

在特殊情况下(一般是热门活动),有些页面占用了一些稀缺服务资源,在紧急情况下可以对其整个降级,页面暂时无法访问。

页面片段降级

比如商品页面中包含其他商品推荐信息,这个片段可以暂时屏蔽。

页面异步请求降级

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

服务功能降级

比如渲染商品详情页时需要调用一些不太重要的服务,比如外卖中的骑手配送路径,紧急情况下可以不显示路径,只显示配送时间和状态。

读降级

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

写降级

特殊情况下如果可以接收最终一致性,可以直接写cache,用于缓解数据库的压力,比如秒杀。

降级预案

一般情况下降级的发生是可以预期的,比如相关业务促销,或者新业务进入新城市的时候。这个时候预案是最重要的,首先再次明确核心链路是什么,哪些不能超时,不能不可用,哪些可以接收一定超时,不能不可用,哪些可以超时,可以不可用。

我们假象一个微信公众号点餐系统,比如下图

很容易梳理出来查看菜品,余额和消费付款都是核心,会直接影响交易本身。而会员信息修改,发放优惠券就是暂时不可用的,而菜品评价是可以部分可用或者接收一定的超时的。

梳理出这些内容以后,那么就需要明确降级开关的触发条件和方式,这个是业务和技术的综合问题,同时要明确降级触发以后的需要周知的干系人。

自动降级

监控对于系统的健康必不可少,监控可以覆盖很多方面,比如流量,JVM,日志等等。而自动降级是一个很吸引人的东西,它是根据系统负载、资源使用情况、SLA等指标自主进行降级。

超时降级

当访问的数据库或者rpc调用超过默认设定值以后,若服务不是核心服务的话可以在超时后自动降级;具体的服务响应最大时间需要和服务提供方商议,或者根据监控系统的历史数据来评估。

失败次数降级

有时候依赖一些不稳定的API,比如调用第三方商家系统,当失败调用次数达到一定阀值后自动降级;然后通过异步线程去探测服务是否恢复了,则取消降级。

这个有点类似半开式熔断。

故障降级

比如要调用的远程服务挂掉了比如Dns故障,则可以直接降级。降级后的处理方案有:兜底数据、缓存或者默认值。

限流降级

当我们去秒杀或者抢购一些限购商品时(比如小米抢购…),此时可能会因为访问量太大而导致系统崩溃,可以用限流来限制访问量,当达到限流阀值,后续请求会被降级;降级后的处理方案可以是:排队页面。

参考

http://jinnianshilongnian.iteye.com/blog/2306477

发表评论

电子邮件地址不会被公开。