高并发带来的问题 服务器雪崩效应 Sentinel入门
高并发带来的问题
在微服务架构中,我们将业务拆分成一个个的服务,服务与服务之间可以相互调用,但是由于网络原因或者自身的原因,服务并不能保证服务的100%可用,如果单个服务出现问题,调用这个服务就会出现网络延迟,此时若有大量的网络涌入,会形成任务堆积,最终导致服务瘫痪。
模拟高并发
1.创建SentinelController
@RestController
public class SentinelController {
@RequestMapping("/sentinel1")
public String sentinel1() throws InterruptedException {
TimeUnit.SECONDS.sleep(1);
return "sentinel1";
}
@RequestMapping("/sentinel2")
public String sentinel2() throws InterruptedException {
return "sentinel2";
}
}
2.修改配置文件中tomcat的并发数
tomcat:
threads:
max: 10 #tomcat的最大并发值修改为10
服务器雪崩效应
在分布式系统中,由于网络原因或自身的原因,服务一般无法保证100%可用。如果一个服务出现了问题,调用这个服务就会出现线程阻塞的情况,此时若有大量的请求涌入,就会出现多条线程阻塞等待,进而导致服务瘫痪。
由于服务与服务之间的依赖性,故障会传播,会对整个微服务系统造成灾难性的严重后果,这就是服务故障的“雪崩效应”。
服务器的雪崩效应其实就是某个微小的服务器挂了,导致整一大片的服务器都不可用,类似生活中的雪崩效应,由于落下的最后一片雪花引发了雪崩的情况。
雪崩发生的原因多种多样,有不合理的容量设计,或者是高并发下某一个方法响应变慢,亦或是某台机器的资源耗尽。我们无法完全杜绝雪崩源头的发生,只能做好足够 的容错,保证在一个服务器发生问题,不会影响到其它服务的正常运行。
常见容错方案
1.隔离机制:比如服务A内总共有100个线程,现在服务A可能会调用服务B,服务C,服务D.我们在服务A进行远程调用的时候,给不同的服务分配固定的线程,不会把所有线程都分配给某个微服务.比如调用服务B分配30个线程,调用服务C分配30个线程,调用服务D分配40个线程.这样进行资源的隔离,保证即使下游某个服务挂了,也不至于把服务A的线程消耗完。比如服务B挂了,这时候最多只会占用服务A的30个线程,服务A还有70个线程可以调用服务C和服务D。
2.超时机制:在上游服务调用下游服务的时候,设置一个最大响应时间,如果超过这个时间,下游未作出反应,就断开请求,释放掉线程。
3.限流机制:限流就是限制系统的输入和输出流量已达到保护系统的目的。为了保证系统的稳固运行,一旦达到的需要限制的阈值,就需要限制流量并采取少量措施以完成限制流量的目的。
4.熔断机制:在互联网系统中,当下游服务因访问压力过大而响应变慢或失败,上游服务为了保护系统整体的可用性,可以暂时切断对下游服务的调用。这种牺牲局部,保全整体的措施就叫做熔断。
服务熔断一般有三种状态:
。熔断关闭状态(Closed)
服务没有故障时,熔断器所处的状态,对调用方的调用不做任何限制
。熔断开启状态(Open)
后续对该服务接口的调用不再经过网络,直接执行本地的fallback方法4.
。半熔断状态(Half-Open)
尝试恢复服务调用,允许有限的流量调用该服务,并监控调用成功率。如果成功率达到预期,则说明服务已恢复,进入熔断关闭状态;如果成功率仍旧很低,则重新进入熔断关闭状态。
5.降级机制:降级其实就是为服务提供一个兜底的方案了,一旦服务无法正常调用,就使用兜底方案
注意:在调用第三方接口的时候不能同步调用,要么通过异步线程池,要么通过mq消息中间件的方式
Sentinel入门(常见的容错组件)
什么是Sentinel?
Sentinel (分布式系统的流量防卫兵)是阿里开源的一套用于服务容错的综合性解决方案。它以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度来保护服务的稳定性
Sentinel管控台:针对服务进行规则的配置
Sentinel核心库:做具体的信息拦截和请求发送
订单服务集成Sentinel
第一步:导入依赖
<!--sentinel组件-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency
第二步:增加配置文件
spring:
cloud:
sentinel:
transport:
port: 9999 #跟控制台交流的端口,随意指定一个未使用的端口即可
dashboard: localhost:8080 #指定控制台服务的地址
第三步:安装sentinel控制台
下载jar包
启动控制台
java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar
成功标志
进入到控制台面板,登录账号和密码默认都是sentinel
流控规则
流量控制,其原理是监控应用流量的QPs(每秒查询率)或并发线程数等指标,当达到指定的阈值时对流量进行控制
资源名:唯一名称,默认是请求路径,可自定义
针对来源:指定对哪个微服务进行限流,默认指default,意思是不区分来源,全部限制阈值类型/单机阈值:
.QPS(每秒请求数量):当调用该接口的QPs达到阈值的时候,进行限流
·线程数:当调用该接口的线程数达到阈值的时候,进行限流
是否集群:暂不需要集群
预热流控
前期初始化需要消耗大量资源,所以需要将流量控制的少一点
等待流控
如果一个请求等待的时间超过规定时间,就会被流控
关联流控
当某一核心资源的重要请求到达他的阈值,为了保证它能够正常运转,对别的不重要的请求进行限流
链路流控
不添加该属性的话,默认会将tranceService折叠掉
公共部分:
public class SentinelServiceImpl {
@SentinelResource(value = "tranceService")
public String resourceMethod(){
//做业务
return "业务资源";
}
}
Controller接口:
@RestController
public class TraceController {
@Autowired
private SentinelServiceImpl sentinelService;
@RequestMapping("/trace1")
public String trace1(){
sentinelService.resourceMethod();
return "trace1";
}
@RequestMapping("/trace2")
public String trace2(){
sentinelService.resourceMethod();
return "trace2";
}
}
控制台:
降级(提供一个兜底方案)
慢调用比例
最大RT=1000
请求处理时间大于1000毫秒,属于一个慢请求
比例阈值 = 0.1
熔断时长 = 10
最小请求数 = 5
当—段时间,请求中慢比例的数值大于10%,自动触发熔断机制,拒绝请求进入,拒绝10秒.
异常比例
比例阈值 0.3,如果错误的请求数/总请求数>0.3,达到了进行熔断的条件
请求1 正常
请求2 正常
请求3 错误
请求4 正常