初识Sentinel
雪崩问题
在微服务项目中,服务A调用服务BCD,假设服务D出现的故障, 导致服务不返回结果阻塞在服务D,阻塞过多相应的服务A也会慢慢阻塞,没办法释放连接,当服务AD的连接阻塞的过多最终会导致服务BC出现故障(依赖故障服务的服务也会出现故障),当服务群够大,最终会导致所有服务
故障 【微服务调用链中某个服务故障,引起整个链路中的所有微服务都不可用,就是雪崩】
解决雪崩问题的常见方法有四种
1.
超时处理:社会之超时的时间,请求超时超过一定的时间没有响应就返回错误信息,不会无休止等待
问题:【如果响应超时的时间没有请求的速度快,tomcat的资源被耗尽也是时间问题,只能起到缓解作用】
2.
舱壁模式:限定每个业务员能使用的线程数,避免耗尽整个tomcat资源,因此也叫线程隔离
问题:【如果服务C挂了,我们虽然限定了线程数,但是还会去访问服务C,会浪费tomcat的性能】
3.
熔断降级:由断路器统计业务执行的异常比例,如果超出阈值则会熔断该业务,拦截访问该业务的一切请求,如果对服务D进行熔断,要访问D的时候直接返回去,资源快速释放
4.流量控制:限制业务访问的QPS,避免面服务因为流量的突增出现故障【用于防止瞬间高并发导致的服务故障】
有人会问,那直接用流量控制就行了呗?
注意,高并发引起的服务故障只是原因之一,还会因为网络波动或者一些原因引起的服务假死问题
【超时处理,线程隔离,熔断降级是为了避免服务故障雪崩问题】
【流量控制是为了访问瞬间高并发引起的雪崩问题】
解决的工具 Sentinel
微服务保护技术Sentinel和Hystrix对比
线程池隔离:在业务请求进入tomcat中,会给每个被隔离业务创建一个独立的线程池,每个请求都是独立的线程,线程数量成倍增长,那么cpu会因为上下文切换造成消耗
信号量隔离【推荐】:在业务请求进入tomcat,不会创建独立线程池,而是去统计当前业务已经使用几个线程,我们可以限制每个业务可以使用几个线程,如果超过限制的数量会进行阻止,可以减少线程的创建,性能不会下降,但是隔离性不如线程池隔离,我们一般用这个
慢调用:如果一个业务有8个到10个耗时比较久,可能会拖慢我的整个服务
限流:不光基于QPS,还能支持调用关系
流量整形:让波动的请求变成匀速的请求
控制台:有开箱即用的控制台,可以再控制台进行配置和监控