微服务第九章-微服务保护：初识sentinel、流量控制、隔离和降级、授权规则、规则持久化

初识sentinel

雪崩问题及解决方案

故障了没有处理，引起所有微服务都不可用

 第一种方案：设置超时时间，超时返回错误信息，释放该请求，缓解雪崩问题，只是将请求释放了，假如1秒等待，此时进入的请求是1秒2个，终有一天还是会雪崩的

第二就是仓壁模式，就是在一个服务里对不同的业务挂起线程池的方式，让失败请求隔离在线程池里了，也会有资源浪费，明知道服务C挂了，还要只能用线程池里的10个资源

第三种方式：熔断降级模式，比如就是请求异常 超过了60%达到了2/3这个阈值，那么请求就会被熔断，此时如果还有业务想要访问挂了的服务D，那么熔断就会拦截该请求，快速失败，资源快速释放

以上3种都是解决雪崩的方式

第四种：流量控制，QBS就是每秒处理请求的数量 次数（流量控制也是预防雪崩）

因为流量过高，导致微服务超过了他的本身QBS导致故障，这里就要用到Sentinel了，假如有无数个请求过来了，Sentinel会按照该服务所能承受的频率去释放请求 ，我们的微服务就可以从容的处理请求了，避免故障导致雪崩的问题

注意，高并发引起服务故障只是原因之一，还有网络问题等

服务保护技术对比

Sentinel 是阿里巴巴开源的一个服务保护的组件

线程池隔离：一个业务请求进入tomact以后，Tomact会给每一个被隔离的业务创建一个独立的线程池，每有一个被隔离的业务就会有一个独立的线程池，自然也就会有独立的线程，因此会比tomact直接处理的方式多出很多线程，可能会带来CPU上下文切换的一个消耗，整个服务的性能有一定的损失

信号量隔离：业务请求进入Tomact以后，不会创建独立的线程池，而是做一个统计，统计当前业务已经使用了几个线程，限制线程的数量，比如最多10个线程，也就是说它会限制每个业务能使用线程的数量，只有一个池子Tomact 的，也不会去创建新的线程

熔断降级：不仅有异常比例，还有慢调用比例，比如一个业务10此请求，有8次都特别慢，就认为有问题，就会熔断

流量整形：就是让突发的就是突然就高峰的请求来了，给它慢启动，匀速的排队

Sentinel介绍和安装

Sentinel就是一个jar包

它就是一个机遇springBoot的一个jar包，一个项目啦 

 

只有一个欢迎语句，是因为我们还没有和微服务整合呢

jar包修改端口登数据，只需要命令行在启动的时候添加一个-D就可以修改端口或者用户名密码登了

 微服务整合Sentinel

将来我们的微服务要和控制台做交互，Sentinel要监控嘛，所以必须要配置地址，知道地址

就可以实时监控了 

流量控制

快速入门

项目内的调用链路：比如controller-service-mapper

Endpoint就是Controller里的每个方法，也就是说Sentinel默认监控的是Controller里的方法，如果说service和mapper也想被监控可以用注解的方式

之前访问的order里的方法，它被监控了，那么它就是链路中的一个资源了；而后它调了service，但是service方法并没有被监控，所以service的方法不是一个资源 

springMVC的根，每个Controller方法就是一个子链路了

default是默认一切来源的请求，单机阈值将来就可以设置我们的这个接口美秒最高并发量就可以了

 点击新增流控规则就有了

Mac系统下Jmeter的下载、安装、及环境变量配置_jmeter mac_FamilyYan的博客-CSDN博客

直接打开控制台输入jmeter就可以启动jmeter了

打开老师的jmeter请求

第一个入门，jmeter20个线程2秒发完，美秒10个，此时QPS就是10，而我的上限设置的是10，会触发限流的 

点击右键启动

查看结果树就会发现美妙有5个失败了，被Sentinel阻塞了，flow limiting倍限流了

1秒钟看见通过5个 拒绝5个 

  

流控模式

关联模式如下

点击编辑，就可以打开留空规则

 点击高级选线

默认是直接方式

关联方式：AB两个资源，A触发阈值，对B做限流

链路模式：ABC三个资源 ，AB都访问资源C，在统计资源C的时候，我只统计A过来的请求，B过来的请求不管

 

也就是说两个业务，一个业务优先级高，一个业务优先级低，当优先级高的资源触发阈值时，对优先级低的做限流 

这里有个修改，有个查询，那就是需要给查询添加流控规则 ，因为不能影响修改，给谁限流就给谁加规则

jemeter测试 美秒10个修改 

观察结果树发现update没有被限流，当我们再访问query的时候发现query限流了

以上就是关联模式

链路模式 如下

这个配置的意思是：我在做限流统计时，只统计test2进入common的请求，这就是对请求来源的一种统计 

 查询订单和创建订单他们两个都需要查询订单，查询的业务往往比较高，势必影响创建订单，那么就给查询订单做个限流

也就是说创建的优先级高，查询的优先级低，那么就在queryGoods里给查询做限流；

就是说当两个方法都去调用queryGoods时候，谁的优先级低就对谁限流

注意：queryGoods是service的方法，默认是没有被监控的，不能控制限流规则，可以去配置 

 重启后先执行以下save和query方法，然后发现order/save和order/query变成了两个独立的链路了，

在以前没有false的时候，他们都属于同一个跟链路下的子链路

下边有两个goods，其实是同一个，给哪个添加都行

 随便点一个goods

打开jemeter qps是4

观察结果树发现query请求一直是有两个失败的，而save请求全都是成功的 

save和query都请求goods查询，每秒4个请求，save没有限流，所以都成功了，而query我们做了限流，每秒最多两个请求，如果来了4个请求肯定会有两个失败

去Sentinel也可以发现，一共来了8个请求，6个成功2个失败

流控效果

预热模式：

默认情况下 请求初始阈值=最大阈值（可以理解为最大QPS）/3 ，也就是说初始阈值是最大阈值的1/3

请求一下order/101,然后给它添加一个流控规则

发起请求美秒20个请求，可以发现一开始通过只有3个请求，随着时间的增长，通过的越来越多

 排队等待

 好处：比如说第1秒一个请求没有，第二秒一块来了10个请求 超过了QPS=5的请求，后五个就会进入等待，不会直接返回错误了，让一个巅峰波浪行的QPS变成了平缓执行的QPS了

等待时间是毫秒 

 每秒15个请求

当然了，超过了阻塞的时间5000毫秒的还是会报错的 

达到了流量整形这样一个效果

热点参数限流

参数索引0，就是参数列表中的第一个参数，给1就是参数列表中第二个参数

1秒钟最多5个请求 

 不同的商品热度是不一样，有的商品访问频率就比较高，上边的这种模式是全都是一个频率了，不能一概而论

比方说参数的类型是id 那么就是long类型，也就是id=100的QPS调为10

 也就是说我们的controller里的方法都是无效的，只有通过@SentinelResource("goods")注解配置的才会生效

如下，该资源就同时具备了两个名称，其中一个是order/hot。order/orderId是默认的springMVC资源名称 

 注意这里是配置热点，但是不要点下边这个配置，有问题，点击左侧的热点规则-新增热点规则

 我们这里查询参数索引只有一个那就是id所以就是0，注意我们的参数类型只有这几个，如果我们的类型不是这几个，那就没有办法做热点参数的，id类型就选long

 

 500个请求100秒，QPS就是5了 

 id=101、102、103，发现101只允许两个成功每秒，102是4个，103是都成功了每秒

发现最大的一个QPS是11,2+4+5=11嘛 

 更犀利的限流就可以使用热点参数限流

总结来说：限流可以降幅服务的负载，从而避免服务因为过高并发从而出现故障，限流其实是对服务故障的一种预防措施

隔离和降级

一旦服务发生故障就容易产生雪崩，利用下面的手段去避免级联失败，避免雪崩

FeignClient整合Sentinel

也就是远程调用的时候去保护，feign是做远程调用的 

 只要开启了配置，feign就会变成Sentinel的资源，Sentinel就过去监听它，我们就可以去配置限流、隔离等的规则了，给feign

以前报错是直接抛个异常，不够清晰友好。可以返回一个友好的提示，或者查询失败返回一些默认的结果等，这也就是降级的逻辑了

失败降级业务逻辑：实现接口，并且指定泛型，给哪个feign客户端做降级处理，我们这里目前就一个feign客户端userClient，实现接口的方法，就是在做降级处理 

我们编译好了降级逻辑类，需要注册到spring容器里去，然后还需要再feign上去引用它 

 重启order项目，如下图这个就是feign的链路，就是feign的远程调用路径，所以也就实现了feign和sentinl的整合了，就可以操作限流热点的操作了

 总结

 线程隔离（舱壁模式）

线程隔离的两种方式

线程池方式：请求来了不会使用你本身的线程，而是去池子里新取一个线程然后完成后边的逻辑

信号量：维护一个计数器，每有一个线程，计数器就会-1，如果到0了，那就不允许访问了

主动超时，就是看你时间长了，直接给你干掉，

异步调用：每一次调用都是使用一个独立的线程，不是使用原来的处理tomact请求的线程 

场景：低扇出，就是请求来了，我发出去N个请求，依赖的越多，扇出越高，开启的线程越多，消耗越大

我们的网关就是高扇出的场景

这里指定阈值，其实就是在指定信号量的最大值

给feign的调用做一个线程隔离，选择流控，其实就是配置信号量的最大值

 jemetr并发线程数是10

 那边的限制是2，超出的就会被限制，发现都绿了，那是因为我们当初做了一个降级策略

user对象是null 

这样就实现了信号量的隔离

熔断降级：壮士断腕

如何恢复呢？是有一个状态机（就是断路器）

状态机包含三个状态： 

closed：走，绿色状态，断路器不会拦截任何请求，但是此时断路器会去统计异常比例，如果发现异常比例过高达到了阈值，就会从closed状态切换为open状态

open：红色代表停止，就会拦截一切请求，就是熔断了，但是不能一直熔断，有一个熔断时间，当熔断时间结束，就会从open 状态切换到Half-open

Half-open：半开状态，这个状态会尝试方形一次请求，根据该请求的结果去判断接下来干嘛，如果依然失败，就会再次进去open状态；如果执行成功，就会切换到closed状态了，又会开始做数据统计了

两个关键的东西：熔断的持续时间，失败的阈值

什么情况下需要去熔断呢？达成熔断的条件，在Sentinel里，就叫熔断的策略

熔断策略到底有哪些呢？

 熔断的策略：

慢调用：响应时长ResponseTime简称RT，如下配置，超过500毫秒的都是慢调用，比例阈值，0.5就是一半，如果慢调用超过一半以上就触发阈值，

熔断时长，5秒，超过5秒以后进入Half-open

最小请求数，统计时长，如下配置就是：统计10秒内的，最少10次请求，慢调用超过500毫秒的，比例超过了一半以上，就会触发熔断，熔断时间5秒钟

 

重启user，访问发现响应时间是118毫秒101的userid正好是1,102就不会触发，响应时间20多毫秒

配置降级规则 

 

快速访问5次101后再去访问102，发现102快速返回了结果，null，说明没有查询，直接熔断降级返回null了，所以响应时间不仅没变长，还变短了，过了5秒再次访问，又成功了，就说明熔断又绿了 

异常比例：不是看调用的时间长短，而是看抛出的异常 

异常数：是看固定的异常数值

 

授权规则

授权规则

先到这里吧，以后用到了在学习后边的 

自定义异常结果

规则持久化