微服务保护技术Sentinel第一节

初识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，还能支持调用关系

流量整形：让波动的请求变成匀速的请求

控制台：有开箱即用的控制台，可以再控制台进行配置和监控