微服系列之雪崩效应的解决方案

为了系统的可用性和可靠性，为了防止系统的整体缓慢甚至到崩溃，这里介绍三种技术手段应对微服务中的雪崩效应，这三种技术手段分别从系统可用性、可靠性角度出发，尽可能的防止系统出现雪崩现象

1、服务熔断

服务熔断机制是应对雪崩现象中微服务链路保护的一种机制

举例：高压电线，举这个例子最贴切，也特别容易理解，在高压电路中，如果某个地方的电压过高，熔断器(熔断保险丝)就会熔断，保证整个电路不会因为某个地方的电压过高导致整个电路崩溃，换句话说就是：没有熔断器呢，电压高会导致整个地区停电，如果有熔断器呢，电路会得到保障，会把断电的损失降到最低

在微服务架构中，熔断机制也跟上面例子中熔断保险丝有着差不多的作用，当扇出链路的某个服务不可用或者响应超时的时候，就会熔断该节点微服的调用，进行服务降级，快速返回错误的响应信息，当检测到该节点微服务调用响应正常后，会恢复调用链路

注意：

①服务熔断重点在于这个"断"字，在哪里切断什么服务，切断对下游服务的调用

②服务熔断和服务降级往往是一起使用的，Hystrix也是同理

2、服务降级

说得简单点就是：调用的资源不够了，要取舍，舍弃那些优先级和轻重级比较轻的服务，把这些服务先停掉，在调用的时候要给出一个兜底数据，否则难免会出现报错，毕竟调用关系还存在，等并发高峰过去之后，再人为的把对应的服务再打开即可

服务降级一般是从整体考虑，就是当某个服务熔断之后，服务器将不再被调用，此时的客户端可以自己准备一个本地的fallback回调，返回一个缺省值，这样，在调用的时候最起码还能够通，不至于直接挂掉报错

3、服务限流

 其实服务限流是服务降级的增强，就是当服务出现问题的时候，服务降级是直接对现有逻辑进行人为干预，避免服务直接挂掉，但是有些场景，服务降级就不能满足或者直接不可以使用，比如秒杀活动，这种活动，你但凡降级，都会影响到数据的完整性，所以这个时候可以做限流操作，从客户端就开始做限流操作

限流的措施有很多种，比如：

①限制总并发数，比如规定数据库连接池、线程池

②限制瞬时并发数，比如nginx限制瞬时并发连接数

③限制时间窗口内的平均速率，比如Guava的RateLimiter、nginx的limit_req模块，限制每秒的请求平均速率

④限制远程接口调用速率、限制MQ的消费速率等