说起springcloud熔断让我想起了去年股市中的熔断，多次痛的领悟，随意实施的熔断对整个系统的影响是灾难性的，好了接下来我们还是说正事。
熔断器
雪崩效应
在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。
如果下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。
熔断器（CircuitBreaker）
熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。
熔断器模式就像是那些容易导致错误的操作的一种代理。这种代理能够记录最近调用发生错误的次数，然后决定使用允许操作继续，或者立即返回错误。 熔断器开关相互转换的逻辑如下图：
熔断器就是保护服务高可用的最后一道防线。
Hystrix特性
1.断路器机制
断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.
2.Fallback
Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.
3.资源隔离
在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池. 这样做的主要优点是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响. 但是带来的代价就是维护多个线程池会对系统带来额外的性能开销. 如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话, 可以使用Hystrix的信号模式(Semaphores)来隔离资源.
Feign Hystrix
因为熔断只是作用在服务调用这一端，因此我们根据上一篇的示例代码只需要改动spring-cloud-consumer项目相关代码就可以。因为，Feign中已经依赖了Hystrix所以在maven配置上不用做任何改动。
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 ";
}
}
3、添加fallback属性
在HelloRemote类添加指定fallback类，在服务熔断的时候返回fallback类中的内容。
@FeignClient(name= "spring-cloud-producer",fallback = HelloRemoteHystrix.class)
public interface HelloRemote {
@RequestMapping(value = "/hello")
public String hello(@RequestParam(value = "name") String name);
}
改动点就这点，很简单吧。
4、测试
那我们就来测试一下看看效果吧。
依次启动spring-cloud-eureka、spring-cloud-producer、spring-cloud-consumer三个项目。
浏览器中输入：http://localhost:9001/hello/neo
返回：hello neo，this is first messge
说明加入熔断相关信息后，不影响正常的访问。接下来我们手动停止spring-cloud-producer项目再次测试：
浏览器中输入：http://localhost:9001/hello/neo
返回：hello neo, this messge send failed
根据返回结果说明熔断成功。
参考：
微服务框架Spring Cloud介绍 Part5: 在微服务系统中使用Hystrix, Hystrix Dashboard与Turbine
作者：纯洁的微笑
出处：http://www.ityouknow.com/
版权归作者所有，转载请注明出处
Post Directory
feign jar中没有hystrix啊 是版本问题吗
不好意思 feign.hystrix.enabled=true 这段是有用的 知识在properties 它没识别 有警告我还以为没有用
idea提示有两个TestClient（不影响程序运行）使用@primary可干掉此提示
学习
feign.hystrix.enabled这个为啥在Intellij里不提示呢？请问
你好，请问能不能把spring cloud 和 spring boot的版本发一下，可能版本不一致，我按着步骤但熔断没有生效，一直是500错误
@Ouchujian https://gitee.com/wangxiaochao121/springcloud,这个版本的搭配没有问题，<spring-cloud.version>Greenwich.SR1</spring-cloud.version>，springboot版本2.1.3.RELEASE
感谢!
那它如何区分注入的服务是远程的还是用@component注解的服务呢？难道优先注入远程的？远程服务不可用则注入fallback的？
上一篇文章的例子没有添加feign的maven引用，这次的hystrix没有添加对应的maven引用，其他的都说得很好， 对于新手可能就不容易理解了。
请问一下.停掉服务提供者之后,程序走的fallback.
然后我重新启动了服务提供者,程序依然走的是fallback
这里面应用的是不是前面的断路器机制?
我需要等待
您好老师，我也遇到@Lichengdi同样的问题。服务提供者重启后，还走fallback。
解决了吗兄弟
我测试的情况是第一次把服务提供者关闭后 eurka注册中心中还是有该服务，请求时会触发熔断，然后再启动提供者，第一次请求还是报的容错的内容。我给eureka配置加上eureka.server.enable-self-preservation=false后，第一次关闭提供者，注册中心一样还是有服务，再启动后第一次还是容错的内容。过来一段时间我看注册中心服务才少了一个。不知道是不是这个配置没生效，关闭了服务 注册中心还是会存留一段时间
我在eureka服务中心配置eureka.server.enable-self-preservation=false，当关掉product后还是能看到eureka里边有这个服务，调用正常还是走fallback
Feign+Hystrix ,一直是走fallback 这是为啥啊，难道是我Hystrix 配置不对吗（我的注册中心是nacos）