SpringCloud5--Hystrix断路器

前面咱们说到，一个复杂的分布式系统面临许多问题，每个服务都存在依赖关系，而这个依赖关系有时候可能会失败，而A调用B和C，B和C又调用其他服务，这种调用关系叫“扇出”，如果扇出的链条上有一个服务出现问题。就会造成“服务雪崩”

服务雪崩

当服务A的流量突然增加，服务A扛得住请求，服务B和服务C未必能扛得住这突发的请求。

如果服务C因为抗不住请求，变得不可用。那么服务B的请求也会阻塞，慢慢耗尽服务B的线程资源，服务B就会变得不可用。紧接着，服务 A也会不可用

一个服务失败，导致整条链路的服务都失败的情形，我们称之为服务雪崩

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和，为了对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。

为了对服务依赖的保护主要有以下三种解决方案

熔断：类似于家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用，如果目标服务情况好转则恢复调用。

隔离：这种模式就像对系统请求按类型划分成一个个小岛的一样，当某个小岛被火少光了，不会影响到其他的小岛。例如可以对不同类型的请求使用线程池来资源隔离，每种类型的请求互不影响，如果一种类型的请求线程资源耗尽，则对后续的该类型请求直接返回，不再调用后续资源。这种模式使用场景非常多，例如将一个服务拆开，对于重要的服务使用单独服务器来部署，再或者多中心。

限流：上述的熔断模式和隔离模式都属于出错后的容错处理机制，而限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。这种模式不能解决服务依赖的问题，只能解决系统整体资源分配问题，因为没有被限流的请求依然有可能造成雪崩效应。

---

更具体的思路概念可以看总概述那一篇章

Hystrix

Hystrix是一个用于处理分布式系统的延迟和容错的开源库.在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等。Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

所以Hystrix是作为服务雪崩的解决方案存在的一个开源库，同样解决服务雪崩现象的还有Sentinel，Resilience4j，zuul等等。

Hystrix的作用

• 服务降级
• 服务熔断
• 服务限流
• 接近实时的监控
• 。。。。。

服务熔断

服务熔断，解决服务雪崩的手段之一，是针对于服务提供方的

服务熔断：当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，进而熔断该节点微服务的调用，快速返回"错误"的响应信息。如果目标服务情况好转则恢复调用。

熔断其实是一个框架级的处理，那么这套熔断机制的设计，基本上业内用的是断路器模式

• 最开始处于closed状态，一旦检测到错误到达一定阈值，便转为open状态；
• 这时候会有个 reset timeout，到了这个时间了，会转移到half open状态；
• 尝试放行一部分请求到后端，一旦检测成功便回归到closed状态，即恢复服务；

在Hystrix中，对应配置如下

//滑动窗口的大小，默认为20
circuitBreaker.requestVolumeThreshold 
//过多长时间，熔断器再次检测是否开启，默认为5000，即5s钟
circuitBreaker.sleepWindowInMilliseconds 
//错误率，默认50%
circuitBreaker.errorThresholdPercentage

每当20个请求中，有50%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。直到5s钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。
熔断机制的注解是@HystrixCommand

服务熔断在Hystrix的实践

pom.xml导包

   <!--  hystrix -->
   <dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-hystrix</artifactId>
   </dependency>

启动类上加上@EnableCircuitBreaker

@SpringBootApplication
@EnableEurekaClient //本服务启动后会自动注册进eureka服务中
@EnableCircuitBreaker//对hystrixR熔断机制的支持
public class DeptProvider8001_Hystrix_App
{
  public static void main(String[] args)
  {
   SpringApplication.run(DeptProvider8001_Hystrix_App.class, args);
  }
}
 

在服务方法上添加@HystrixCommand，一旦调用服务方法失败抛错误，会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法

@RestController
public class DeptController
{
  @Autowired
  private DeptService service = null;
  
  @RequestMapping(value="/dept/get/{id}",method=RequestMethod.GET)
    @HystrixCommand(fallbackMethod = "processHystrix_Get")
  public Dept get(@PathVariable("id") Long id)
  {
   Dept dept =  this.service.get(id);
   if(null == dept)
   {
     throw new RuntimeException("该ID："+id+"没有没有对应的信息");
   }
   return dept;
  }
  
  public Dept processHystrix_Get(@PathVariable("id") Long id)
  {
   return new Dept().setDeptno(id)
           .setDname("该ID："+id+"没有没有对应的信息,null--@HystrixCommand")
           .setDb_source("no this database in MySQL");
  }
}

注意，配置的fallbackMethod方法必须与被@HystrixCommand注解的方法有相通的入参和返回值

否则会报错fallback method wasn’t found: defaultFallback

服务降级

什么叫服务降级？

整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。

这里有两种场景:

• 当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，增加响应速度！
• 当下游的服务因为某种原因不可用，上游主动调用本地的一些降级逻辑，避免卡顿，迅速返回给用户！

上面的场景就是熔断，下面的场景是降级。

应该要这么理解:

• 服务降级有很多种降级方式！如开关降级、限流降级、熔断降级!
• 服务熔断属于降级方式的一种！

熔断和降级必定是一起出现，不可能只出现熔断，不出现降级。当下游服务不可用，为了对用户负责，就要进入上游的降级逻辑

try{
    //调用下游的helloWorld服务
    xxRpc.helloWorld();
}catch(Exception e){
    //因为熔断，所以调不通
    doSomething();
}

!!!所以服务降级处理是在客户端实现完成的，与服务端没有关系。服务熔断是服务端的

Feign+Hystrix的服务降级

Feign+Hystrix有两种方式可以进行服务降级

配置文件
@EnableFeignClients中已经默认打开了断路器功能，所以这里的启动类上不需要再加@EnableCircuitBreaker注解，只需要在feign里面打开hystrix的断路器配置即可

feign: 
  hystrix: 
    enabled: true

方式一

在@FeignClient中为fallback参数指定fallback方法

因为@FeignClient注解的是接口，所以我们必须创建一个实现类，该实现类对应实现的方法就是该服务的降级方法。

@FeignClient(value = "MICROSERVICECLOUD-DEPT",fallback=DeptClientServiceFallback.class)
public interface DeptClientService
{
	@RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
	public Dept get(@PathVariable("id") long id);
	}

@Service
public class DeptClientServiceFallback implements DeptClientService
{
	@Override
	public Dept get(@PathVariable("id") long id){
		return new Dept().setDeptno(id).setDname("该ID：" + id + "没有没有对应的信息,Consumer客户端提供的降级信息,此刻服务Provider已经关闭")
						.setDb_source("no this database in MySQL");
	}
	
}

方式二

在@FeignClient中为fallbackFactory参数指定fallback处理类

同样需要创建一个实现类，该实现类需要实现的是泛型类型的FallbackFactory<（）>，继承create方法，return一个子类的实现类。

@FeignClient(value = "MICROSERVICECLOUD-DEPT",fallbackFactory=DeptClientServiceFallbackFactory.class)
public interface DeptClientService
{
	@RequestMapping(value = "/dept/get/{id}", method = RequestMethod.GET)
	public Dept get(@PathVariable("id") long id);
}

@Component 
public class DeptClientServiceFallbackFactory implements FallbackFactory<DeptClientService>
{
	@Override
	public DeptClientService create(Throwable throwable)
	{
		return new DeptClientService() {
			@Override
			public Dept get(long id)
			{
				return new Dept().setDeptno(id).setDname("该ID：" + id + "没有没有对应的信息,Consumer客户端提供的降级信息,此刻服务Provider已经关闭")
						.setDb_source("no this database in MySQL");
			}

		};
	}
}

服务监控hystrixDashboard

除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控（Hystrix Dashboard），Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，**并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界面。

pom.xml文件添加依赖

   <dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-hystrix</artifactId>
   </dependency>
   <dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
   </dependency> 

启动类添加注解

@SpringBootApplication
@EnableHystrixDashboard
public class DeptConsumer_DashBoard_App
{
  public static void main(String[] args)
  {
   SpringApplication.run(DeptConsumer_DashBoard_App.class,args);
  }
}
 

被监控的微服务都要添加监控依赖

   <!-- actuator监控信息完善 -->
   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-actuator</artifactId>
   </dependency>

直接启动 访问/hystrix就能看到

hystrixDashboard监控方式

Hystrix Dashboard共支持三种不同的监控方式

1，默认的集群监控：通过URL:turbine-hostname:port/turbine.stream开启，实现对默认集群的监控。

2，指定的集群监控：通过URL:turbine-hostname:port/turbine.stream?cluster=[clusterName]开启，实现对clusterName集群的监控。

3，单体应用的监控：通过URL/hystrix-app:port/hystrix.stream开启，实现对具体某个服务实例的监控。

hystrix的资源隔离机制

hystrix支持信号量隔离和线程池隔离

总结对比：

隔离方式	是否支持超时	是否支持熔断	隔离原理	是否是异步调用	资源消耗
线程池隔离	支持，可直接返回	支持，当线程池到达maxSize后，再请求会触发fallback接口进行熔断	每个服务单独用线程池	可以是异步，也可以是同步。看调用的方法	大，大量线程的上下文切换，容易造成机器负载高
信号量隔离	不支持，如果阻塞，只能通过调用协议（如：socket超时才能返回）	支持，当信号量达到maxConcurrentRequests后。再请求会触发fallback	通过信号量的计数器	同步调用，不支持异步	小，只是个计数器

Hystrix是如何通过线程池实现线程隔离的

Hystrix通过命令模式，将每个类型的业务请求封装成对应的命令请求，比如查询订单->订单Command，查询商品->商品Command，查询用户->用户Command。每个类型的Command对应一个线程池。创建好的线程池是被放入到ConcurrentHashMap中，比如查询订单：

final static ConcurrentHashMap<String, HystrixThreadPool> threadPools = new ConcurrentHashMap<String, HystrixThreadPool>();
threadPools.put(“hystrix-order”, new HystrixThreadPoolDefault(threadPoolKey, propertiesBuilder));
当第二次查询订单请求过来的时候，则可以直接从Map中获取该线程池。具体流程如下图：

hystrix线程执行过程和异步化.png