《Spring Cloud学习笔记:微服务保护Sentinel》

2023-12-27 06:49:51

流量控制:避免因为突发流量而导致的服务宕机。

隔离和降级:避免微服务出现雪崩

避免非法的请求进入微服务当中

避免因为服务的重启而导致这些规则的丢失

1. 初始Sentinel

1.1 雪崩问题及解决方案

1.1.1 雪崩问题

微服务中,服务间调用关系错综复杂,一个微服务往往依赖于其它多个微服务。

如图,服务消费者调用服务提供者,如果服务提供者发生了故障,由于当前服务消费者应用的部分业务依赖于服务提供者,导致服务消费者的业务请求会被阻塞,因为服务消费者要等待服务提供者结果的返回,请求被阻塞,用户自然不会得到响应,Tomcat的这个线程也不会释放,因为阻塞它就不会释放Tomcat的连接,于是越来越多的用户请求到来,越来越多的线程会被阻塞,由于Tomcat服务器支持的线程和并发数有限,业务请求一直被阻塞,会导致服务器资源耗尽,从而导致其它业务请求请求不进来,导致当前服务也故障不可用了,形成级联失败,雪崩就发生了 => 一个服务故障导致依赖于它的服务最终也出现故障了,导致依赖于它的服务最终被拖垮

微服务之间会相互调用,微服务调用链路中的某个服务故障,引起整个链路中的所有微服务都不可用,也就是引起整个链路中的所有微服务都无法访问的情况,这就是服务雪崩。?

  • 在微服务里面,雪崩问题是一个必须要解决的问题。

解决雪崩问题的常见方式有四种:应对服务雪崩的一种微服务链路保护机制

  • 前面三种是已经有服务故障了,我该怎么样去避免这个故障传递到其它服务而引起雪崩(3解决 + 1预防):?

如何避免因服务故障而引起的雪崩问题??

超时处理:

  • 调用业务时设定超时时间(给业务设定超时时间),如果请求超过一定时间没有响应就释放该请求,直接返回错误信息,而不会让请求无休止等待,这样就不会导致一直占用Tomcat资源,可以在一定程序上缓解雪崩问题{缓解雪崩问题而不是100%解决雪崩问题,因为如果说释放请求的速度没有进入请求的速度快,那么终有一天服务器端的资源还是有可能会被耗尽}

舱壁模式(线程隔离)

  • 限定每个业务能使用的线程数(说白了就是给每个业务都分配一个独立的线程池),这个时候每个业务能够使用的线程资源是有限的(同时也限制了每个业务请求处理的并发量),这样就可以避免耗尽整个Tomcat的资源(因为一个业务一旦出现故障,它最多是把整个线程池内的资源耗尽,而不会导致整个Tomcat的资源被耗尽),因此也叫线程隔离。?
  • 这种模式它确实解决了雪崩问题,但是从资源上来讲会造成一定的浪费,比如服务提供者真的宕机了,但服务消费者每次还来去请求访问它,明明知道它挂了,还要去尝试访问,而且还要占用我一定的线程数,这显然是一种浪费。

?

断路器模式或熔断降级(模式):比较推荐的一种解决方案

  • 断路器统计业务执行的异常比例,如果超出阈值则会熔断该业务会认为该服务由导致雪崩的风险,会拦截访问该业务的一切请求,形成熔断,类似于快速失败机制,资源快速释放,从而避免雪崩问题的发生,该模式不会存在资源浪费的情况,因为如果知道服务出现故障了,就不让请求再去访问该服务了? =>? 类似于电路里面的保险丝儿。? ?
  • 当检测到服务恢复正常响应以后,我们再去放行访问该业务的请求。?
  • 熔断降级模式是解决雪崩问题里面比较好的一种方案。

?

如何避免因瞬间高并发流量而导致的服务故障??

限流 - 流量控制:

  • 限制业务访问的QPS(每秒查询率,每秒的响应请求数,每秒钟处理请求的数量),避免服务因流量的突增而故障,?避免因为突发流量而导致的服务宕机。
  • 使用Sentinel实现限流:Sentinel它可以按照服务所能够承受的一个频率去释放请求,把雪崩问题扼杀在了摇篮当中。总结:流量控制是预防雪崩,避免出现雪崩问题!

思考:那我就只用流量控制不就可以从根源上避免出现雪崩问题了吗?其它三种我不用不就行了。。。?

  • 因为高并发引起的服务故障只是故障的原因之一,往往服务还会因为其它问题而出现故障,比如因为网络问题或者是Full GC引起的假死问题,这些问题都会引起服务故障,这个时候就要用到其它三种解决方案了。?

总结:

  • 限流是对服务的保护,避免因突增的高并发流量而导致服务故障,进而避免雪崩,是一种预防措施。
  • 超时处理、线程隔离(舱壁模式)、熔断降级(断路器模式)是在部分服务故障时,将故障控制在一定范围,避免雪崩,是一种补救措施。?

1.2.服务保护框架或技术对比

在SpringCloud当中支持多种服务保护技术:

Hystrix和Sentinel都是非常成熟可靠的服务保护工具,早期比较流行的是Hystrix框架,但目前国内使用最广泛的还是阿里巴巴的Sentinel服务保护框架(是Spring Cloud Alibaba的组件之一),这里我们做下对比:?

关于Hystrix和Sentinel的对比,在Sentinel的官网上有一篇文章写的很详细:?

sentinel-vs-hystrix | Sentinel?

  • Hystrix是Netflix开源的项目,而Sentinel是阿里巴巴开源的项目;
  • Hystrix主要
  • Sentinel底层是基于信号量来实现资源隔离,而Hystrix支持线程池隔离和信号量隔离,但默认情况下都是使用线程池隔离来实现资源隔离。
  • 线程池隔离:在一个业务请求进入Tomcat以后,它会给每一个被隔离的业务创建一个独立的线程池。
  • 信号量隔离:当业务请求进入Tomcat以后,
  • Hystrix主要通过断路器来实现熔断保护,而Sentinel则提供了更灵活的流量控制、熔断、降级等策略。
  • Hystrix主要提供了服务降级、服务熔断、线程隔离等功能,而Sentinel除了提供上述功能之外,还提供了实时监控、流量控制、热点参数限流、系统负载保护等功能。
  • Hystrix适用于Java语言的微服务架构,而Sentinel则支持多种语言和多种类型的应用架构
  • Hystrix已经停止维护,Spring Cloud在已经发布的项目中已经移除了对Hystrix的支持,而Sentinel在阿里巴巴内部广泛使用,并且有着活跃的社区支持。

? ? ? ???

SentinelHystrix
隔离策略信号量隔离线程池隔离/信号量隔离
熔断降级策略基于慢调用比例或异常比例基于失败比率
实时指标实现滑动窗口滑动窗口(基于 RxJava)
规则配置支持多种数据源支持多种数据源
扩展性多个扩展点插件的形式
基于注解的支持支持支持
限流基于 QPS,支持基于调用关系的限流有限的支持
流量整形支持慢启动、匀速排队模式不支持
系统自适应保护支持不支持
控制台开箱即用,可配置规则、查看秒级监控、机器发现等不完善
常见框架的适配Servlet、Spring Cloud、Dubbo、gRPC 等Servlet、Spring Cloud Netflix

?

文章来源:https://blog.csdn.net/weixin_53622554/article/details/135230832
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。