微服务保护

最新推荐文章于 2024-07-20 15:56:05 发布

m0_68418793

最新推荐文章于 2024-07-20 15:56:05 发布

阅读量206

点赞数

文章标签：微服务 java microservices

本文链接：https://blog.csdn.net/m0_68418793/article/details/125176009

版权

Sentinel专门用来解决服务雪崩问题

1. 服务雪崩问题
随着微服务的流行,服务和服务之间的稳定性变得越来越重要，通常一个业务调用需要经过多个后端微服务，假设在整个调用链路上，某个服务不可用的话，则有可能造成整个调用链路上的多个微服务不可用，这种效应称为**服务雪崩（级联故障/失效）**。
2. 雪崩问题发生的原因
1）依赖服务I的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞。
2）服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。
于是依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了

1. 服务雪崩问题的解决方式
1）超时处理 :
设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待
2）仓壁模式 :
船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。
于此类似，我们可以限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。
3）断路器
由*断路器*统计业务执行的异常比例，如果超出阈值则会*熔断*该业务，拦截访问该业务的一切请求
4）限流
限制业务访问的QPS，避免服务因流量的突增而故障
备注 : 从原理上说,其中前三种方式是解决雪崩问题,第四种限流方式是*组止*雪崩的发生
相关概念:
1. QPS: 每秒的请求数
2. RT : 响应时间(response time)

2. 服务保护的技术栈的对比

3. 服务保护---流量控制(限流)
雪崩问题虽然有四种方案，但是限流是避免服务因突发的流量而发生故障，是对微服务雪崩问题的预防。我们这里先介绍这种模式。

4.1 簇点链路
簇点链路是什么:
当请求进入微服务时，首先会访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链就叫做**簇点链路**
簇点链路中被监控的每一个接口就是一个**资源**
举例:
比如我们访问的controller层中的方法接口**/order/{orderId},**这就是一个链路
**注意:**
sentinel默认只对controller层的簇点实施监控,其他层需要手动监控

4.2 流控模式

4.2.1 流控模式的种类(三种)
- 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式
- 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
- 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流
4.2.2 直接-流控模式
在簇点链路中点击**流控**
设置以下信息

阈值类型:
QPS : 每秒请求数量
单机阈值: 每台机器每秒接收请求的数量

4.2.3 关联-流控模式

统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流(拎一个资源达到阈值时,把当前资源限流)

query达到阈值时,对update进行限流
**注意**: 需要对谁限流,就要给谁加流控

4.2.4 链路-流控模式

如果有多个链路需要调用goods链路,那么当goods链路达到阈值时,对调用goods的链路进行限流
**/order/query**和**/order/sava**都调用了**goods**链路,当**goods**链路达到阈值2时,对**/order/query**进行了限流,进而确保了**/order/save**的正常使用

4.3 流控效果
4.3.1 流控效果的种类(三种)

- 快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
- warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。
- 排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长