微服务框架

【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务】

微服务保护

30 初识Sentinel

30.1 雪崩问题及解决方案

30.1.1 雪崩问题

【先来看一个场景】

当前有这么一些个微服务，A、B、C、D，各个服务之间都可能存在有依赖关系，

比如说现在就有服务A 的有一个业务依赖于服务B， 还有个业务依赖于服务D

现在服务D 出现 了故障

现在服务A 中依赖于服务D 的业务就不能正常工作了

等待阻塞越来越多时

会导致服务A的Tomcat 资源耗尽，现在就算请求不是访问服务D 的，也不能正常工作了，

粗略地就可以认为，服务A 也出现故障了

这就形成了 一个服务故障，导致依赖于它的一个服务也跟着故障了的情况

【而且，这只是一个简单的调用关系】

在实际的微服务中，一定会更加 复杂

因为这样的原因，一个拖垮一个，故障的服务越来越多，这就会导致整个微服务群，都不可用了

【雪崩问题】微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。

【解决雪崩问题的常见方式有四种】

① 超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待

超过时间后， 它会立即结束请求，返回给用户信息，而不是 阻塞在那里【这样请求就释放了，不会一直占用Tomcat 的资源】

但是这种方式并不能真正解决问题，只能是说“缓解”，因为这个等待时间总会有可能没有请求的速度快

② 舱壁模式：限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。

船中 这样的设计就能在一定程度上加强船 的“容灾能力”。在程序设计中

将服务A 中的资源划分成一个个独立的线程池，给每个业务分配一个线程池，

这样就可以避免整个Tomcat 的资源耗尽的问题情况

【但是这样也存在着资源浪费的问题，

明明服务C已经挂掉了，但是还是让来的 请求尝试去访问 服务C】

③ 熔断降级：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。

举个栗子

这是最先前的服务阻塞 导致服务Tomcat 资源耗尽的情况

【熔断】

熔断会去统计服务A 中的业务，比如来了几个请求

现在的统计情况就是一共三个请求，故障了俩，故障率63%，如果说阈值是50%，那就超出阈值了

这个时候就会直接熔断

一旦出现熔断，服务A 依赖于服务D 的业务就再也不能执行 了【被拦截】

【快速失败 → 资源快速释放】

④ 流量控制：限制业务访问的QPS【每秒钟处理请求的数量】，避免服务因流量的突增而故障。

【举个栗子】

现在有一个微服务，它能承受最大的QPS = 2( 即每秒钟最多处理两个请求)

为了避免业务请求真的来了很多，引入Sentinel

Sentinel 可以按照这个服务可以承受的频率，去释放请求【预防雪崩，而前面三种是已经出现故障 了，如何避免故障传递】

30.1.2 总结

什么是雪崩问题？

• 微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。

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

• 流量控制

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

• 超时处理
• 线程隔离
• 降级熔断