数目|可能会_Sentinel微服务组件Sentinel控制台的规则配置

篇首语：本文由编程笔记#自由互联小编为大家整理，主要介绍了Sentinel微服务组件Sentinel控制台的规则配置相关的知识，希望对你有一定的参考价值。文章目录

篇首语：本文由编程笔记#自由互联小编为大家整理，主要介绍了Sentinel微服务组件Sentinel控制台的规则配置相关的知识，希望对你有一定的参考价值。

文章目录

• 1.Sentinel控制台介绍
• 2.实时监控
• 3.簇点链路
• 4.流控规则
• • 4.1 流量控制
  • 4.2 并发线程数
  • 4.3 流控模式
  • 4.4 流控效果
• 5.降级规则
• • 5.1 熔断策略
  • 5.2 异常比例
  • 5.3 异常数
• 6.热点参数限流
• 7.系统规则
• 8. 授权控制规则
• 9. 集群规则

1.Sentinel控制台介绍

Sentinel 提供一个轻量级的开源控制台它提供机器发现以及健康情况管理、监控单机和集群规则管理和推送的功能。 Sentinel 控制台包含如下功能:

• 查看机器列表以及健康情况收集 Sentinel 客户端发送的心跳包用于判断机器是否在线。
• 监控 (单机和集群聚合)通过 Sentinel 客户端暴露的监控 API定期拉取并且聚合应用监控信息最终可以实现秒级的实时监控。
• 规则管理和推送统一管理推送规则。
• 鉴权生产环境中鉴权非常重要。这里每个开发者需要根据自己的实际情况进行定制。 阿里云提供了 企业级的 Sentinel 控制台应用高可用服务 AHAS

2.实时监控

监控接口的通过的QPS和拒绝的QPS

3.簇点链路

用来显示微服务的所监控的API

4.流控规则

4.1 流量控制

流量控制flow control其原理是监控应用流量的 QPS 或并发线程数等指标当达到指定的阈值时对流量进行控制以避免被瞬时的流量高峰冲垮从而保障应用的高可用性。 FlowRule RT(响应时间) 1/0.2s 5 同一个资源可以创建多条限流规则。FlowSlot会对该资源的所有限流规则依次遍历直到有规则触发限流或者所有规则遍历完毕。一条限流规则主要由下面几个因素组成我们可以组合这些元素来实现不同的限流效果。 参考文档 https://github.com/alibaba/Sentinel/wiki/%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6

限流阈值类型 流量控制主要有两种统计类型一种是统计并发线程数另外一种则是统计 QPS。类型由 FlowRule 的 grade 字段来定义。其中0 代表根据并发数量来限流1 代表根据 QPS 来进行流量控制。

QPSQuery Per Second每秒请求数就是说服务器在一秒的时间内处理了多少个请求。

QPS 进入簇点链路选择具体的访问的API然后点击流控按钮

测试http://localhost:8800/user/findOrderByUserId/1 BlockException异常统一处理

springwebmvc接口资源限流入口在HandlerInterceptor的实现类AbstractSentinelInterceptor的preHandle方法中对异常的处理是BlockExceptionHandler的实现类

sentinel 1.7.1 引入了sentinel-spring-webmvc-adapter.jar

自定义BlockExceptionHandler 的实现类统一处理BlockException

Slf4jComponentpublic class MyBlockExceptionHandler implements BlockExceptionHandler Override public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception log.info("BlockExceptionHandler BlockException"e.getRule()); R r null; if (e instanceof FlowException) r R.error(100,"接口限流了"); else if (e instanceof DegradeException) r R.error(101,"服务降级了"); else if (e instanceof ParamFlowException) r R.error(102,"热点参数限流了"); else if (e instanceof SystemBlockException) r R.error(103,"触发系统保护规则了"); else if (e instanceof AuthorityException) r R.error(104,"授权规则不通过"); //返回json数据 response.setStatus(500); response.setCharacterEncoding("utf-8"); response.setContentType(MediaType.APPLICATION_JSON_VALUE); new ObjectMapper().writeValue(response.getWriter(), r);

测试

4.2 并发线程数

并发数控制用于保护业务线程池不被慢调用耗尽。例如当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加对于调用者来说意味着吞吐量下降和更多的线程数占用极端情况下甚至导致线程池耗尽。为应对太多线程占用的情况业内有使用隔离的方案比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢线程池隔离。这种隔离方案虽然隔离性比较好但是代价就是线程数目太多线程上下文切换的 overhead 比较大特别是对低延时的调用有比较大的影响。Sentinel 并发控制不负责创建和管理线程池而是简单统计当前请求上下文的线程数目正在执行的调用数目如果超出阈值新的请求会被立即拒绝效果类似于信号量隔离。并发数控制通常在调用端进行配置。

可以利用jmeter测试

4.3 流控模式

基于调用关系的流量控制。调用关系包括调用方、被调用方一个方法可能会调用其它方法形成一个调用链路的层次关系。

直接 资源调用达到设置的阈值后直接被流控抛出异常

关联 当两个资源之间具有资源争抢或者依赖关系的时候这两个资源便具有了关联。比如对数据库同一个字段的读操作和写操作存在争抢读的速度过高会影响写得速度写的速度过高会影响读的速度。如果放任读写操作争抢资源则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢举例来说read_db 和 write_db 这两个资源分别代表数据库读写我们可以给 read_db设置限流规则来达到写优先的目的设置strategy 为 RuleConstant.STRATEGY_RELATE 同时设置 refResource为write_db。这样当写库操作过于频繁时读数据的请求会被限流。

链路 根据调用链路入口限流。 NodeSelectorSlot中记录了资源之间的调用链路这些资源通过调用关系相互之间构成一棵调用树。这棵树的根节点是一个名字为 machine-root 的虚拟节点调用链的入口都是这个虚节点的子节点。 一棵典型的调用树如下图所示

machine-root / \\ / \\ Entrance1 Entrance2 / \\ / \\ DefaultNode(nodeA) DefaultNode(nodeA)

上图中来自入口Entrance1和Entrance2 的请求都调用到了资源 NodeASentinel 允许只根据某个入口的统计信息对资源限流。

测试会发现链路规则不生效 注意高版本此功能直接使用不生效如何解决

从1.6.3版本开始Sentinel Web filter默认收敛所有URL的入口context导致链路限流不生效。 从1.7.0版本开始官方在CommonFilter引入了WEB_CONTEXT_UNIFY参数用于控制是否收敛context将其配置为false即可根据不同的URL进行链路限流。

1.8.0 需要引入sentinel-web-servlet依赖

com.alibaba.csp sentinel-web-servlet

添加配置类配置CommonFilter过滤器指定WEB_CONTEXT_UNIFYfalse禁止收敛URL的入口context

Configurationpublic class SentinelConfig Bean public FilterRegistrationBean sentinelFilterRegistration() FilterRegistrationBean registration new FilterRegistrationBean(); registration.setFilter(new CommonFilter()); registration.addUrlPatterns("/*"); // 入口资源关闭聚合 解决流控链路不生效的问题 registration.addInitParameter(CommonFilter.WEB_CONTEXT_UNIFY, "false"); registration.setName("sentinelFilter"); registration.setOrder(1); return registration;

再次测试链路规则链路规则生效但是出现异常

控制台打印FlowException异常

原因分析 1.Sentinel流控规则的处理核心是 FlowSlot, 对getUser资源进行了限流保护当请求QPS超过阈值2的时候就会触发流控规则抛出FlowException异常

2.对getUser资源保护的方式是SentinelResource注解模式会在对应的SentinelResourceAspect切面逻辑中处理BlockException类型的FlowException异常 解决方案 在SentinelResource注解中指定blockHandler处理BlockException

// UserServiceImpl.javaOverrideSentinelResource(value "getUser",blockHandler "handleException")public UserEntity getUser(int id) UserEntity user baseMapper.selectById(id); return user;public UserEntity handleException(int id, BlockException ex) UserEntity userEntity new UserEntity(); userEntity.setUsername("被限流降级啦"); return userEntity;

如果此过程没有处理FlowException, AOP就会对异常进行处理核心代码在CglibAopProxy.CglibMethodInvocation#proceed中抛出UndeclaredThrowableException异常属于RuntimeException

3.异常继续向上抛出引入CommonFilter后CommonFilter添加了对异常的处理机制所以会在CommonFilter中进行处理。 注意此处对BlockException异常的处理是UrlBlaockHandler的实现类而在AbstractSentinelInterceptor拦截器中是使用BlockExceptionHandler的实现类处理

会抛出一个RuntimeException类型的UndeclaredThrowableException异常然后打印到控制台显示

此处又是有坑 FlowException不会被BlockException异常机制处理因为FlowException已经被封装为RuntimeException类型的UndeclaredThrowableException异常

测试 自定义CommonFilter对BlockException异常处理逻辑用于处理经过CommonFilter处理的spring webmvc接口的BlockException

// SentinelConfig.javaBeanpublic FilterRegistrationBean sentinelFilterRegistration() FilterRegistrationBean registration new FilterRegistrationBean(); registration.setFilter(new CommonFilter()); registration.addUrlPatterns("/*"); // 入口资源关闭聚合 解决流控链路不生效的问题 registration.addInitParameter(CommonFilter.WEB_CONTEXT_UNIFY, "false"); registration.setName("sentinelFilter"); registration.setOrder(1); //CommonFilter的BlockException自定义处理逻辑 WebCallbackManager.setUrlBlockHandler(new MyUrlBlockHandler()); return registration;// UrlBlockHandler的实现类Slf4jpublic class MyUrlBlockHandler implements UrlBlockHandler Override public void blocked(HttpServletRequest request, HttpServletResponse response, BlockException e) throws IOException log.info("UrlBlockHandler BlockException"e.getRule()); R r null; if (e instanceof FlowException) r R.error(100,"接口限流了"); else if (e instanceof DegradeException) r R.error(101,"服务降级了"); else if (e instanceof ParamFlowException) r R.error(102,"热点参数限流了"); else if (e instanceof SystemBlockException) r R.error(103,"触发系统保护规则了"); else if (e instanceof AuthorityException) r R.error(104,"授权规则不通过"); //返回json数据 response.setStatus(500); response.setCharacterEncoding("utf-8"); response.setContentType(MediaType.APPLICATION_JSON_VALUE); new ObjectMapper().writeValue(response.getWriter(), r);

测试此场景拦截不到BlockException对应SentinelResource指定的资源必须在SentinelResource注解中指定blockHandler处理BlockException

总结 为了解决链路规则引入ComonFilter的方式除了此处问题还会导致更多的问题不建议使用ComonFilter的方式。 流控链路模式的问题等待官方后续修复或者使用AHAS。

4.4 流控效果

当 QPS 超过某个阈值的时候则采取措施进行流量控制。流量控制的效果包括以下几种快速失败直接拒绝、Warm Up预热、匀速排队排队等待。对应 FlowRule 中的 controlBehavior 字段。

快速失败 RuleConstant.CONTROL_BEHAVIOR_DEFAULT方式是默认的流量控制方式当QPS超过任意规则的阈值后新的请求就会被立即拒绝拒绝方式为抛出FlowException。这种方式适用于对系统处理能力确切已知的情况下比如通过压测确定了系统的准确水位时。

Warm Up Warm UpRuleConstant.CONTROL_BEHAVIOR_WARM_UP方式即预热/冷启动方式。当系统长期处于低水位的情况下当流量突然增加时直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"让通过的流量缓慢增加在一定时间内逐渐增加到阈值上限给冷系统一个预热的时间避免冷系统被压垮。 冷加载因子: codeFactor 默认是3即请求 QPS 从 threshold / 3 开始经预热时长逐渐升至设定的 QPS 阈值。 通常冷启动的过程系统允许通过的 QPS 曲线如下图所示

测试用例

RequestMapping("/test")public String test() try Thread.sleep(100); catch (InterruptedException e) e.printStackTrace(); return "test()";

编辑流控规则

jmeter测试

查看实时监控可以看到通过QPS存在缓慢增加的过程

匀速排队 匀速排队RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER方式会严格控制请求通过的间隔时间也即是让请求以均匀的速度通过对应的是漏桶算法。 该方式的作用如下图所示

这种方式主要用于处理间隔性突发的流量例如消息队列。想象一下这样的场景在某一秒有大量的请求到来而接下来的几秒则处于空闲状态我们希望系统能够在接下来的空闲期间逐渐处理这些请求而不是在第一秒直接拒绝多余的请求。 注意匀速排队模式暂时不支持 QPS > 1000 的场景。

jemeter压测

查看实时监控可以看到通过QPS为5体现了匀速排队效果

5.降级规则

除了流量控制以外对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。我们需要对不稳定的**弱依赖服务调用**进行熔断降级暂时切断不稳定调用避免局部不稳定因素导致整体的雪崩。熔断降级作为保护自身的手段通常在客户端调用端进行配置。

熔断降级规则说明 熔断降级规则DegradeRule包含下面几个重要的属性

5.1 熔断策略

慢调用比例(SLOW_REQUEST_RATIO)选择以慢调用比例作为阈值需要设置允许的慢调用 RT即最大的响应时间请求的响应时间大于该值则统计为慢调用。当单位统计时长statIntervalMs内请求数目大于设置的最小请求数目并且慢调用的比例大于阈值则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态HALF-OPEN 状态若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断若大于设置的慢调用 RT 则会再次被熔断。

测试用例

RequestMapping("/test")public String test() try Thread.sleep(100); catch (InterruptedException e) e.printStackTrace(); return "test()";

jemeter压测/test接口保证每秒请求数超过配置的最小请求数

查看实时监控可以看到断路器熔断效果

此时浏览器访问会出现服务降级结果

5.2 异常比例

异常比例 (ERROR_RATIO)当单位统计时长statIntervalMs内请求数目大于设置的最小请求数目并且异常的比例大于阈值则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态HALF-OPEN 状态若接下来的一个请求成功完成没有错误则结束熔断否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0]代表 0% - 100%。

测试用例

RequestMapping("/test2")public String test2() atomicInteger.getAndIncrement(); if (atomicInteger.get() % 2 0) //模拟异常和异常比率 int i 1/0; return "test2()";

配置降级规则

查看实时监控可以看到断路器熔断效果

5.3 异常数

异常数 (ERROR_COUNT)当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态HALF-OPEN 状态若接下来的一个请求成功完成没有错误则结束熔断否则会再次被熔断。

注意异常降级仅针对业务异常对 Sentinel 限流降级本身的异常BlockException不生效。

配置降级规则

jemeter测试

查看实时监控可以看到断路器熔断效果

6.热点参数限流

何为热点热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据并对其访问进行限制。比如

• 商品 ID 为参数统计一段时间内最常购买的商品 ID 并进行限制
• 用户 ID 为参数针对一段时间内频繁访问的用户 ID 进行限制

热点参数限流会统计传入参数中的热点参数并根据配置的限流阈值与模式对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制仅对包含热点参数的资源调用生效。

注意 热点规则需要使用SentinelResource(“resourceName”)注解否则不生效 参数必须是7种基本数据类型才会生效

测试用例

RequestMapping("/info/id")SentinelResource(value "userinfo", blockHandlerClass CommonBlockHandler.class, blockHandler "handleException2", fallbackClass CommonFallback.class, fallback "fallback" )public R info(PathVariable("id") Integer id) UserEntity user userService.getById(id); return R.ok().put("user", user);

配置热点参数规则 注意 资源名必须是SentinelResource(value“资源名”)中 配置的资源名热点规则依赖于注解

具体到参数值限流配置参数值为3,限流阈值为1

测试 http://localhost:8800/user/info/1 限流的阈值为3 http://localhost:8800/user/info/3 限流的阈值为1

7.系统规则

Sentinel 系统自适应限流从整体维度对应用入口流量进行控制结合应用的 Load、CPU 使用率、总体平均 RT、入口 QPS 和并发线程数等几个维度的监控指标通过自适应的流控策略让系统的入口流量和系统的负载达到一个平衡让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

• Load 自适应仅对 Linux/Unix-like 机器生效系统的 load1 作为启发指标进行自适应系统保护。当系统 load1 超过设定的启发值且系统当前的并发线程数超过估算的系统容量时才会触发系统保护BBR 阶段。系统容量由系统的 maxQps * minRt 估算得出。设定参考值一般是 CPU cores * 2.5。
• CPU usage1.5.0 版本当系统 CPU 使用率超过阈值即触发系统保护取值范围 0.0-1.0比较灵敏。
• 平均 RT当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护单位是毫秒。
• 并发线程数当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
• 入口 QPS当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。

编写系统规则

jemeter配置

测试结果

8. 授权控制规则

很多时候我们需要根据调用来源来判断该次请求是否允许放行这时候可以使用 Sentinel 的来源访问控制黑白名单控制的功能。来源访问控制根据资源的请求来源origin限制资源是否通过若配置白名单则只有请求来源位于白名单内时才可通过若配置黑名单则请求来源位于黑名单时不通过其余的请求通过。

来源访问控制规则AuthorityRule非常简单主要有以下配置项

• resource资源名即限流规则的作用对象。
• limitApp对应的黑名单/白名单不同 origin 用 , 分隔如 appA,appB。
• strategy限制模式AUTHORITY_WHITE 为白名单模式AUTHORITY_BLACK 为黑名单模式默认为白名单模式。

配置授权规则

第一步实现com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.RequestOriginParser接口在parseOrigin方法中区分来源并交给spring管理 注意如果引入CommonFilter此处会多出一个

import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.RequestOriginParser;import org.springframework.stereotype.Component;import javax.servlet.http.HttpServletRequest;/** * author Fox */Componentpublic class MyRequestOriginParser implements RequestOriginParser /** * 通过request获取来源标识交给授权规则进行匹配 * param request * return */ Override public String parseOrigin(HttpServletRequest request) // 标识字段名称可以自定义 String origin request.getParameter("serviceName");// if (StringUtil.isBlank(origin))// throw new IllegalArgumentException("serviceName参数未指定");// return origin;

测试origin是order的请求不通过。

9. 集群规则

为什么要使用集群流控呢假设我们希望给某个用户限制调用某个 API 的总 QPS 为 50但机器数可能很多比如有 100 台。这时候我们很自然地就想到找一个 server 来专门来统计总的调用量其它的实例都与这台 server 通信来判断是否可以调用。这就是最基础的集群流控的方式。 另外集群流控还可以解决流量不均匀导致总体限流效果不佳的问题。假设集群中有 10 台机器我们给每台机器设置单机限流阈值为 10 QPS理想情况下整个集群的限流阈值就为 100 QPS。不过实际情况下流量到每台机器可能会不均匀会导致总量没有到的情况下某些机器就开始限流。因此仅靠单机维度去限制的话会无法精确地限制总体流量。而集群流控可以精确地控制整个集群的调用总量结合单机限流兜底可以更好地发挥流量控制的效果。 https://github.com/alibaba/Sentinel/wiki/%E9%9B%86%E7%BE%A4%E6%B5%81%E6%8E%A7 集群流控中共有两种身份

• Token Client集群流控客户端用于向所属 Token Server 通信请求 token。集群限流服务端会返回给客户端结果决定是否限流。
• Token Server即集群流控服务端处理来自 Token Client 的请求根据配置的集群规则判断是否应该发放 token是否允许通过。

Sentinel 集群流控支持限流规则和热点规则两种规则并支持两种形式的阈值计算方式

• 集群总体模式即限制整个集群内的某个资源的总体 qps 不超过此阈值。
• 单机均摊模式单机均摊模式下配置的阈值等同于单机能够承受的限额token server 会根据连接数来计算总的阈值比如独立模式下有 3 个 client 连接到了 token server然后配的单机均摊阈值为 10则计算出的集群总量就为 30按