SpringCloud-day08-Hystrix断路器

8.Hystrix断路器

8.1.Hystrix简介

　　在分布式环境中，许多服务依赖项中的一些必然会失败。Hystrix是一个库，通过添加延迟容忍和容错逻辑，帮助你控制这些分布式服务之间的交互。

Hystrix通过隔离服务之间的访问点、停止级联失败和提供回退选项来实现这一点，所有这些都可以提高系统的整体弹性。

　　Hystrix提供了熔断、隔离、Fallback、cache、监控等功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用。

　　hystrix对应的中文名字是“豪猪”，豪猪周身长满了刺，能保护自己不受天敌的伤害，代表了一种防御机制，这与hystrix本身的功能不谋而合，因此Netflix团队将该框架命名为Hystrix，并使用了对应的卡通形象做作为logo。

8.2.服务雪崩效应　

　　当一个请求依赖多个服务的时候：

　　正常情况下的访问：

　　但是，当请求的服务中出现无法访问、异常、超时等问题时（图中的I），那么用户的请求将会被阻塞。

　　如果多个用户的请求中，都存在无法访问的服务，那么他们都将陷入阻塞的状态中。

　　Hystrix的引入，可以通过服务熔断和服务降级来解决这个问题。

8.3.Hystrix服务熔断服务降级　

　　Hystrix服务熔断服务降级@HystrixCommand fallbackMethod

　　熔断机制是应对雪崩效应的一种微服务链路保护机制。

　　当某个服务不可用或者响应时间超时，会进行服务降级，进而熔断该节点的服务调用，快速返回自定义的错误影响页面信息。

　　接下来我们设计一个测试：

　　我们写一个新的带服务熔断的服务提供者项目 microservice-station-provider-hystrix-1004。

　　注意：本质上是拷贝一个服务提供者，在上面添加Hystrix的配置即可，你也可以选择在原来的服务提供者（1001、1002、1003）上直接修改。

　　把配置和代码都复制一份到这个项目里

　　然后修改

　　第一步：在pom.xml文件里面添加hystrix依赖

 <dependency>

     <groupId>org.springframework.cloud</groupId>

     <artifactId>spring-cloud-starter-hystrix</artifactId>

 </dependency>

　　第二步：application.yml修改下端口和实例名称

　　port: 1004

　　instance-id: microservice-ticket-hystrix:1004 #客户端实例名称

　　第三步：启动类名称改成ticketProviderHystrixApplication_1004，以及加下注解支持 @EnableCircuitBreaker

　　第四步：在控制层中新增 lockTicket() ,锁票方法

  /**

      * 锁票业务

      * @return

      * @throws InterruptedException

      */

     @ResponseBody

     @GetMapping(value="/lockTicket")

     @HystrixCommand(fallbackMethod="lockTicketFallback")

     public Map<String,Object> lockTicket() throws InterruptedException{

         Thread.sleep(2000);

         Map<String,Object> map=new HashMap<String,Object>();

         map.put("code", 200);

         map.put("msg", "锁定的车票数据xxxxx");

         return map;

     }

     /**

      * 模拟锁票超时 或者 系统故障的回调函数

      * @return

      * @throws InterruptedException

      */

     public Map<String,Object> lockTicketFallback() throws InterruptedException{

         Map<String,Object> map=new HashMap<String,Object>();

         map.put("code", 500);

         map.put("msg", "系统出错，稍后重试");

         return map;

     }

第五步：测试

这里我正常访问返回的是 200 锁定的车票数据xxxxx

但是我们这里Thread.sleep(2000) 模拟超时；

这里的话我们加上@HystrixCommand注解以及 fallbackMethod

表明这个方法我们再没有异常以及没有超时(hystrix默认1秒算超时)的情况，才返回正常的业务数据；

否则，进入我们fallback指定的本地方法，我们搞的是500 系统出错，稍后重试，有效的解决雪崩效应，以及返回给用户界面

很好的报错提示信息；

在 microservice-ticket-consumer-80项目也要对应的加个方法，用于测试

  /**

      * 锁票业务

      * @return

      */

     @SuppressWarnings("unchecked")

     @GetMapping(value="/lockTicket")

     @ResponseBody

     public Map<String,Object> lockTicket(){

         System.out.println("-----调用锁票远程服务接口---------");

         return restTemplate.getForObject(URL+"/lockTicket/", Map.class);  }

最后后我们来测试下；

先启动三个eureka，再启动带hystrix的provider，最后启动普通的consumer；

通过修改Thread.sleep(2000) 不同的睡眠时间，观察测试结果

浏览器：http://localhost/ticket/lockTicket

当设置睡眠时间为2000毫秒=时，结果如下

当去掉睡眠时间，测试结果如下：

通过上述测试，可以判定hystrix起到了服务降级熔断的作用！

8.4.Hystrix默认超时时间设置

Hystrix默认超时时间是1秒，我们可以通过hystrix源码看到，

找到 hystrix-core.jar com.netflix.hystrix包下的HystrixCommandProperties类

default_executionTimeoutInMilliseconds属性局势默认的超时时间

我们系统里假如要自定义设置hystrix的默认时间的话；

application.yml配置文件加上

 hystrix:

   command:

     default:

       execution:

         isolation:

           thread:

             timeoutInMilliseconds: 3000

修改成3秒然后我们代码里sleep修改成2秒测试；

测试结果：

OK 默认时间生效！