架构之服务降级

原文链接:https://www.cnblogs.com/zhaochenguang/p/11042655.html

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

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

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

1. 自动化维度

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

1. 功能维度

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

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脚本部署来控制在适当时机开启/关闭开关。

1. 接入层降级开关

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

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

1. 应用层降级开关

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