SpringCloud Alibaba之服务熔断与降级Sentinel（Alibaba第二篇）
一、提前准备
1、分析之前的服务降级熔断Hystrix
- 使用过我们的Hystrix后，就会发现它很是麻烦，很多东西我们要自己去配置表【就像我们之前学习的Eureka一样，我们不用再自己去建什么8001哦，作为Eureka的主机配置，使用了nacos就解决了，而sentinel就是替代料Hystrix】
- sentinel能干什么
2、sentinel下载安装
- 下载地址：https://github.com/alibaba/sentinel/releases
- 运行后端
把Tomcat关掉
- 访问客户端
3、sentinel初始化监控
- 前提是你的nacos启动好。
（1）建项目
- 导入依赖
cn.mldn
cloud-api-commons
1.0-SNAPSHOT
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
com.alibaba.csp
sentinel-datasource-nacos
com.alibaba.cloud
spring-cloud-starter-alibaba-sentinel
org.springframework.cloud
spring-cloud-starter-openfeign
org.springframework.boot
spring-boot-starter-web
org.springframework.boot
spring-boot-starter-actuator
org.springframework.boot
spring-boot-devtools
runtime
true
cn.hutool
hutool-all
4.6.3
org.projectlombok
lombok
true
org.springframework.boot
spring-boot-starter-test
test
-
主启动
-
yaml
这个client-ip改为port：8719 -
随便写点逻辑
（2）启动相关8080,8401，8848
- nacos启动
- sentinel启动
- 8401启动
- 访问测试
什么都没有，因为sentinel是采用懒加载机制，只有你的项目访问过了，才会被加载。
- 再次测试
- 我请求不断的来，但是就是不行，CAO哦，烦死了，天天报错。
- 修改版本试一试还是不行，安装个Linux的试一试
- 最后自己才发现是那个client-ip应该是port，这个client-ip后续才会用。
二、流量控制
（一）sentinel流量控制
1、sentinel流控的位置
- 相关概念
2、流空规则
（1）流量控制-每秒钟的请求数量（QPS）直接失败
-
配置位置
我们这可以设置自己的值，如果单机域值。这里我们可以设置一个2
只要你在一秒内多点两次就会出问题
然后你又恢复一秒点两次啊，然后就没事。 -
思考：
- 我们的Hystrix是通过自己创建一个模块来管理我们的其他模块，然后写一个兜底的。参考文章，那我们这样的英语怎么给用户展示呢，用户不懂这句话怎么办呢，是吧。
- 如何自定义，我们的流量控制呢？
- 上面问题留着后续解决。
（2）流量控制-线程数直接失败
- 上面的每秒钟请求数来了后，都是来的超过2两个后，直接报错，但是我们的线程数是可以来多个的，但是我处理的慢慢的处理。但是处理的还是我能处理的那么几个。
当你多个线程来了后，你进行来了，后续等我慢慢的处理，但是如果多了，我搞不定就同样的报错，是已经把它放进来了。
（3）流量控制-关联
为什么呢，因为在微服务里面里面很多时候调用的时候，我这里限流外，你那里也可以进行限流。
- 这里使用postman进行测试
首先测试通过
- 运行测试
然后再次访问我们的testC就会发现C挂了。
（4）流量控制-链路
这种后续讲解。
3、流空效果
（1）快速失败
这个不多说了吧
它的具体源代码来源于这里
（2）预热
一个系统怕的是突然来了访问量超级多。预热就是请允许我系统慢慢的才能来处理。
- 加载因子理解
其实就是你单机的配置为10，当你请求平时来的请求，可以最大请求10/3个，然后进行预热，在5秒钟内，你要从3预热到10.
- 代码测试
测试A的时候，刚开始1秒内，你请求三次后就会报错，过了5秒后，你点三次也不会报错。
（3）排队等待
- 排队等待其实就是内部，管理外面来不来哦，我反正一秒钟内只能处理那么一些。
- 可以测试
新建一个collection
（二）sentinel降级
1、服务降级概念
请与Hystrix的服务熔断进行对比学习。相关文章
而我们的sentinel是没有半开状态的。
2、服务降级策略
（1）三种介绍
- RT
- 异常比列与异常数
（2）服务降级-RT规则
-
RT：慢调用比例 (SLOW_REQUEST_RATIO)：选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用。当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断。
条件时一秒内有五个请求，并且平均时间大于阈值的条件。 -
案例演示
这样单独测试勉勉强强是可以处理请求的
-
那要是你多个请求来处理就完了【模拟我们用jmeter进行测试，模拟10个线程在一秒过去，此时就访问D根本出不来】
（3）服务降级-异常比列
- 配置
访问第一次
再一次访问
是因为我们要满足数量：请求量必须大于5，而且异常比率大于20%.只要用我们的Jmeter进行测试就OK了。
（4）服务降级-异常数
就一分钟之内，如果异常数到达阈值就报错，而你要跳转到相应的页面展示给用户。
即如果四次你都是出现错误，那就跳闸段了。
（三）热点key限流
1、什么是热点Key
就比如带有如下的一个p1的参数进行限流【假设这个p1比较火】
2、兜底方法
3、配置兜底方法
- 这里补充一点
只要你不写blockHandler参数和下面个兜底方法没有带上BlockException异常，它都会跳转到默认的页面Error Page也免去。
- 另外这个页面说明
4、参数例外项
其实就是例外的时候，然后什么什么
此时你p1等于5的话，是没事的，你只要点到200秒每次后才会报错。
- 添加个异常看看
它直接来到这里了。
5、系统规则
我们之前的限流是对某一个具体的规则进行限流，而系统规则则是对总体进行限流。
（四）限流与SentinelResource
1、按资源名称限流
- 正常测试
但是双加后发现报错的是page页面，没有按着我们自己的思路走。
而且我发现把后台系统暂停后启动，配置的规则也自动消失。【先不管没生效的问题】
2、根据URL进行限流
启动测试是来到的这里。
-
我们两种方式都可以吧。
-
我们先来分析根据上面两个情况带来的问题
- 兜底的方法与我们的业务逻辑耦合度高
- 如果我多个方法都需要兜底方法的话，那岂不是我们要写N多个。
3、解决上一步中分析的问题
- 先编写controller
- 处理Handler
- 补充Handler
- 启动测试
配置规则
这样配置就成功了
4、流控逻辑
-
之前的过程
我们现在它自定义页面，我们只要在上面去配置即可完成，但是我们也可以自定义配置，但是不常用【基本不用，在代码里面写死】，基本不采用。 -
其他补充
三、sentinel服务熔断
之前的ribbon
1、建立三个module
（1）建立9003
- 建项目
- 导依赖
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
cn.mldn
cloud-api-commons
1.0-SNAPSHOT
org.springframework.boot
spring-boot-starter-web
org.springframework.boot
spring-boot-starter-actuator
org.springframework.boot
spring-boot-devtools
runtime
true
org.projectlombok
lombok
true
org.springframework.boot
spring-boot-starter-test
test
- 写yaml
server:
port: 9003
spring:
application:
name: nacos-payment-provider
cloud:
nacos:
discovery:
server-addr: localhost:8848 #配置Nacos地址
management:
endpoints:
web:
exposure:
include: '*'
- 主启动
（2）建立9004
- 建项目【和9003一样的】
- 导pom
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
cn.mldn
cloud-api-commons
1.0-SNAPSHOT
org.springframework.boot
spring-boot-starter-web
org.springframework.boot
spring-boot-starter-actuator
org.springframework.boot
spring-boot-devtools
runtime
true
org.projectlombok
lombok
true
org.springframework.boot
spring-boot-starter-test
test
- yaml
server:
port: 9004
spring:
application:
name: nacos-payment-provider
cloud:
nacos:
discovery:
server-addr: localhost:8848 #配置Nacos地址
management:
endpoints:
web:
exposure:
include: '*'
- 主启动
- 对9003和9004业务进行抽取
9003与9004是微服务提供者。
（3）建立84
- 建立项目
- 导入依赖
org.springframework.cloud
spring-cloud-starter-openfeign
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
com.alibaba.cloud
spring-cloud-starter-alibaba-sentinel
cn.mldn
cloud-api-commons
1.0-SNAPSHOT
org.springframework.boot
spring-boot-starter-web
org.springframework.boot
spring-boot-starter-actuator
org.springframework.boot
spring-boot-devtools
runtime
true
org.projectlombok
lombok
true
org.springframework.boot
spring-boot-starter-test
test
- 写yaml
server:
port: 84
spring:
application:
name: nacos-order-consumer
cloud:
nacos:
discovery:
server-addr: localhost:8848
sentinel:
transport:
#配置Sentinel dashboard地址
dashboard: localhost:8080
#默认8719端口，假如被占用会自动从8719开始依次+1扫描,直至找到未被占用的端口
port: 8719
#消费者将要去访问的微服务名称(注册成功进nacos的微服务提供者)
service-url:
nacos-user-service: http://nacos-payment-provider
# 激活Sentinel对Feign的支持
feign:
sentinel:
enabled: true
- 主启动
- 逻辑
然后把这三个都启动。还有就是sentinel与nacos启动
2、回顾一下84的业务逻辑
1,2，3是正常用户，而4是非法访问，而且4之后，就是非法访问。
- 正常访问
- 非正常访问直接访问page页面。
3、兜底方法【fallback管运行异常】，相当于Hystrix的服务降级
4、降级处理【blockhandler处理的是配置违规】
如果点两次才会我们的sentinel就会接管了
5、fallback与blockhandler都配置
那如果访问4到底是fallback接管呢，还是blockhandler接管呢
-
我们访问1的时候【点快了都会触发限流】
又是昨天的效果，不知道为啥。反正是启动效果了。 -
再访问4
都是我们的原来的项目提供的page页面，这问题先不管，因为只要把它抽取出来是个类就没问题了。
点块一点就时如下
-
结论
6、exceptionsToIgnore服务配置
7、sentinel服务熔断之OpenFeign
-
肯定是先引入feign的依赖【84里面】
-
激活sentinel对feign的支持
-
OpenFeign就时接口加注解
-
启动测试
此时只要把9003断掉即会发现发生降级。 -
sentinel与Hystrix对比
四、sentinel规则持久化
1、sentinel持久化的由来
像我们写的上面部分，只要微服务重新启动，那就这些配置就消失了。
2、配置持久化的步骤
-
持久化到哪里
其实可以写成文件，数据库都可以，不仅仅是写进去nacos。 -
修改8401
- 添加pom
- 改yaml
- 添加nacos配置
- 启动测试：localhost:8401/rateLimit/byUrl即可
- 添加pom