总结：Spring boot熔断

一、介绍

1、熔断的目的：是为了保证服务高可用，不能因为系统中的一个小服务不可用，从而导致整个系统崩溃。
2、熔断的原理：对于使用相关注解的类或者方法，系统会监控其错误，如果多次出现同一个错误，且达到阈值，则打卡熔断开关，熔断开关打开后，不再访问远程服务，而是直接调用预先准备的失败方法。当熔断开关过期后，会尝试再次访问远程服务，这个时候的熔断开关是半开半闭状态的。有些服务会直接失败，有些会继续访问远程服务。
（至于熔断开关的过期时间多久，这个不确定。以及过期后重试远程服务比例，这些设置暂不清楚）

二、雪崩效应

在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。

如果下图所示：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)来隔离资源.

五、熔断策略

• Closed: 关闭状态(断路器关闭)，所有请求都正常访问。
• Open:打开状态(断路器打开)，所有请求都会被降级。Hystix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全关闭。 默认失败比例的阈值是50%，请求次数最少不低于20次 。
• Half Open:半开状态，Closed状态不是永久的， 关闭后会进入休眠时间(默认是5S) 。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会完全打开断路器，否则继续保持关闭，再次进行休眠计时。

六、Hystrix线程隔离技术

1、什么是线程池隔离技术？

线程隔离就是服务访问每个服务组件都是单独的线程池，如下所示：每个服务根据需求配置一定的线程池数量

#hubble-biz
hystrix.threadpool.hubble-biz.coreSize=150
hystrix.threadpool.hubble-biz.maxQueueSize=1000
hystrix.threadpool.hubble-biz.queueSizeRejectionThreshold=800

#hubble-biz-host
hystrix.threadpool.hubble-biz-host.coreSize=80
hystrix.threadpool.hubble-biz-host.maxQueueSize=1000
hystrix.threadpool.hubble-biz-host.queueSizeRejectionThreshold=800

#hubble-biz-cm
hystrix.threadpool.hubble-biz-cm.coreSize=80
hystrix.threadpool.hubble-biz-cm.maxQueueSize=1000
hystrix.threadpool.hubble-biz-cm.queueSizeRejectionThreshold=800

2、为什么要线程隔离？

避免单个服务处故障，耗尽所有线程资源。

比如我们现在有3个业务调用分别是查询订单、查询商品、查询用户，且这三个业务请求都是依赖第三方服务-订单服务、商品服务、用户服务。三个服务均是通过RPC调用。当查询订单服务，假如线程阻塞了，这个时候后续有大量的订单查询请求过来，那么容器中的线程数量则会持续增加直致CPU资源耗尽到100%，整个服务对外不可用，集群环境下就是雪崩。如下图

3、实现原理

一个大Map对象，key即应用的名称，每个应用名称对应一个线程池。

final static ConcurrentHashMap<String, HystrixThreadPool> threadPools = new ConcurrentHashMap<String, HystrixThreadPool>();
threadPools.put(“hystrix-order”, new HystrixThreadPoolDefault(threadPoolKey, propertiesBuilder));

参考：

熔断器Hystrix

springboot 的熔断

Hystrix线程隔离技术解析-线程池

踩坑 Spring Cloud Hystrix 线程池队列配置