架构设计 -- 服务降级

架构设计 -- 服务降级

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

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

降级策略有不少种，能够从下面3个维度分为5种策略：

1. 自动化维度

包括：自动开关降级、人工开关降级。

1. 功能维度

包括：读服务降级、写服务降级。

1. 系统层次维度

包括：多级降级。

 

 1. 自动开关降级

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

• 超时

调用远程非核心服务时，响应过慢后自动降级，先不调了。

须要配置好超时时间和超时重试次数。

• 统计失败次数

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

• 故障

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

• 限流

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

2. 手动开关降级

自动降级是根据系统出现的一些问题进行响应，但在系统尚未出现问题时，我就想降级某些服务，好比促销立刻开始了，能够预知访问量很大，咱们提早就把推荐服务关掉；再好比新功能想上线进行灰度测试，当新功能不符合预期时我想立刻切换回老服务。

这类需求就须要使用能够人工控制的开关来实现。

开关能够存放到配置文件、数据库、Redis/Zookeeper等位置，按期同步开关数据。

分布式系统中一般会建立一个配置中心，对整个系统中的配置开关进行集中管理，提供 Web UI 界面进行便捷操做。目前有一些开源方案能够选择，例如 ZooKeeper、Diamond、Etcd 三、Consul。

3. 读服务降级

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

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

4. 写服务降级

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

例如扣减库存的操做，正常状况下的设计通常是：

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

方案2：先扣减 Redis 缓存，同步扣减数据库，若是失败则回滚 Redis 缓存。

当数据库性能跟不上时，就须要采用异步方式了：

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

再好比用户评价，若是量太大，就能够把评价从同步写转为异步写，还有评价后会给一些奖励，也能够异步。

5. 多级降级

从距离用户远近的角度，能够分为如下3个层面：

1. 页面JS降级开关

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

1. 接入层降级开关

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

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

1. 应用层降级开关

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