微服务保护Sentinel第二节

Sentinel是阿里巴巴开源的一款微服务流量控制组件，官网地址各位自行百度

Sentinel具有如下的特征

1. 丰富的应用场景:Sentinel承接了阿里巴巴十多年的双十一大促流量的核心场景，比如秒杀(就是突发流量控制在系统可以承受的范围以内)，消息削峰填谷，集群流量控制，实时熔断下游不可用的应用等
2. 完备的实时监控：Sentinel同时提供了实时的监控的功能，我们可以再控制台中看到接入应用的单台机器秒级的数据，甚至500台以下规模集群的汇总情况
3. 广泛的额开源生态：Sentinel提供开箱即用的和其他开源框架/库的模块的整合，比如 SpringCloud，Dubbo，GRPC的整合，我们只需要引入相应的依赖并进行简单的配置就可以快速的接入Sentinel
4. 完善的SPI扩展点:Sentinel提供简单易用的  完善的 SPI扩展接口，我们可以通过实现扩展借口来进行快速的定制逻辑，例如定制规则管理，适配动态数据源等

安装Sentinel控制台，方便我们对系统做限流设置，我们可以再GitHub上下载响应的jar包

将jar包拷贝到一个非中文目录，运行一下命令启动这个程序

java -jar sentinel-dashborad-1.8.jar 【我们会发现他就是一个基于springboot的应用】

然后访问: localhost:8080 就可以看到控制台页面，默认的账户名和密码都是sentinel

如果我们要修改Sentinel的默认端口，账户，密码都可以通过下列的配置

 github上对更丰富的配置都有详细的说明

整合微服务和Sentinel

前提，创建一个微服务项目

第一步：

引入Sentinel的依赖

 第二步

配置控制台地址【将来服务要和控制台做交互】

 第三步

访问微服务的任意端点[springmvc的任意一个接口都是一个端点]，触发Sentinel的监控

【注意，启动服务后要访问一下任意一个接口才能触发Sentinel的实时监控】

之前我们提出了微服务保护的四种解决方案【超时处理，线程隔离，熔断降级，流控】，我们Sentinel提供了其中的后三种，接下来将限流中的限流规则

限流规则

1. 快速入门
2. 流控模式
3. 流控效果
4. 热点参数限流

簇点链路：

簇点链路就是项目内部的调用链路，链路中被监控的每个接口就是一个资源，默认情况下Sentinel会监控SpringMvc的每一个端点【Endpoint】，因此Springmvc的每一个端点就是调用链路中的一个资源【如果说你的Service和Mapper也想被监控，将来要用Sentinel提供的一些注解来实现】

 点击流控，可以添加流控规则    针对名称就是url     针对来源default默认所有请求

阈值类型可以选根据每秒访问量限制也可以根据使用的线程数来控制并发量，可以通过压测测试服务器的性能，比如sentinel,后面测试要用到，自己下载一个

 

设置qps为5，好了之后，用jemeter进行测试看会不会限流

流控模式

在添加限流规则的时候，点击高级选项，可以选择三种流控模式

1. 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的设置
2. 关联：统计和当前资源相关的另一个资源，触发阈值时 ，对当前资源进行限流  。【使用场景，比如用户支付时需要修改订单的状态，同时用户需要查询订单慢查询和修改操作都会争抢数据库的所，产生竞争，业务需求是优先支付和更新订单的业务，因此当修改订单业务触发阈值时，对查询订单业务进行限流】当write触发阈值，对read进行限流

        3.链路：统计从指定链路访问到本资源时的请求，触发阈值时，对当前的链路进行限流  。        【只针对从指定链路访问到本资源的请求进行统计，判断是否超过阈值】      。例如有两个 请求链路，    test ->  common       test2->  common,我们只希望从  /test2 进入到  /common的请求，则可以这样配置         

使用的场景：

有查询订单和创建订单，两者都需要查询商品，针对从查询订单进入到查询商品的统计的请求统计进行限流  

Sentinel默认只标记Controller中的方法为资源，如果要标记其他方法，需要利用@SentinelRerource注解，示例：      

Sentinel默认会将Controller方法作为Context整合，导致链路模式的流控失效，需要修改application.yml,添加配置，如果不关闭的话所有的controller都会被认为是同一个根链路发展来的多个子链路，就没办法做指定链路的流控模式了

 

 

流控效果

流控效果是指请求到到流控阈值时应该采用的措施，包括三种

1.快速失败：

达到阈值时，新的请求会被立刻拒绝并抛出FlowException异常，是默认的处理方式

2.warm up:预热模式，

对超出阈值的请求同样是拒绝并抛出异常，但是这种模式阈值会动态的变化，从一个较小的值主键增加的最大阈值

【这是应对服务冷启动的一种方案，请求阈值的初始值是  threshold(最大阈值)/clodFactor(冷启动因子),持续指定时长后，逐渐提高到threshold值，而coldFactor的默认值是3】 

冷启动：服务刚刚启动的时候不能上来把qps打满，只承受到三分之一的的qps，防止刚刚启动时请求过大早成服务器故障

 

例如，我们设置的qps的最大阈值时10，预热时间为5秒。那么初始的阈值就是十分之三，也就是三，然后在5秒后逐渐增长到10

3.排队等待 

让所有的请求按照先后次序排队等待执行，两个请求的间隔不能小于指定的时长

当请求超过qps阈值时，快速失败和预热模式会拒绝新的请求并且抛出异常，而排队等待则是让所有的请求进入到一个队列中，然后按照阈值允许的时间间隔依次执行，后来的请求必须等待前面执行完成，如果请求预期的等待时长超过最大时长就会被拒绝

例如。  qps=5，意味着每200ms处理一个队列中的请求，超时时间为2000毫秒的请求会被抛出异常，这起到的就是一个流量整形的作用，类似于中间件一样的效果