微服务组件(高并发带来的问题服务器雪崩效应Sentinel入门)

在微服务架构中&＃xff0c;我们将业务拆分成一个个的服务&＃xff0c;服务与服务之间可以相互调用&＃xff0c;但是由于网络原因或者自身的原因&＃xff0c;服务并不能保证服务的100%可用&＃xff0c;如果单个服务出现问题&＃xff0c;调用这个服务就会出现网络延迟&＃xff0c;此时若有大量的网络涌入&＃xff0c;会形成任务堆积&＃xff0c;最终导致服务瘫痪。

模拟高并发

1.创建SentinelController

&＃64;RestController
public class SentinelController {
&＃64;RequestMapping("/sentinel1")
public String sentinel1() throws InterruptedException {
TimeUnit.SECONDS.sleep(1);
return "sentinel1";
}
&＃64;RequestMapping("/sentinel2")
public String sentinel2() throws InterruptedException {
return "sentinel2";
}
}


2.修改配置文件中tomcat的并发数

tomcat:
threads:
max: 10 #tomcat的最大并发值修改为10


在分布式系统中,由于网络原因或自身的原因,服务一般无法保证100%可用。如果一个服务出现了问题&＃xff0c;调用这个服务就会出现线程阻塞的情况&＃xff0c;此时若有大量的请求涌入&＃xff0c;就会出现多条线程阻塞等待&＃xff0c;进而导致服务瘫痪。
由于服务与服务之间的依赖性&＃xff0c;故障会传播&＃xff0c;会对整个微服务系统造成灾难性的严重后果&＃xff0c;这就是服务故障的“雪崩效应”。
服务器的雪崩效应其实就是某个微小的服务器挂了&＃xff0c;导致整一大片的服务器都不可用&＃xff0c;类似生活中的雪崩效应&＃xff0c;由于落下的最后一片雪花引发了雪崩的情况。
雪崩发生的原因多种多样&＃xff0c;有不合理的容量设计&＃xff0c;或者是高并发下某一个方法响应变慢&＃xff0c;亦或是某台机器的资源耗尽。我们无法完全杜绝雪崩源头的发生&＃xff0c;只能做好足够 的容错&＃xff0c;保证在一个服务器发生问题&＃xff0c;不会影响到其它服务的正常运行。

常见容错方案

1.隔离机制:比如服务A内总共有100个线程,现在服务A可能会调用服务B,服务C,服务D.我们在服务A进行远程调用的时候,给不同的服务分配固定的线程,不会把所有线程都分配给某个微服务.比如调用服务B分配30个线程,调用服务C分配30个线程&＃xff0c;调用服务D分配40个线程.这样进行资源的隔离&＃xff0c;保证即使下游某个服务挂了&＃xff0c;也不至于把服务A的线程消耗完。比如服务B挂了&＃xff0c;这时候最多只会占用服务A的30个线程,服务A还有70个线程可以调用服务C和服务D。

2.超时机制:在上游服务调用下游服务的时候&＃xff0c;设置一个最大响应时间&＃xff0c;如果超过这个时间&＃xff0c;下游未作出反应&＃xff0c;就断开请求&＃xff0c;释放掉线程。

3.限流机制:限流就是限制系统的输入和输出流量已达到保护系统的目的。为了保证系统的稳固运行,一旦达到的需要限制的阈值,就需要限制流量并采取少量措施以完成限制流量的目的。

4.熔断机制:在互联网系统中&＃xff0c;当下游服务因访问压力过大而响应变慢或失败&＃xff0c;上游服务为了保护系统整体的可用性&＃xff0c;可以暂时切断对下游服务的调用。这种牺牲局部&＃xff0c;保全整体的措施就叫做熔断。
服务熔断一般有三种状态:
。熔断关闭状态(Closed)
服务没有故障时&＃xff0c;熔断器所处的状态&＃xff0c;对调用方的调用不做任何限制
。熔断开启状态(Open)
后续对该服务接口的调用不再经过网络&＃xff0c;直接执行本地的fallback方法4.
。半熔断状态(Half-Open)
尝试恢复服务调用&＃xff0c;允许有限的流量调用该服务&＃xff0c;并监控调用成功率。如果成功率达到预期&＃xff0c;则说明服务已恢复&＃xff0c;进入熔断关闭状态;如果成功率仍旧很低&＃xff0c;则重新进入熔断关闭状态。

5.降级机制:降级其实就是为服务提供一个兜底的方案了&＃xff0c;一旦服务无法正常调用&＃xff0c;就使用兜底方案

注意&＃xff1a;在调用第三方接口的时候不能同步调用&＃xff0c;要么通过异步线程池&＃xff0c;要么通过mq消息中间件的方式

什么是Sentinel?

Sentinel (分布式系统的流量防卫兵)是阿里开源的一套用于服务容错的综合性解决方案。它以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度来保护服务的稳定性

Sentinel管控台:针对服务进行规则的配置
Sentinel核心库:做具体的信息拦截和请求发送

订单服务集成Sentinel

第一步&＃xff1a;导入依赖


<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-starter-alibaba-sentinelartifactId>


第二步&＃xff1a;增加配置文件

spring:
cloud:
sentinel:
transport:
port: 9999 #跟控制台交流的端口&＃xff0c;随意指定一个未使用的端口即可
dashboard: localhost:8080 #指定控制台服务的地址


第三步&＃xff1a;安装sentinel控制台

下载jar包

启动控制台
java -Dserver.port&＃61;8080 -Dcsp.sentinel.dashboard.server&＃61;localhost:8080 -Dproject.name&＃61;sentinel-dashboard -jar sentinel-dashboard.jar

成功标志

进入到控制台面板&＃xff0c;登录账号和密码默认都是sentinel

流控规则

流量控制&＃xff0c;其原理是监控应用流量的QPs(每秒查询率)或并发线程数等指标&＃xff0c;当达到指定的阈值时对流量进行控制

资源名:唯一名称&＃xff0c;默认是请求路径&＃xff0c;可自定义
针对来源:指定对哪个微服务进行限流&＃xff0c;默认指default&＃xff0c;意思是不区分来源&＃xff0c;全部限制阈值类型/单机阈值:
.QPS(每秒请求数量):当调用该接口的QPs达到阈值的时候&＃xff0c;进行限流
·线程数:当调用该接口的线程数达到阈值的时候&＃xff0c;进行限流
是否集群:暂不需要集群

预热流控

前期初始化需要消耗大量资源&＃xff0c;所以需要将流量控制的少一点

等待流控

如果一个请求等待的时间超过规定时间&＃xff0c;就会被流控

关联流控

当某一核心资源的重要请求到达他的阈值&＃xff0c;为了保证它能够正常运转&＃xff0c;对别的不重要的请求进行限流

链路流控

不添加该属性的话&＃xff0c;默认会将tranceService折叠掉

公共部分&＃xff1a;

public class SentinelServiceImpl {
&＃64;SentinelResource(value &＃61; "tranceService")
public String resourceMethod(){
//做业务
return "业务资源";
}
}


Controller接口&＃xff1a;

&＃64;RestController
public class TraceController {
&＃64;Autowired
private SentinelServiceImpl sentinelService;
&＃64;RequestMapping("/trace1")
public String trace1(){
sentinelService.resourceMethod();
return "trace1";
}
&＃64;RequestMapping("/trace2")
public String trace2(){
sentinelService.resourceMethod();
return "trace2";
}
}


控制台:

降级(提供一个兜底方案)

慢调用比例

最大RT&＃61;1000
请求处理时间大于1000毫秒,属于一个慢请求
比例阈值 &＃61; 0.1
熔断时长 &＃61; 10
最小请求数 &＃61; 5
当—段时间,请求中慢比例的数值大于10%,自动触发熔断机制,拒绝请求进入,拒绝10秒.

异常比例

比例阈值 0.3&＃xff0c;如果错误的请求数/总请求数>0.3&＃xff0c;达到了进行熔断的条件
请求1 正常
请求2 正常
请求3 错误
请求4 正常

异常数案例