springcloud服务状态监控（SpringCloud系列服务雪崩服务熔断）
springcloud服务状态监控（SpringCloud系列服务雪崩服务熔断）这里的服务熔断指的就是当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。主要是用来在微服务系统中防止出现服务雪崩现象的。熔断器其实可以理解为类似于电表的保险丝，一旦某个时刻电压过载，那么保险丝就熔断了，跳闸，反之整个电路因为电力过载而烧掉，起火等灾难的出现。所以服务雪崩产生的根本原因是在调用链路中链路的某一个服务因为执行业务时间过长，或者大规模出现异常导致自身服务不可用，并且将这种不可用进行放大的情况。就像雪崩一样，雪崩的出现往往是因为山顶的一刻雪球的滚动，从而导致不断的放大，从而导致的雪崩的出现。如果系统没有设计处理好，服务雪崩是微服务中很容易出现的情况，从而会导致整个系统的不可用性，造成难以估量的损失，那么如何解决微服务中如何解决服务雪崩的问题呢？主要的解决方案有服务熔断
我们知道在微服务的项目中，Spring Cloud进行接口调用时，一般是需要使用Feign进行接口调用，如果某个接口或者服务出现了请求错误或者服务故障，很有可能导致服务雪崩的问题，导致整个系统服务不可用。服务雪崩解决方案中主要有服务熔断和服务降级两个方式，今天就一起学习下。
什么是服务雪崩在微服务之间进行通信服务调用由于某一个服务故障，导致级联服务故障的现象叫做雪崩效应。雪崩效应描述的是提供方不可用，导致消费方不可用并将不可用逐渐放大的过程。
比如有三个服务：用户服务调用商品服务，商品服务调用库存服务，调用关系如下图：
如果有一时刻用户服务的流量波动很大，流量经常会突然性增加，那么在这种情况下，就算用户服务能够扛着请求，但是商品服务或者库存服务也未必能够扛住这突发性的海量请求。这时候库存服务很可能因为扛不住请求，而变得不可用，那么商品服务的请求也会变得阻塞，慢慢耗尽商品服务的线程资源，这时候商品服务也会变得不可用了，同理会导致用户服务也变得不可用。
所以服务雪崩产生的根本原因是在调用链路中链路的某一个服务因为执行业务时间过长，或者大规模出现异常导致自身服务不可用，并且将这种不可用进行放大的情况。就像雪崩一样，雪崩的出现往往是因为山顶的一刻雪球的滚动，从而导致不断的放大，从而导致的雪崩的出现。
如果系统没有设计处理好，服务雪崩是微服务中很容易出现的情况，从而会导致整个系统的不可用性，造成难以估量的损失，那么如何解决微服务中如何解决服务雪崩的问题呢？
主要的解决方案有服务熔断和服务降级！
什么是服务熔断熔断器其实可以理解为类似于电表的保险丝，一旦某个时刻电压过载，那么保险丝就熔断了，跳闸，反之整个电路因为电力过载而烧掉，起火等灾难的出现。
这里的服务熔断指的就是当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。主要是用来在微服务系统中防止出现服务雪崩现象的。
这里微服务中的熔断器一般主要使用的Hystrix熔断器组件。熔断器本身是一种开关装置，当某个服务单元发生故障之后，通过熔断器Hystrix的故障监控，某个异常条件被触发，直接熔断整个服务，向调用方法返回一个符合预期的并且可以处理的备选响应，而不是长时间的等待或者抛出无法处理异常，就保证了服务调用方的线程不会长时间占用，避免故障在级联链路系统中的蔓延、扩大、直至产生服务的雪崩，并且如果目标服务转好，则恢复调用，服务熔断是解决服务雪崩的重要手段之一。
使用熔断器首先就需要在自己所有的微服务中引用Hystrix熔断器组件，一旦引用了Hystrix熔断器组件，并开启熔断器，那么就具有了服务的熔断功能。
服务熔断一般采用断路器模式。当某个服务被调用时，断路器就会监控这个调用，如果调用的时间太长，断路器将会介入并中断调用。此外，断路器将监视所有对远程资源的调用，如对某一个远程资源的调用失败次数足够多（默认是10s内20次请求调用失败或者10s内超过50%的请求失败），那么断路器会出现并采取快速失败，阻止将来调用此远程资源的请求。
什么是服务降级服务降级指的是服务压力剧增的时候根据当前业务的情况以及流量对一些服务和页面进行策略的降级，以此来缓解服务器的压力，保证核心任务的进行，同时保证部分甚至大部分服务能够得到正确的响应，也就是当前请求处理不了了或者出错了， 给一个默认的返回。可以理解为牺牲小我，成就大我，即当网站服务的流量突然激增的时候，为了保证系统核心服务的正常进行，有策略地关闭微服务中某些小的边缘性的服务，从而保证系统核心服务的正常进行。
比如在双11的时候，为了保证下订单、付款、添加购物车等这些核心功能的正常，可能会牺牲一些确认收货、评价、删除订单等这些不是很核心、很紧急的服务，这些服务可以在以后网站的流量并不是很大的时候恢复对于系统的正常运行没有影响，往往这时候可能比如评价的时候会提示系统繁忙，请稍后再试等等。
区别
1、熔断和降级触发的原因不一样，服务熔断一般是某个服务的故障引起的，而服务降级则是从整体的负荷考虑的；
2、它们管理目标的层次不一样，熔断其实是一个框架级的处理，每个微服务都需要。而降级一般需要对业务进行层级区分，即核心服务、边缘服务，一般从外围的边缘服务开始进行降级。
共同点
1、它们的目的一致，都是从系统的可用性和可靠性的角度考虑，为了防止整个系统的反应缓慢或者崩溃，而采用的策略。
2、它们达到的目的都是某些服务不可用或者不可达，但是整体核心功能正常。
3、它们的粒度一致，都是服务级别的，即影响的是服务。
4、自治性要求高，熔断模式一般是由服务基于策略地自动触发，降级虽然可以人为处理，但是在微服务的架构下，完全依靠人为显然不可行，所以需要进行开关预设、配置中心。
服务熔断可以理解为服务降级的一种，因为熔断必然会触发降级，区别就是熔断在于对调用链路的保护，降级是对整个系统过载的一种保护。
作者：jiangxia_1024
链接：https://juejin.cn/post/7116891891890651149
来源：稀土掘金
