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依赖

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

 

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

　　port: 1004

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

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

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

 1  /**
 2      * 锁票业务
 3      * @return
 4      * @throws InterruptedException
 5      */
 6     @ResponseBody
 7     @GetMapping(value="/lockTicket")
 8     @HystrixCommand(fallbackMethod="lockTicketFallback")
 9     public Map<String,Object> lockTicket() throws InterruptedException{
10         Thread.sleep(2000);
11         Map<String,Object> map=new HashMap<String,Object>();
12         map.put("code", 200);
13         map.put("msg", "锁定的车票数据xxxxx");
14         return map;
15     }
16 
17     /**
18      * 模拟锁票超时 或者 系统故障的回调函数
19      * @return
20      * @throws InterruptedException
21      */
22     public Map<String,Object> lockTicketFallback() throws InterruptedException{
23         Map<String,Object> map=new HashMap<String,Object>();
24         map.put("code", 500);
25         map.put("msg", "系统出错，稍后重试");
26         return map;
27     }

 第五步：测试

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

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

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

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

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

很好的报错提示信息；

 

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

 1  /**
 2      * 锁票业务
 3      * @return
 4      */
 5     @SuppressWarnings("unchecked")
 6     @GetMapping(value="/lockTicket")
 7     @ResponseBody
 8     public Map<String,Object> lockTicket(){
 9         System.out.println("-----调用锁票远程服务接口---------");
10         return restTemplate.getForObject(URL+"/lockTicket/", Map.class); 11 }

 

最后后我们来测试下；

先启动三个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配置文件加上 

 1 hystrix:
 2 
 3   command:
 4 
 5     default:
 6 
 7       execution:
 8 
 9         isolation:
10 
11           thread:
12 
13             timeoutInMilliseconds: 3000

 

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

 测试结果：

OK 默认时间生效！

 

转载于:https://www.cnblogs.com/newAndHui/p/10635308.html