SpringCloud---熔断降级理解、Hystrix实战(五)

https://www.cnblogs.com/qdhxhz/p/9581440.html

https://blog.csdn.net/chenxyz707/article/details/80913725

一、概念

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实战

使用到的组件包括：Eureka、Feign包括以下三个项目：

（1）Eureka-server： 8081 注册中心

（2）product-server ：8001 商品微服务

（3）order-server ： 9001 订单微服务

注册中心、商品微服务、在之前博客都已搭建，这里就不重复写。这里只写order-server微服务。

创建：

https://github.com/cwn132/service-consumer

三、结合redis模拟熔断降级服务异常报警通知实战