hystrix容错

现在我们假设一下,服务提供者响应非常缓慢,那么消费者对提供者的请求就会被强制等待,直到服务返回.
在高负载场景下,如果不做任何处理,这种问题很可能造成所有处理用户的请求的线程都被耗尽.
而不能响应用户的进一步请求.

如果是微服务工程,则很有可能出现服务雪崩效应

什么是雪崩效应:

在微服务架构中,根据业务来拆分成一个个的服务,服务与服务之间可以相互调用,在spring cloud 可以用RestTemplate + ribbon 或feign来调用.
为了保证其高可用,单个服务通常会集群部署,由于网络原因或者自身原因,服务并不能保证100%可用,如果单个服务出现问题,调用这个服务就会出现线程阻塞,
此时如果有大量请求涌入,servlet容器的线程资源会被消耗完毕,导致服务瘫痪.服务与服务之间的依赖性,故障会传播,会对整个微服务系统造成灾难性的严重后果,
这就是服务故障的雪崩效应.如果不懂,请看下文:

而此时,A服务的流量波动很大,流量经常突然性增加.那么在这种情况下,就算A服务能扛得住请求,B服务和C服务未必能扛得住这突发的请求.
此时,如果C服务因为扛不住请求,变得不可用,那么B服务的请求也会阻塞,慢慢耗尽B服务的线程资源,B服务就会变得不可用.紧接着,A也会不可用,
这个过程用图来说明,如下:

如上图所示,一个服务失败,导致整条链路的服务都失败的情形,我们称之为服务雪崩.

如何解决:

超时机制
    通过网络请求其他服务时,都必须设置超时,征程情况下,一个远程调用一般在几十毫秒被就返回了, 
    当依赖的服务不可用或者因为网络问题,响应时间将会变的很长,而通常情况下,一次远程调用对应了一个线程,
    如果响应太慢,那么这个线程得不到释放,而线程对应了系统资源,如果大量的线程得不到释放,并且越积越多.
    服务资源就会被耗尽,从而导致资源服务不可用,所以必须为每个请求设置超时时间,如果超时,则释放线程资源.
    
    
    
熔断器模式
    试想一下,家庭如果没有断路器,电流过载了(例如:功率过大,电线短路),电路不断开的话,电路就会升温,甚至是烧断电路,起火.
    有了断路器之后,当电流过载时,会自动切断电路(跳闸).从而保护了整条电路与家庭的安全.当电流过载的问题解决后,只要将
    关闭断路器,电路就又可以工作了.
    
    同样的道理,当依赖的服务有大量超时时,再让新的请求去访问已经没有太大意义,只会无畏的消耗现有的资源.
    譬如我们设置了超时时间为1秒,如果短时间内有大量请求,在1秒内都得不到响应,就往往意味着异常,此时就没有必要让更多
    的请求去访问这个服务了,我们应该使用断路器避免资源浪费.
    
    段利器可以实现快速失败,如果它在一段时间内侦测到许多类似的错误(比如超时),就会强迫其后续的多个调用快速失败,不再
    请求所依赖的服务,从而方式应用程序不断的尝试执行可能失败的操作.这样因应用程序可以继续执行而不用等待修正错误,或
    浪费CPU时间去等待长时间的超时.断路器可以使用因共用程序能够诊断错误是否已修正,如果已经修正,则应用程序会再次尝试
    调用操作.
    
    断路器模式就像是那些容易导致错误的操作的一种代理,这种代理能够记录最近调用发生错误的次数,然后决定适用于需操作继续
    或立即返回错误.
    
    
实现断路器的思路:
    1.监控  监控总共请求多少次,有多少次失败,假设失败率为多少,断路器打开
    2.状态  打开,关闭,断开
    3.分流  
    4.自我修复(状态的切换)