熔断降级理解

1、为什么需要熔断降级

（1）需求背景

它是系统负载过高，突发流量或者网络等各种异常情况介绍，常用的解决方案。

在一个分布式系统里，一个服务依赖多个服务，可能存在某个服务调用失败，比如超时、异常等，如何能够保证在一个依赖出问题的情况下，不会导致整体服务失败。

比如：某微服务业务逻辑复杂，在高负载情况下出现超时情况。

内部条件：程序bug导致死循环、存在慢查询、程序逻辑不对导致耗尽内存

外部条件：黑客攻击、促销、第三方系统响应缓慢。

（2）解决思路

解决接口级故障的核心思想是优先保障核心业务和优先保障绝大部分用户。比如登录功能很重要，当访问量过高时，停掉注册功能，为登录腾出资源。

（3）解决策略

熔断，降级，限流，排队。

2、什么是熔断

一般是某个服务故障或者是异常引起的，类似现实世界中的‘保险丝’，当某个异常条件被触发，直接熔断整个服务，而不是一直等到此服务超时，为了防止防止整个系统的故障，

而采用了一些保护措施。过载保护。比如A服务的X功能依赖B服务的某个接口，当B服务接口响应很慢时，A服务X功能的响应也会被拖慢，进一步导致了A服务的线程都卡在了X功能

上，A服务的其它功能也会卡主或拖慢。此时就需要熔断机制，即A服务不在请求B这个接口，而可以直接进行降级处理。

3、什么是降级

服务器当压力剧增的时候，根据当前业务情况及流量，对一些服务和页面进行有策略的降级。以此缓解服务器资源的的压力，以保证核心业务的正常运行，同时也保持了客户和大部分客户的得到正确的响应。

自动降级：超时、失败次数、故障、限流

（1）配置好超时时间(异步机制探测回复情况)；

（2）不稳的的api调用次数达到一定数量进行降级(异步机制探测回复情况)；

（3）调用的远程服务出现故障(dns、http服务错误状态码、网络故障、Rpc服务异常)，直接进行降级。

人工降级：秒杀、双十一大促降级非重要的服务。

4、熔断和降级异同

相同点：

1）从可用性和可靠性触发，为了防止系统崩溃

2）最终让用户体验到的是某些功能暂时不能用

不同点：

1）服务熔断一般是下游服务故障导致的，而服务降级一般是从整体系统负荷考虑，由调用方控制

2）触发原因不同，上面颜色字体已解释

5、熔断到降级的流程讲解

Hystrix提供了如下的几个关键参数，来对一个熔断器进行配置：

circuitBreaker.requestVolumeThreshold    //滑动窗口的大小，默认为20 
circuitBreaker.sleepWindowInMilliseconds //过多长时间，熔断器再次检测是否开启，默认为5000，即5s钟 
circuitBreaker.errorThresholdPercentage  //错误率，默认50%

3个参数放在一起，所表达的意思就是：

每当20个请求中，有50%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。直到5s钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。

这里面有个很关键点，达到熔断之后，那么后面它就直接不去调该微服务。那么既然不去调该微服务或者调的时候出现异常，出现这种情况首先不可能直接把错误信息传给用户，所以针对熔断

我们可以考虑采取降级策略。所谓降级，就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。

这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强，当然这也要看适合的业务场景。

hystrix 解决服务雪崩效应

Hystri简介

Hystrix是Netflix开源的一款针对分布式系统的延迟和容错库，目的是用来隔离分布式服务故障。它提供线程和信号量隔离，以减少不同服务之间资源竞争带来的相互影响;提供优雅降级机制;提供熔断机制使得服务可以快速失败，而不是一直阻塞等待服务响应，并能从中快速恢复。Hystrix通过这些机制来阻止级联失败并保证系统弹性、可用 .

1、服务雪崩效应

默认情况下tomcat只有一个线程池去处理客户端发送的所有服务请求，这样的话在高并发情况下，如果客户端所有的请求堆积到同一个服务接口上，就会产生tomcat的所有线程去处理该服务接口，可能会导致其他服务接口访问延迟；严重致始整个项目都挂掉.

2、Hystrix服务保护框架，在微服务中Hystrix为我们解决了哪些事情？

Hystrix 别名“豪猪”

1）断路器

2）服务降级

3）服务熔断

4）服务隔离机制

5）服务雪崩效应

–》连环雪崩效应，如果比较严重的话，可能会导致整个微服务接口无法访问，所有服务都会瘫痪

3、解决服务雪崩效应原理：

1）服务降级

在高并发情况下，防止用户一直等待，使用服务降级方式（返回一个友好的提示直接给客户端，不会去处理请求，调用fallback本地方法），目的是为了用户体验

比如秒杀–当前请求人数过多，请稍后重试。（在tomcat中没有线程进行处理客户端请求的时候，不应该让用户一直转圈等待。）

2）服务熔断

例如保险丝，服务熔断的目的是为了保护服务，在高并发情况下，如果请求达到了一定的极限（可以自己设置阈值），如果流量超出了设置的阈值，会自动开启保护服务功能，使用服务降级方式返回一个友好的提示。

熔断机制和服务降级一起使用。

默认阈值为10个

3）服务隔离

采用线程池隔离，每个服务接口都有自己独立的线程池，每个线程池互不影响；

缺点：CPU占用率非常高。

不是所有的接口都要去采用线程池隔离，只有核心关键接口才需要

4、Hystrix设置禁止超时时间

当一个服务被大量线程数访问时，另外一个服务能访问，但是却跳到了fallback方法中，这是因为Hystrix需要设置禁止超时时间；

@HystrixCommand注解默认开启了线程池隔离，服务降级，服务熔断

feign超时时间需要设置，否则会报错

java.net.SocketTimeoutException: Read timed out

–》我设置这一步时，在yml文件中添加相关配置，idea没有给出相应提示，本来还有点怀疑，但是运行之后竟然成功
了。

5、Hystrix实现方式

Hystrix有两种方式实现：一种是注解，一种是接口

1）Hystrix的注解方式业务代码和return调用的方法是属于同一个线程的

*2）*而第二种方式，业务代码和return调用的方法是两个线程，并且属于不同线程池

3）第一种方式比较冗余，所以最好采用第二种方式

备注

1）这个Hystrix的超时时间会影响所有的接口，不是只针对@HystrixCommand注解的接口

2）如果调用其他接口超时的时候（默认是1秒时间），默认情况下业务逻辑是可以正常执行的，但是为了避免客户端等待，会直接执行服务降级方法。

常见错误

1）java.util.concurrent.TimeoutException: null
2）java.lang.RuntimeException: Hystrix circuit short-circuited and is OPEN

6.为什么要用Hystrix?

在一个分布式系统里，一个服务依赖多个服务，可能存在某个服务调用失败，

比如超时，异常等，如何能保证在一个依赖出问题的情况下，不会导致整体服务失败，

通过Hystrix就可以解决

7.功能

提供熔断，隔离，Fallback，cache，监控等功能

8.熔断后怎么处理？

出现错误后，可以Fallback错误的处理信息