springcloud二 熔断器Hystrix

说熔断器Hystrix,你可以理解成一个保险丝，一旦达到一定错误返回值，就会自动返回错误，每隔5秒检查一次。
在消费者A、消费者B、提供者C
消费者A=>消费者B=>提供者C
Hystrix特性
1.断路器机制
假如提供者C突然报错，消费者A每次都需要请求去拿取这个错误，而造成服务器负载过大甚至宕机，浪费不必要的cpu等待资源，如何避免这种问题，就要说到熔断器，当Hystrix Command请求后端服务失败数量超过一定比例，断路器会切换到开路状态(Open)，这时所有请求会直接失败发送给消费者， 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.
2.Fallback
Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.
3.资源隔离
在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池. 这样做的主要优点是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响. 但是带来的代价就是维护多个线程池会对系统带来额外的性能开销. 如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话, 可以使用Hystrix的信号模式(Semaphores)来隔离资源.

熔断器Hystrix直接拿第一章消费者只需要改动spring-cloud-consumer
1.配置文件,application.properties添加这一条：

feign.hystrix.enabled=true

2.创建回调类,创建HelloRemoteHystrix类继承与HelloRemote实现回调的方法

@Component
public class HelloRemoteHystrix implements HelloRemote{

    @Override
    public String hello(@RequestParam(value = "name") String name) {
        return "hello" +name+", this messge send failed ";
    }
}

4. 2个提供者，1个消费者，熔断器Hystrix加到消费者中
   第一种情况：2个提供者没有关闭正常返回
   第二种情况：关闭一个提供者，熔断器Hystrix会返回三次，然后负载均衡到第2个提供者
   第三种情况：2个提供者直接关闭，熔断器Hystrix直接返回