微服务——服务保护Sentinel
雪崩问题
在单体项目里面，如果某一个模块出问题会导致整个项目都有问题。
在微服务项目里面，单独一个服务出问题理论上是不会影响别的服务的。 但是如果有别的业务需要调用这一个模块的话还是会有问题。
问题产生原因和解决思路
最初那只是一个小小的故障。后来随着调用的服务越来越多，然后等待时消耗完了系统资源，然后就集体蹦了。
解决方案
高并发引发的问题可以通过限流解决.
请求限流用于避免服务故障。
线程隔离用于避免故障扩散.限制了线程数之后这个服务就不会因为调用别的服务导致自身资源消耗殆尽。
为了防止线程资源一直被占用，这里还要做一个服务熔断，让出线程给别的服务。
发生熔断时直接走提前编写的fallback逻辑。这个就是服务降级。舍弃一部分保证整个微服务群的健康。
技术实现
Sentinel
初识sentinel
可以在控制台去配置限流规则，熔断规则等等。
Sentinel 的使用可以分为两个部分:
-
核心库（Jar包）：不依赖任何框架/库，能够运行于 Java 8 及以上的版本的运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。在项目中引入依赖即可实现服务限流、隔离、熔断等功能。
-
控制台（Dashboard）：Dashboard 主要负责管理推送规则、监控、管理机器信息等。
利用给好的jar包，在命令行用如下命令启动
java -Dserver.port=8090 -Dcsp.sentinel.dashboard.server=localhost:8090 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar访问http://localhost:8090页面，就可以看到sentinel的控制台了：
需要输入账号和密码，默认都是：sentinel
登录后，即可看到控制台，默认会监控sentinel-dashboard服务本身：
微服务整合
访问一次之后，就可以顺利被监控了。
docker部署
拉取镜像
docker pull docker.io/bladex/sentinel-dashboard创建容器
docker run --name sentinel -d -p 8858:8858 -d 镜像id
然后剩下的就是改改ip+端口,都是和上面一样的使用方法。
这个东西应该就是让微服务自己把自己的状况快照发送到sentinel，然后由sentinel根据定义的规则决定是否限流熔断等等。不是由sentinel主动发起监控，不然云服务器里面的sentinel怎么可能监控的到我本地的运行项目。
tmd,搞错了。这个玩意没办法从云端监控我的本地项目，只有第一次是本地项目主动发起的。剩下的都是要由sentinel发起监控.
请求限流
快速入门
可以看见，设置每秒一条之后，多出的请求会被sentinel拦截。
添加一个每秒10的阈值之后使用jmeter进行50条线程2s内跑完的任务进行压力测试。
结果无误，2s内只有20条请求正常响应，剩下的全都被异常处理了。
流控模式
关联
关联模式：这个模式是在某两个业务差不多同时发生时，通过限流其中一个业务的方式为另一个业务让行。
然后给query加流控规则,当update1s超过5个请求时对query限流。
jmeter测试，1000个线程100s执行完，也就是每秒10个请求. 可以的看见query被限流了。
链路
sentinel默认只会监控controller的资源，所以要用到sentinel的注解。
链路模式中，是对不同来源的两个链路做监控。但是sentinel默认会给进入SpringMVC的所有请求设置同一个root资源，会导致链路模式失效。
重新配置之后可以看见，service层的资源也被监控了。为其中一个goods设置流控。
流控效果
warm up
使用jmeter进行200个线程20s的压测，初始时成功的只有3个，说明初始阈值就是3，20s里后面每一秒内能通过的线程数也是组件上升。
排队等待
使用jemter进行300个线程20s执行完的压测，qps是15.可以看见，后面大多数请求的响应时间都是接近5s了。这里起到了一个流量整形的作用。
热点参限流
只有那些通过@SentinelResource注解配置的资源才有效。
所以要现在controller的资源上面添加注解。
重启后可以看见hot的簇点链路。
在左侧的热点规则那里进行配置才会有高级选项.然后如下配置
使用jmeter发起3个500线程100s的请求，分别对应三种参数，qps为5.
然后结果如下，jmeter中101的是每秒2个成功，102是每秒4个，103是全部。
隔离和降级
FeginClient整合Sentinel
例如在查询订单的时候，会发起远程调用去查询用户信息。这里就可以编写调用失败后的降级逻辑。
这里启动时会有一个循环依赖的错误。
这里要在order-service服务里面自动注入UserClient时加上@Lazy注解。
或者是在启动类里添加@ComponentScan来扫描feign的包.两个方法都可以
@Autowired
@Lazy
private UserClient userClient;这里运行时也还是会有循环依赖的报错.要将父工程里面的springcloud版本号改成SR8。这次才是真正解决问题.加上@Lazy只是延迟问题发生的时机。
这次在service层的hot下终于可以看见利用feign发起远程调用的接口了。
线程隔离(舱壁模式)
低扇出就是这个服务需要调用的服务较少。
线程池的做法是会开启独立线程的，而信号量的做法则不会。
在jmeter中开启10个线程要求0s内完成。理论上是由8个线程会被拒绝的.
但是因为前面做了降级处理，会返回一个空对象而不是报错所以在控制台才可以看见报错的日志信息。不多不少，正好8个.
熔断降级
下面是sentinel断路器的三个状态和状态之间的切换。需要配置的两个重要参数有，熔断持续时间和熔断的阈值。
慢调用
发生熔断之后成功阻塞了这个接口。
异常比例、异常数
授权规则
测试，然后尝试直接访问order-service时就会报错.
然后通过gateway网关访问就可以正常访问
自定义异常结果
修改返回的限流异常为授权拦截.
通过实现下面的接口将所有不同类型的异常分别处理。
@Component
public class SentinelExceptionHandler implements BlockExceptionHandler {
@Override
public void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception {
String msg = "未知异常";
int status = 429;
if (e instanceof FlowException) {
msg = "请求被限流了";
} else if (e instanceof ParamFlowException) {
msg = "请求被热点参数限流";
} else if (e instanceof DegradeException) {
msg = "请求被降级了";
} else if (e instanceof AuthorityException) {
msg = "没有权限访问";
status = 401;
}
response.setContentType("application/json;charset=utf-8");
response.setStatus(status);
response.getWriter().println("{\"msg\": " + msg + ", \"status\": " + status + "}");
}
}
规则持久化
sentinel把规则保存在内存里，重启就会自动丢失。
规则管理模式
实现push模式
一、修改order-service服务
1.引入依赖
在order-service中引入sentinel监听nacos的依赖：
com.alibaba.csp
sentinel-datasource-nacos
2.配置nacos地址
在order-service中的application.yml文件配置nacos地址及监听的配置信息：
spring:
cloud:
sentinel:
datasource:
flow:
nacos:
server-addr: localhost:8848 # nacos地址
dataId: orderservice-flow-rules
groupId: SENTINEL_GROUP
rule-type: flow # 还可以是：degrade、authority、param-flowflow是持久化的，defrade是降级的
二、修改sentinel-dashboard源码
SentinelDashboard默认不支持nacos的持久化，需要修改源码。
tmd，看着教程巨几把麻烦，以后用服务器厂商提供的应该也不用我来搞这些，就不做了，以后有需求再来看吧.
可以看见最后实现效果如下，在指定页面添加的规则就会自动持久化到nacos.
