Sentinel - 服务容错
1. 高并发带来的问题
在微服务架构中,我们将业务拆分成了一个又一个的微服务,应用层面的微服务要调用服务层面的微服务,但是由于网络或者自身的原因,并不能保证100%的调用成功,服务提供者也无法保证服务100%可用。
如果单个服务出现问题,调用这个服务就会出现网络延迟,如果此时处于高并发的场景,也就是说瞬间会涌入大量的连接,最终会导致连接耗尽,服务瘫痪。
1.1 模拟高并发场景
在商品微服务上,睡眠100毫秒,模拟网络拥堵
package com.mszlu.shop.goods.controller;
import com.mszlu.common.Result;
import com.mszlu.shop.goods.service.GoodsService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequestMapping("goods")
public class GoodsController {
@Autowired
private GoodsService goodsService;
@GetMapping("findGoods/{id}")
public Result findGoods(@PathVariable("id") Long id){
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
return goodsService.findGoodsById(id);
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
新写一个简单的商品微服务接口,用户当查询商品服务连接耗尽后,其他接口的访问情况:
修改tomcat的并发数,默认是200 ,将其改小一点:
server:
port: 8002
tomcat:
max-threads: 10
max-connections: 10
2
3
4
5
1.2 Jmeter压测
下载启动
https://jmeter.apache.org/download_jmeter.cgi
下载jmeter,解压进入bin目录,找到jmeter.properties,修改语言:
language=zh_CN
1双击jmeter.bat启动。
添加线程组
配置线程并发数,可以配置为200 效果更明显
添加http取样
配置取样,并启动测试
访问商品微服务的查询商品接口:
启动测试后,调用商品微服务的测试接口
经过测试,我们发现,test接口出现访问问题,不能正常的提供服务,或者响应延迟。
这是因为findGoods接口 囤积了大量的请求,占用了所有的资源,一旦这样的接口多了,就会引起服务器的崩溃。
2. 服务雪崩问题
在分布式系统中,由于网络原因或自身的原因,服务一般无法保证100%可用,如果一旦一个服务出现问题,调用这个服务就会出现线程阻塞的情况,此时若有大量的请求涌入,就会出现多条线程阻塞等待,进而导致服务瘫痪。
由于服务和服务之间的依赖性,故障会传播,会对整个微服务系统造成灾难性的严重后果,这就是服务故障的“雪崩效应”。
雪崩效应发生的原因多种多样,有不合理的容量设计,或者是高并发下某一个方法出现了响应变慢,亦或是某台机器的资源耗尽,我们无法完全杜绝雪崩的源头的发生,只有做好足够的容错,保证在一个服务发生问题,不会影响到其他服务的正常运行。
也就是“雪落而不雪崩”。
其实最好的办法,还是尽量减少服务之间的依赖
3. 常见的容错方案
要防止雪崩的扩散,我们就要做好服务的容错,容错说白了就是保护自己不被猪队友拖垮的一些措施,下面介绍常见的服务容错思路和组件。
3.1常见的容错思路
常见的容错思路有隔离,超时,限流,熔断,降级这几种。
3.1.1 隔离
它是指将系统按照一定的原则划分为若干个服务模块,各个模块之间相互独立,无强依赖。
当有故障发生时,能将问题和影响隔离在某个模块内部,而不扩散风险,不波及其他模块,不影响整体的系统服务。
常见的隔离方式有:线程池隔离和信号量隔离。
线程池隔离中,一旦某个服务挂了,只会影响其中分配的连接,不会影响别的服务的执行,有限的分配连接。
信号量隔离,设置了接收连接的上限,适用于可以快速返回的服务。
3.1.2 超时
在上游服务调用下游服务的时候,设置一个最大响应时间,如果超过这个时间,下游未做反应,就断开请求,释放掉线程。
3.1.3 限流
限流就是限制系统的输入和输出流量,已达到保护系统的目的。为了保证系统的稳固运行,一旦达到需要限制的阈值,就需要限制流量并采取少量限制措施以完成限制流量的目的。
3.1.4 熔断
在互联网系统中,当下游服务因访问压力过大而响应变慢或失败,上游系统为了保护系统整体的可用性,可以暂时切断对下游服务的调用。这种牺牲局部,保全整体的措施就叫做熔断。
服务熔断一般有三种状态:
熔断关闭状态(closed)
服务没有故障时,熔断器所处的状态,对调用方的调用不做任何限制
熔断开启状态
后续对该服务接口的调用不在经过网络,直接执行本地的fallback方法
半熔断状态
尝试恢复服务调用,允许有限的流量调用该服务,并监控调用成功率。如果成功率达到预期,则说明服务已恢复,进入熔断关闭状态;如果成功率依旧很低,则重新进入熔断开启状态。
3.1.5 降级
降级其实就是为服务提供一个拖底方案,一旦服务无法正常调用,就使用托底方案。