微服务保护机制

熔断降级机制是对系统的防护,比如受到一些恶意攻击,那么需要熔断机制来保护系统的微服务,做出响应,避免资源被耗尽。既要能响应,又要能防护,当我们的请求达到一个负载阈值,就启用熔断,把真实接口关掉,给客户端请求一个响应,这个响应,我们可以设置。服务熔断就是对该服务的调用执行熔断,对应后续请求,不在继续调用该目标服务,而是直接返回,从而可以快速释放资源,或者服务出现故障,会把故障信息返回给客户端。

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)降级是被调用方为防止自身资源不足导致过载的自我保护机制,是从自身整体系统负荷来考虑的,主动提供一种简单的返回值,对调用方更友好。

SpringCloud的实现

SpringCloud结合Hystrix来实现这些保护机制。

Hystrix设计原则

  • 防止单个服务故障耗尽整个服务的Servlet容器(Tomcat/Jetty)的线程资源。
  • 快速失败机制,如果某个服务出现故障,则调用该服务的请求迅速失败,而不是线程等待。
  • 提供回退方案(fallback),在请求发生故障时,提供设定好的回退方案。
  • 使用熔断机制,防止故障扩散到其他服务。
  • 提供熔断器的监控组件Hystrix Dashboard,近实时的监控,报警以及运维操作。

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

1
2
3
circuitBreaker.requestVolumeThreshold    // 单个窗口周期中要使熔断生效的最小请求数,默认20
circuitBreaker.sleepWindowInMilliseconds // 过多长时间,熔断器再次检测是否开启,默认为5000,即5s钟 
circuitBreaker.errorThresholdPercentage  // 错误率,默认50%

3个参数放在一起,所表达的意思就是:单个时间窗口,有超过20个请求的情况下,如果超过50%的请求处理失败,熔断器就会打开。此时再调用此服务,将会直接返回失败,不再调远程服务。直到5s钟之后,重新检测该触发条件,判断是否把熔断器关闭,或者继续打开。

这里面有个很关键点,达到熔断之后,那么后面它就直接不去调该微服务。那么既然不去调该微服务或者调的时候出现异常,出现这种情况首先不可能直接把错误信息传给用户,所以针对熔断我们可以考虑采取降级策略。所谓降级,就是当某个服务熔断之后,服务器将不再被调用,此时客户端可以自己准备一个本地的fallback回调,返回一个缺省值。

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

参考

https://www.cnblogs.com/shijingxiang/articles/12175033.html

(完)