目录
微服务中的雪崩现象
解决：
超时处理
舱壁模式
熔断降级
流量控制
Sentinel
操作
限流规则
案例：流量监控
高级选项：
流控模式：
关联模式场景：
链路模式
总结
流控效果
预热模式：
排队等待
编辑
总结
热点参数限流
案例：给order/{id}进行热点参数限流
微服务中的雪崩现象
首先，我们介绍一下微服务中雪崩现象：因为微服务中服务是互相调用的，错综复杂，当一个服务D出现问题时，那么调用D的服务请求就会失败，当请求累积到一定的量时，请求D的服务也会出问题——>(因为我们内置的tomcat连接数是有限制的，如果一直请求那个失败的服务，当请求达到一定的数量)，服务A也会炸掉，从而引起整个链路服务不可用；
解决：
超时处理
我们可以设置超时时间，超过了就会返回错误信息，释放tomcat资源
劣势：起到了缓解雪崩问题，当服务请求的时间比超时时间短，假设1s内多个请求，而你超时时间是1s，那么还是会出现雪崩
舱壁模式
将每个业务隔离开（有一个线程池），限定每个业务能够使用的线程数，就算这个服务挂了，也就损失这一部分的线程，从而避免了损失整个tomcat资源——>也就是线程隔离
熔断降级
根据异常请求的比例，比如说你异常请求达到了1/2，超过了这个阈值就会熔断该业务，拒绝一切请求访问该业务
流量控制
首先我们了解一下QPS——>每秒能够处理的请求数；流量控制——>限制服务访问的QPS，避免服务因为流量突然增大而挂掉；
它是一种预防的功能，给大量请求进行限流，以一定数量请求进行访问
Sentinel
首先我们来说一下信号量隔离和线程池隔离之间的区别：
信号量隔离：用的还是tomcat池子，只是我们每一个业务都被限定了能够用多少个线程去访问，当请求数超过这个限定的数量时，就会拒绝访问了——>也就是说它会限制每个业务能使用的线程数量
好处：不用创建线程池，节省资源；
坏处：隔离性较差，相当于吃大锅饭，每个规定了盛多少饭；
线程池隔离：就跟我们上面的舱壁模式一样，每个业务分配一个线程池，线程池里面限定了一定的线程数，起到了隔离作用，当服务挂了也就浪费这个池子
好处：隔离性好;
坏处：浪费了资源；
控制台：
Sentinel支持开箱即用，那些第三方配置都可以直接用，比如：查看监控，配置规则等等
熔断降级策略:
除了根据失败的请求比例来判断是否熔断，是否拒绝其他的请求请求该业务之外；还可以根据请求服务的时间来进行熔断降级——>因为请求服务时间可能太长了，拖垮我们的服务，我们进行熔断；
限流：
可以让突发的流量平稳运行——>进行一种流量控制，支持慢启动和匀速排队模式
操作
java -jar sentinel-dashboard-1.8.x.jar //启动sentinel
修改配置（启动有效）：
java -jar sentinel-dashboard-1.8.x.jar -Dserver.port=8090//修改端口配置
然后我们后台启动服务，Sentinel进行监控
cloud:
nacos:
discovery:
server-addr: localhost:8848 # nacos服务地址
cluster-name: Hangzhou # 实例集群
ephemeral: false # 非临时实例
sentinel:
transport:
dashboard: localhost:8080 #sentinel控制台版本
org.springframework.cloud
spring-cloud-starter-alibaba-sentinel
0.9.0.RELEASE
限流规则
点击服务资源查看流量监控，就可以弹出表单，添加流控规则
这个单机阈值就是每秒能够请求的次数，资源名就是请求的资源
当超过单机阈值，就会报错；
案例：流量监控
我们这个Sentinel_spring_web_context是一个根节点，底下这个/order/{orderid}是它的一个节点，然后像咱这个订单还调用了用户服务，所以下面可能还有子节点
点击流控设置流量控制
针对来源：意思就是从哪里来的，限流
QPS：每秒请求数量
我们要模拟1s超过5次请求，可以利用jmeter
发现限流成功
可以修改响应风格，看到响应失败
高级选项：
流控模式：
流控模式强调的是对哪个资源进行限流
关联模式场景：
比如某个用户支付时候，需要修改订单状态，那么用户需要查询订单，查询和修改订单的操作会争抢数据库锁——>从而产生竞争；
业务需求是：有限支付和更新订单的业务，以此当修改订单业务触发阈值时，我们这里需要对查询订单业务限流；
当/write资源访问（修改订单）量触发阈值时，就会对/read资源限流，从而避免影响/write资源
那么我们的阈值就是对限流的资源（被关联的）使用；
当你访问query时发现被限流——>访问update次数过多，又因为update与query关联
总结：
链路模式
Sentinel默认只会标记Controller中的方法，如果要标记其他的需要@SentinelResource注解
如果不关闭context，会认为所有的controller是同一个根目录发展而来的子链路
sentinel:
transport:
dashboard: localhost:8080 #sentinel控制台版本
web-context-unify: false #关闭context
会发现save和query成两个独立链路
然后我们对query下调用的good进行流控,选择高级选项链路模式（统计哪个链路进来的进行限流）——>从/order/query进来的
我们发送200个请求在50s内，对两个请求（query和save）发送
会发现good关联的query链路被限流
save是成功的
查看监控
总结
链路：是对资源的来源进行一个限流
关联：强调的是一个优先级，比如修改调用查询，触发阈值对查询限流
流控效果
流控效果强调的是对请求的处理，效果
预热模式：
意思就是服务器一开始不会应对那么多的请求QPS，如果一下应对那么多，可能一上来就给打懵了，会有个预热——>防止一下高并发导致服务器宕机
如果设置QPS每秒最大请求为10，那么它会预热，从10/3开始慢慢到10（时间为你的预热时长）
我们进行测试，每秒请求10个，会发现：能够成功的请求越来越多
排队等待
好处：
能够让流量平稳的运行，平稳的处理
案例：给order/{id}限流，最大QPS为10，每s处理10个请求，利用排队的流量监控，超时时间设置为5s——>超过5s的请求直接拒绝
请求进入队列，按照阈值运行的时间间隔依次执行请求；如果请求预期等待时间>超时间就会拒绝，然后处理的请求资源放出来平稳
总结
各有各的好处：一个直接让你失败不让你久等，对用户体验比较好；warm up防止高并发导致的服务器宕机，相对更加安全；而排队等待的话能够使流量平稳运行，只有超过整个队列时长才会拒绝，更加综合一点；
热点参数限流
之前的的限流是统计访问某个资源的所有请求，判断是否超过QPS阈值，而判断是否拒绝；
而热点参数限流——>是根据参数值是否相同来判断拒绝
参数索引是第x个参数，判断含有这个参数的请求数是否超过QPS阈值
场景：不同商品的热度不一样，所以我们需要针对不同的参数设置不同的QPS阈值
案例：给order/{id}进行热点参数限流
注意：热点参数限流对默认SPringMVC资源无效，只有通过@SentinelResource注解的才行
对我们设置@SentinelResource的控制器进行参数限流
测试：
单机阈值QPS为5，对几个http进行请求测试
