Hystrix使用

1.添加Hystrix的依赖

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

为什么要使用服务降级

首先我们可以自行测试两个请求
1.正常的请求
2.有延迟的请求(就是用一个线程加一个睡眠时间，达到延迟的要求)
首先在正常情况是没有问题的，但是一旦用Jmeter对其中的请求进行压力测试，另一个请求就会造成请求延迟的情况，原因：tomcat的默认的工作线程数（20000）被打满了，没有多余的线程来分解压力和处理
3.这时如果有消费者来调用请求就会造成消费者被拖慢
原因：端口同一层次的其它接口服务被困死，因为tomcat线程池里面的工作线程已经被挤占完毕。

正因为有上述故障或不佳表现才有我们的降级/容错/限流等技术诞生。

降级容错解决的维度要求

超时导致服务器变慢(转圈) - 超时不再等待
出错(宕机或程序运行出错) - 出错要有兜底

解决：

• 对方服务(8001)超时了，调用者(80)不能一直卡死等待，必须有服务降级。
• 对方服务(8001)down机了，调用者(80)不能一直卡死等待，必须有服务降级。
• 对方服务(8001)OK，调用者(80)自己出故障或有自我要求(自己的等待时间小于服务提供者)，自己处理降级。

Hystrix之服务降级支付侧fallback

降级配置 - @HystrixCommand
8001先从自身找问题
设置自身调用超时时间的峰值，峰值内可以正常运行，超过了需要有兜底的方法处埋，作服务降级fallback。

8001fallback

业务类启用 - @HystrixCommand报异常后如何处理

—旦调用服务方法失败并抛出了错误信息后，会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法

@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler", commandProperties = {
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000")
    })
    public String paymentInfo_TimeOut(Integer id) {
        try {
            TimeUnit.MILLISECONDS.sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "线程池:  " + Thread.currentThread().getName() + " id:  " + id + "\t" + "O(∩_∩)O哈哈~" + "  耗时(秒): 3";
    }
	//出问题用来善后的方法
    public String paymentInfo_TimeOutHandler(Integer id) {
        return "线程池:  " + Thread.currentThread().getName() + " paymentInfo_TimeOutHandler 中的id:  " + id + "\t" + "kuo(╥﹏╥)o~o(╥﹏╥)o~";
    }

主启动类激活
添加新注解@EnableCircuitBreaker

题外话，切记 - 我们自己配置过的热部署方式对java代码的改动明显
但对@HystrixCommand内属性的修改建议重启微服务

@EnableHystrix和@EnableCircuitBreaker有什么区别

@EnableHystrix继承了@EnableCircuitBreaker并对其进行封装。 两个注解都是激活hystrix的功能，我们根据上面代码得出来结论，只需要在服务启动类加入@EnableHystrix注解即可，无须增加@EnableCircuitBreaker注解，本身@EnableHystrix注解已经涵盖了EnableCircuitBreaker的功能。