架构设计 -- 服务降级策略详解

目录

1. 自动开关降级

2. 手动开关降级

3. 读服务降级

4. 写服务降级

5. 多级降级


降级是系统保护的重要手段,保证系统的高可用,简单理解,降级就是丢车保帅,在系统压力极大时,暂时不做非必要动作,以保证系统核心功能的正常。

例如电商系统中,购物车、结算这类的核心功能就是保护对象,是绝对不能降级的,而像个性化自动商品推荐服务就可以暂时不提供。

降级策略有很多种,可以从下面3个维度分为5种策略:

  1. 自动化维度--------包括:自动开关降级、人工开关降级。
  2. 功能维度--------包括:读服务降级、写服务降级。
  3. 系统层次维度--------包括:多级降级。

架构设计 -- 服务降级策略详解_第1张图片

1. 自动开关降级

系统在运行时根据运行状态自动触发降级,例如:

  • 超时

调用远程非核心服务时,响应过慢后自动降级,先不调了。需要配置好超时时间和超时重试次数。

  • 统计失败次数

有的服务可能不太稳定,例如外部的机票服务,当调用失败次数超过容忍度后就自动降级。可以通过异步线程去探测服务是否恢复了,可用后自动取消降级。

  • 故障

比如远程服务挂掉了,就自动降级,可以使用默认值、提前准备的内容、之前的缓存数据。

  • 限流

例如秒杀系统,通常会使用限流机制进行保护,当达到限流阈值时,后续请求就自动被降级,例如将用户导流到排队页面过会儿重试、直接告诉用户没货了。

2. 手动开关降级

自动降级是根据系统出现的一些问题进行响应,但在系统还没有出现问题时,我就想降级某些服务,比如促销马上开始了,可以预知访问量很大,我们提前就把推荐服务关掉;再比如新功能想上线进行灰度测试,当新功能不符合预期时我想马上切换回老服务。

这类需求就需要使用可以人工控制的开关来实现。

开关可以存放到配置文件、数据库、Redis/Zookeeper等位置,定期同步开关数据。

分布式系统中通常会创建一个配置中心,对整个系统中的配置开关进行集中管理,提供 Web UI 界面进行便捷操作。目前有一些开源方案可以选择,例如 ZooKeeper、Diamond、Etcd 3、Consul。

3. 读服务降级

读取数据 的角度考虑降级,例如商品详情页,其中有非常多的内容,比如商家信息、推荐信息、配送至信息、相关分类、热销榜等等,这些都不是核心数据,所以在出现异常时可以进行降级处理。

还以商品详情页为例,在促销活动之前,可以将整个页面切换为静态化,最大程度的降级读服务。

4. 写服务降级

写服务都是很关键的,降级思路基本就是同步写转异步写

例如扣减库存的操作,正常情况下的设计一般是:

方案1:数据库中扣减,成功后更新 Redis 缓存。

方案2:先扣减 Redis 缓存,同步扣减数据库,如果失败则回滚 Redis 缓存。

当数据库性能跟不上时,就需要采用异步方式了:

先扣减 Redis 缓存,同时向队列中发送一条扣减数据库库存的消息,异步进行数据库扣减,实现最终一致性。

再比如用户评价,如果量太大,就可以把评价从同步写转为异步写,还有评价后会给一些奖励,也可以异步。

5. 多级降级

从距离用户远近的角度,可以分为以下3个层面:

  • 1.页面JS降级开关

主要控制页面功能的降级,在页面中通过JS脚本部署来控制在适当时机开启/关闭开关。

  • 2.接入层降级开关

在请求入口进行控制,请求进入后,会首先进入接入层,例如 Nginx,在其中根据实际情况进行自动/人工降级。

接入层的控制功能是很强大的,可以实现秒级切换、增量式切换(按照机器组开启)、细粒度服务开关、超时自动降级。

  • 3.应用层降级开关

在应用中配置相应的功能开关,根据实际情况进行自动/人工降级。

内容整理自《亿级流量网站架构核心技术》

你可能感兴趣的:(微服务,分布式架构)