Sentinel之授权规则与规则持久化
一、上集回顾
上级文章地址：【SpringCloud】Sentinel 之隔离与降级_面向架构编程的博客-CSDN博客
我们先来回顾一下Sentinel控制台上面的功能：
所以，本章节就来研究 "授权规则"这一功能模块。
二、授权规则
授权规则可以对请求方来源做判断和控制。（请求者的身份）
基本规则
授权规则可以对调用方的来源做控制，有白名单和黑名单两种方式。
白名单：来源（origin）在白名单内的调用者允许访问
黑名单：来源（origin）在黑名单内的调用者不允许访问
点击左侧菜单的"授权规则"，右上角有一个"新增授权规则"的button：
资源名：就是受保护的资源，例如/order/{orderId}
流控应用：是来源者的名单，
如果是勾选白名单，则名单中的来源被许可访问。
如果是勾选黑名单，则名单中的来源被禁止访问。
也就是说，如果选择了"白名单"，只有 指定的流控应用可以访问，其它都不行！！！
【问】有了Gateway做身份认证，为啥还要Sentinel授权规则呢？？？
假设项目的源代码泄露，那么网关有可能被绕过！然后直接访问微服务。这样子我们之前在网关中做的安全校验都将会失效。
所以，这个时候我们就需要Sentinel授权规则！它可以帮我们判断"请求是从哪里来的?"
我们允许请求从gateway到order-service，不允许浏览器访问order-service，那么白名单中就要填写网关的来源名称（origin）。
1.获取origin
Sentinel是通过RequestOriginParser接口的parseOrigin来获取请求的来源的。
// 请求来源解析器
public interface RequestOriginParser {
/**
* 从请求request对象中获取origin，获取方式自定义
*/
String parseOrigin(HttpServletRequest request);
}这个方法的作用就是从request对象中，获取请求者的origin值并返回。
但是，可惜的是，默认情况下，sentinel不管请求者从哪里来，返回值永远是default，也就是说一切请求的来源都被认为是一样的值default。
因此，我们需要自定义这个接口的实现！！！让不同的请求，返回不同的origin。
代码实现
order-service服务中，新建一个包sentienl，我们定义一个RequestOriginParser的实现类
@Component
public class HeaderOriginParser implements RequestOriginParser {
@Override
public String parseOrigin(HttpServletRequest request) {
// 1.获取请求头
String origin = request.getHeader("origin");
// 2.非空判断
if (StringUtils.isEmpty(origin)) {
origin = "blank";
}
return origin;
}
}这里我们写了一个判断请求头是否为空的Demo。
2.给网关添加请求头
既然获取请求origin的方式是从reques-header中获取origin值，我们必须让所有从gateway路由到微服务的请求都带上origin头。
我们可以用GatewayFilter来实现
修改gateway服务中的application.yml，添加一个defaultFilter：
spring:
application:
name: gateway
cloud:
nacos:
server-addr: localhost:8848 # nacos 地址
gateway:
routes:
......
default-filters: # 默认过滤器 对所有的路由都生效
- AddRequestHeader=origin,gateway
routes:
...... 给网关添加过滤器，名为origin，值为gateway
这样，从gateway路由的所有请求都会带上origin头，值为gateway。而从其它地方（比如：浏览器）到达微服务的请求则没有这个头。
3.配置授权规则
添加一个授权规则，放行origin值为gateway的请求。
4.测试
现在，我们直接跳过网关，访问order-service服务，即直接访问order-service服务的端口号
通过网关访问（10010）
但是请注意一点，/user/{userId}并不会受到上述的限制！
二、自定义异常结果
默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。异常结果都是flow limmiting（限流）。这样不够友好，无法得知是限流还是降级还是授权拦截。
异常类型
而如果要自定义异常时的返回结果，需要实现BlockExceptionHandler接口：
public interface BlockExceptionHandler {
/**
* 处理请求被限流、降级、授权拦截时抛出的异常：BlockException
*/
void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;
}这个方法有三个参数：
HttpServletRequest request：request对象
HttpServletResponse response：response对象
BlockException e：被sentinel拦截时抛出的异常
这里的BlockException包含多个不同的子类：
异常 | 说明 |
FlowException | 限流异常 |
ParamFlowException | 热点参数限流的异常 |
DegradeException | 降级异常 |
AuthorityException | 授权规则异常 |
SystemBlockException | 系统规则异常 |
自定义异常处理
在order-service定义一个自定义异常处理类
@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的所有规则都是内存存储，重启后所有规则都会丢失。在生产环境下，我们必须确保这些规则的持久化，避免丢失。
规则管理模式
规则是否能持久化，取决于规则管理模式，sentinel支持三种规则管理模式：
原始模式：Sentinel的默认模式，将规则保存在内存，重启服务会丢失。
pull模式
push模式
pull模式
pull模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。
push模式
push模式：控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel客户端监听Nacos，获取配置变更的推送消息，完成本地配置更新。
