服务雪崩介绍

服务提供者不可用导致服务调用者也跟着不可用，以此类推引起整个链路中的所有微服务都不可用，

服务提供者A因为某种原因出现故障，那么服务调用者服务B依赖于服务A的请求便无法成功调用其提供的接口，假以时日依赖于服务A的请求越来越多导致服务B的Tomcat资源耗尽，造成服务B线程阻塞，导致服务B也出现故障。那么假如服务C依赖于服务B由于服务B也出现了故障导致服务C出现故障。以此类推引起整个链路中的所有微服务都不可用。

① 理解：

② 解决

将超时时间缩短（不可取）

优点：

• 简单
  

缺点：

• 有的服务超时时间都是提前预定好的
  
• 在一些服务中可以会大量的代码或者连接DB等，这时连接时间如果如果不够代码的执行时间，那么一个正常的业务也无法执行完
  

设置拦截器

概述

在微服务中可以解决服务雪崩，称为熔断器或者断路器。能够防止分布式项目中出现联动故障（一个服务宕机，其他服务也无法正常运行）。

Hystrix中设置了类似拦截器的方案，如果需要调用的服务发生了宕机，那么就不调用这台机器，直接使用备选方案。

使用

① rent-car-service

配置文件

1. server:
2.   port: 8080
3. spring:
4.   application:
5.     name: rent-car-service
6. eureka:
7.   client:
8.     service-url:
9.       defaultZone: http://localhost:8761/eureka
10.   instance:
11.     hostname: localhost
12.     instance-id: ${eureka.instance.hostname}:${spring.application.name}:${server.port}
13.     lease-renewal-interval-in-seconds: 5

API：

1. @RestController
2. public class CarController {
3. 
4. @GetMapping("rent")
5. public String rent(){
6. return "租车成功";
7.     }
8. }

② conusmer-service

hystrix依赖

1. <dependency>
2. <groupId>org.springframework.cloud</groupId>
3. <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
4. </dependency>

配置文件

1. server:
2.   port: 8081
3. spring:
4.   application:
5.     name: consumer-service
6. eureka:
7.   client:
8.     service-url:
9.       defaultZone: http://localhost:8761/eureka
10.   instance:
11.     hostname: localhost
12.     instance-id: ${eureka.instance.hostname}:${spring.application.name}:${server.port}
13.     lease-renewal-interval-in-seconds: 5

OpenFeign接口

1. @FeignClient(value = "rent-car-service",fallback = ConsumerRentCarFeignHystrix.class) // 指定发生服务雪崩时执行哪个类
2. public interface ConsumerRentCarFeign {
3. 
4. @GetMapping("rent")
5.     String rent();
6. }

Hystrix实现类

1. @Component // 添加到IOC容器中
2. public class ConsumerRentCarFeignHystrix implements ConsumerRentCarFeign {
3. 
4. /**
5.      * 备用方案
6.      * 当调用的服务挂掉后执行本方法
7.      * @return
8.      */
9. @Override
10. public String rent() {
11. return "网络异常 稍后重试";
12.     }
13. }

API

1. @RestController
2. public class ConsumerController {
3. 
4. @Autowired
5. private ConsumerRentCarFeign consumerRentCarFeign;
6. 
7. @GetMapping("consumerToRent")
8. public String consumerToRent(){
9.         System.out.println("有人来租车");
10. return consumerRentCarFeign.rent();
11.     }
12. }

开启Hystrix

1. feign:
2.   hystrix:
3.     enabled: true

断路器思想

常用配置

1. hystrix: #hystrix 的全局控制
2.   command:
3. default: #default 是全局控制，也可以换成单个方法控制，把 default 换成方法名即可
4.       fallback:
5.         isolation:
6.           semaphore:
7.             maxConcurrentRequests: 1000 #信号量隔离级别最大并发数
8.       circuitBreaker:
9.         enabled: true #开启断路器
10.         requestVolumeThreshold: 3 #失败次数（阀值）
11.         sleepWindowInMilliseconds: 20000 #窗口时间
12.         errorThresholdPercentage: 60 #失败率
13.       execution:
14.         isolation:
15.           Strategy: thread #隔离方式 thread 线程隔离集合和 SEMAPHORE 信号量隔离
16.         thread:
17.           timeoutInMilliseconds: 3000 #调用超时时长

相关面试题

什么是 Hystrix?

防雪崩利器，具备服务降级，服务熔断， 依赖隔离， 监控(Hstrix Dashboard)等功能

什么是服务熔断？熔断器的作用是什么？

首先我们说一下什么是扇出与雪崩效应：多个微服务之间调用的时候，假设微服

务 A 调用了微服务 B 和微服务 C，微服务 B 和微服务 C 又调用了其他的服务，这

就是所谓的扇出，如果扇出的链路上某个微服务的调用响应时间过长，或者是不

可用，那么该微服务调用者就会阻塞线程，占用越来越多的系统资源，进而崩溃。

同理，影响调用者的调用者，进而一步步崩溃，这也就是所谓的雪崩效应。

那么服务熔断机制就是应对雪崩效应的一种微服务链路保护机制，扇出链路

的某个微服务不可用，或者是响应时间过长，会进行服务的降级，进而会熔断该

节点微服务的调用，快速返回错误的响应信息，当检测到该节点微服务调用响应

正常的时候，恢复链路。在 SpringCloud 框架里熔断机制是通过 Hystrix 实现的。

Hystrix 会搞很多个小的线程池比如订单服务请求库存服务是一个线程池，

请求仓储服务是一个线程池，请求积分服务是一个线程池。每个线程池里的线程

仅仅用于请求那个服务，当某个线程池达到阈值时，就会启动服务熔断，服务降

级。如果其他请求继续访问，就直接返回 fallback 的默认值。

什么是服务降级?

服务熔断的时候,在返回的之前做一个熔断处理,比如将请求信息存储到数

据库以便后期数据恢复,我认为这种熔断后的处理指的就是服务降级。优先核心

服务,非核心服务不可用或弱可用。

服务降级案例:双十一:《哎哟喂,被挤爆了.…》或 app 秒杀:《网络开小差

了,请稍后再试…》

在 fallbackMethod (回退函数)中具体实现降级逻辑。

熔断和降级：调用服务失败后快速失败

• 熔断：是为了防止异常不扩散，保证系统的稳定性
  
• 降级：编写好调用失败的补救逻辑，然后对服务直接停止运行，这样这些接口就无法正常调用，但又不至于直接报错，只是服务水平下降
  
• 通过HystrixCommand 或者 HystrixObservableCommand 将所有的外部系统（或者称为依赖）包装起来，整个包装对象是单独运行在一个线程之中（这是典型的命令模式）。
  
• 超时请求应该超过你定义的阈值
  
• 为每个依赖关系维护一个小的线程池（或信号量）；如果它变满了，那么依赖关系的请求将立即被拒绝，而不是排队等待
  
• 统计成功，失败（由客户端抛出的异常），超时和线程拒绝
  
• 打开断路器可以在一段时间内停止对特性服务的所有请求，如果服务的错误百分比通过阈值，手动或自动的关闭断路器。
  
• 当请求被拒绝、连接超时或者断路器打开，直接执行 fallback 逻辑。
  
• 近乎实时监控指标和配置变化。
  

Hystrix如何避免雪崩效应的?

首先要避免雪崩效应的形成 需要一个强大的容错机制,Hystrix 就是实现了超时机制和断路器模式的工具类库

Hystrix主要通过以下几点实现延迟和容错:

包裹请求: 使用HystrixCOmmand 包裹对依赖的调用逻辑,每个命令在独立线程中执行.使用了设计模式种的"命令模式"

跳闸机制: 当服务的错误率超过了一定的阈值时,Hystrix 可以自动或者手动跳闸,停止请求服务一段时间

资源隔离: Hystrix 为每个依赖维护一个小型的线程池或者是信号量,如果该线程吃已满,发送到该依赖的请求立即被拒绝,而不是排队等候,从而加速失败判定.

监控: Hystrix可以近乎实时的监控运行指标和配置的变化,列如 成功,失败,超时和被拒绝的请求等.

回退机制: 当请求失败,超时,被拒绝,或者当断路器打开的时候,执行回退逻辑.回退逻辑由自行提供,列入返回一个缺省值

自我修复: 断路器打开一段时间后 ,会自动进入"半开状态",尝试请求服务,请求通过恢复请求,请求失败则继续断路器开启