微服务保护Sentinel
雪崩问题
解决雪崩问题的四种常见方式:
- 超时处理:设定超时时间,请求超过一定时间没有响应就返回错误信息,不会无休止等待。如果设置一秒钟没响应返回,即1s释放连接,这1s中有好多个请求进来,来不及释放也会造成资源堵塞
- 舱壁模式:限定每个业务能使用的线程数,避免耗尽整个tomcat的资源,也叫线程隔离。还是有问题,如果服务挂了,下游服务还是会不停的请求,虽然有线程数控制,但是还是会有请求进来,即使明知道服务挂了,会造成分配给这个服务的资源浪费
- 熔断降级:由断路器统计业务执行的异常比例,如果超出阈值则会熔断该业务,拦截访问业务的一切请求。没啥问题,现在主流都是用这个
- 流量控制:限制业务访问的QPS,预防服务因流量的突增而故障。
服务技术对比
搭建sentinel
- 引入依赖,下游服务引,比如orderservice调用userservice方法,在orderservice中引入
<!-- 引入sentinel依赖-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
- 配置yaml
spring:
cloud:
sentinel:
transport:
dashboard: 127.0.0.1:8080
流控规则
簇点链路
簇点链路:就是项目内的调用链路,链路中被监控的每个接口就是一个资源。
默认情况下sentinel会监控SpringMVC的每一个端点 (Endpoint),因此SpringMVC的每一个端点 (Endpoint)就是调用链路中的一个资源。
流控、熔断等都是针对簇点链路中的资源来设置的,因此我们可以点击对应资源后面的按钮来设置规则:流控 / 降级 / 热点 / 授权
- 单机阈值:QPS不能超过5,每秒钟只允许5次请求,超出的请求会被拦截并报错
高级选项
在添加限流规则时,点击高级选项,可以选择三种流控模式:
- 直接:统计当前资源的请求,触发闻值时对当前资源直接限流,也是默认的模式
- 关联:统计与当前资源相关的另一个资源,触发闻值时,对当前资源限流
- 链路:统计从指定链路访问到本资源的请求,触发闯值时,对指定链路限流
流控模式
流控模式-限流
关联模式:统计与当前资源相关的另一个资源,触发闻值时,对当前资源限流
使用场景:比如用户支付时需要修改订单状态,同时用户要查询订单。查询和修改操作会争抢数据库锁,产生竞争业务需求是有限支付和更新订单的业务,因此当修改订单业务触发闻值时,需要对查询订单业务限流
限制/order/query资源,
总结:
满足下面条件可以使用关联模式:
- 两个有竞争关系的资源
- 一个优先级较高,一个优先级较低
流控模式-链路
链路模式:只针对从指定链路访问到本资源的请求做统计,判断是否超过阈值
假设现在有两条链路:
- /order/save–>/query
- /order/query–>/query
对query资源做链路限制,限制/order/query这个资源入口的qps
spring:
cloud:
sentinel:
transport:
dashboard: 127.0.0.1:8080
web-context-unify: false # sentinel默认会将controller方法做context整合,导致链路模式的流控失败,现在要把service里的方法也要监控到
#链路模式中,是对不同来源的两个链路做监控,但是sentinel默认会给进入springmvc的所有请求设置同一个root资源,会导致链路失败
@SentinelResource("query")//将该资源交给sentinel监控
public String query() {
return "查询成功";
}
流控效果
流控效果-warm up
warm up也叫预热模式,是应对服务冷启动的一种方案。请求闻值初始值是threshold/coldFactor,持续指定时长后,逐渐提高到threshold值。而coldFactor的默认值是3.
例如,我设置QPS的threshold为10,预热时间为5秒,那么初始闻值就是 10/3,也就是3,然后在5秒后逐渐增长到10.
流控效果-排队等待
当请求超过QPS闻值时,快速失败和warm up 会拒绝新的请求并抛出异常。而排队等待则是让所有请求进入一个队列中然后按照闻值允许的时间间隔依次执行。后来的请求必须等待前面执行完成,如果请求预期的等待时间超出最大时长则会被拒绝。
虽然不能确定进来的流量是怎么样的,但是可以保证出去的流量是200ms一个出去,起到流量整形的作用
热点参数限流
热点参数限流分别统计参数值相同的请求,是否超过QPS阈值
下面这个代表对hot
这个资源的0号参数做统计,每秒的QPS不饿能超过2,但是102/103是可以超过2的,只是不能超过10/4
需要注意的是:热点参数限流对默认的Springmvc资源无效,需要加之前用过的注解@SentinelResouce
@SentinelResource("hot")
@GetMapping("{orderId}")
public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
// 根据id查询订单并返回
return orderService.queryOrderById(orderId);
}
隔离和降级
虽然限流可以尽量避免因高并发而引起的服务故障,但服务还会因为其它原因而故障。而要将这些故障控制在一定范围避免雪崩,就要靠线程隔离(舱壁模式)和熔断降级手段了。
不管隔离还是熔断,都是对客户端(调用者)的保护(下游服务)。
Feign整合Sentinel
- 引入依赖
<!-- 引入sentinel依赖-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
- 配置yaml
spring:
sentinel:
enabled: true #开启feign对sentinel的支持
-
在feign中:
-
第一步:在feign-api项目中的UserClientFallbackFactory编写降级规则,需要继承FallbackFactory
-
@Slf4j public class UserClientFallbackFactory implements FallbackFactory<UserClient> { @Override public UserClient create(Throwable throwable) { return new UserClient() { @Override public User findById(Long id) { log.error("查询用户异常" + throwable); return new User(); } }; } }
-
-
第二步:将这个UserClientFallbackFactory注册成bean
-
public class FeignClientConfiguration { @Bean public Logger.Level feignLogLevel(){ return Logger.Level.BASIC; } @Bean public UserClientFallbackFactory userClientFallbackFactory(){ return new UserClientFallbackFactory(); } }
-
-
第三步:在调用接口的头上补充注解
-
@FeignClient(value = "userservice",fallbackFactory = UserClientFallbackFactory.class) public interface UserClient { @GetMapping("/user/{id}") User findById(@PathVariable("id")Long id); }
-
-
线程隔离
熔断降级
熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例,如果超出闻值则会熔断该服务。即拦截访问该服务的一切请求,而当服务恢复时,断路器会放行访问该服务的请求。
断路器的状态
断路器熔断策略有三种:慢调用、异常比例、异常数
- 慢调用:业务的响应时长(RT)大于指定时长的请求认定为慢调用请求。在指定时间内,如果请求数量超过设定的最小数量,慢调用比例大于设定的闯值,则触发熔断。
- 异常比例或异常数:统计指定时间内的调用,如果调用次数超过指定请求数,并且出现异常的比例达到设定的比例闻值(或超过指定异常数),则触发熔断。
慢调用
对这个/user/id资源进行降级,规定RT响应时间超过50ms的调用是慢调用,在1000ms中,如果请求>5,且慢调用比例大于0.4,则会触发熔断,熔断时间是1s。然后进入half-open状态,放行一次请求做测试。
异常比例
对这个/user/id资源进行降级,在1000ms中,如果请求数>5,且失败比例达到0.4,则触发熔断,熔断时间是1s。然后进入half-open状态,放行一次请求做测试。
授权规则
授权规则是对请求来源的判断,比如网关,浏览器,有些请求是浏览器通过网关转发到具体服务的,有些是越过网关直接到服务的。
gateway:
default-filters:
- AddRequestHeader=origin,gateway
在网关中配置:添加请求头信息:origin=gateway
在具体服务中实现接口,判断该请求有没有携带origin
@Component
public class HeaderOriginParser implements RequestOriginParser {
@Override
public String parseOrigin(HttpServletRequest httpServletRequest) {
String origin = httpServletRequest.getHeader("origin");
if (StringUtils.isEmpty(origin)){
origin="blank";
}
return origin;
}
}
自定义异常
默认情况下,发生限流、降级、授权拦截时,都会抛出异常到调用方。如果要自定义异常时的返回结果,需要实现BlockExceptionHandler
接口。
@Component
public class MyBlockException implements BlockExceptionHandler {
/**
* 处理请求被限流,降级,授权拦截时抛出的异常:BlockException
* @param httpServletRequest
* @param httpServletResponse
* @param e
* @throws Exception
*/
@Override
public void handle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, BlockException e) throws Exception {
String msg = "未知错误";
int status = 429;
if (e instanceof FlowException){
msg = "请求被限流了";
}else if (e instanceof DegradeException){
msg="请求被降级了";
} else if (e instanceof ParamFlowException) {
msg="热点参数限流";
} else if (e instanceof AuthorityException) {
msg="请求没有权限";
status = 401;
}
httpServletResponse.setStatus(status);
httpServletResponse.setContentType("application/json;charset=utf-8");
httpServletResponse.getWriter().println("message:"+ msg + ",status:"+ status);
}
}
获取请求来源的接口是什么?
- RequestOriginParser
处理BlockException的接口是什么?
- BlockExceptionHandler
规则持久化
sentinel的控制台规则管理有三种:
- 原始模式:sentinel的默认模式,将规则保存在内存中,重启服务会丢失
- pull模式:保存在本地文件或数据库,定时读取
- push模式:保存在nacos,监听变更实时更新