There are a lot of people will be in service degradation and service fuse mix that is one thing!
Why do I have such a misunderstanding it?
For the following scenario, as shown when the call , repeatedly failed to reach a certain threshold, will not go to tune , but will downgrade method to perform a local! For such a mechanism: binding Hystrix in Spring cloud, which was referred to fuse downgrade!
Service AService BService AService B
So I had to think that is one thing, after all fuse together and downgrade occurs, and the concept both too close to it!
text
Avalanche Service
OK, we start with the service from the avalanche! Suppose there is a call chain
By this time, Service Athe flow of volatile, often sudden increase in traffic! So in this case, even if the Service Aenergy Go On request, Service Band Service Cmay not be able Go On this burst request.
At this time, if Service Cbecause Kangbu Zhu request, becomes unavailable. Then the Service Brequest will be blocked, slowly run out of Service Bthread resources, Service Bwill become unavailable. Then, Service Aalso unavailable, the process shown below
As shown above, a service fails, resulting in the case of the whole link services are failed, we call service avalanche.
ps：Who invented this word is really necessary to install 13 interview!
So, service fuse and service degradation can be seen as a means to solve one of an avalanche of service.
Service fuse
那么，什么是服务熔断呢？
服务熔断：当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。
需要说明的是熔断其实是一个框架级的处理，那么这套熔断机制的设计，基本上业内用的是断路器模式，如Martin Fowler提供的状态转换图如下所示
- 最开始处于
closed状态，一旦检测到错误到达一定阈值，便转为open状态； - 这时候会有个 reset timeout，到了这个时间了，会转移到
half open状态； - 尝试放行一部分请求到后端，一旦检测成功便回归到
closed状态，即恢复服务；
业内目前流行的熔断器很多，例如阿里出的Sentinel,以及最多人使用的Hystrix
在Hystrix中，对应配置如下
//滑动窗口的大小，默认为20
circuitBreaker.requestVolumeThreshold
//过多长时间，熔断器再次检测是否开启，默认为5000，即5s钟
circuitBreaker.sleepWindowInMilliseconds
//错误率，默认50%
circuitBreaker.errorThresholdPercentage每当20个请求中，有50%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。直到5s钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。
这些属于框架层级的实现，我们只要实现对应接口就好！
服务降级
那么，什么是服务降级呢？
这里有两种场景:
- 当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，增加响应速度！
- 当下游的服务因为某种原因不可用，上游主动调用本地的一些降级逻辑，避免卡顿，迅速返回给用户！
其实乍看之下，很多人还是不懂熔断和降级的区别!
其实应该要这么理解:
- 服务降级有很多种降级方式！如开关降级、限流降级、熔断降级!
- 服务熔断属于降级方式的一种！
可能有的人不服，觉得熔断是熔断、降级是降级，分明是两回事啊！其实不然，因为从实现上来说，熔断和降级必定是一起出现。因为当发生下游服务不可用的情况，这个时候为了对最终用户负责，就需要进入上游的降级逻辑了。因此，将熔断降级视为降级方式的一种，也是可以说的通的！
我撇开框架，以最简单的代码来说明！上游代码如下
try{
//调用下游的helloWorld服务
xxRpc.helloWorld(); }catch(Exception e){ //因为熔断，所以调不通 doSomething(); }注意看，下游的helloWorld服务因为熔断而调不通。此时上游服务就会进入catch里头的代码块，那么catch里头执行的逻辑，你就可以理解为降级逻辑!