3.2.2Sentinel的线程隔离
用法说明：
在添加限流规则时，可以选择两种阈值类型：
- QPS：就是每秒的请求数
- 线程数：是该资源能使用用的tomcat线程数的最大值即通过限制线程数量 实现线程隔离( 舱壁模式)
3.2.3总结
线程隔离的两种手段
- 信号量隔离
- 线程池隔离
信号量隔离的特点
- 基于计数器模式 简单 开销小
线程池隔离的特点
- 基于线程池模式 有额外开销 但隔离控制更强
3.3熔断隔离
熔断降级是解决雪崩问题的重要手段
其思路是由断路器统计服务调用的异常比例、慢请求比例 若超出阈值则会熔断该服务 即拦截访问该服务的一切请求
而当服务恢复时 断路器会放行访问该服务的请求 断路器控制熔断和放行是通过状态机来完成的：
状态机包括三个状态：
- closed：关闭状态 断路器放行所有请求 并开始统计异常比例、慢请求比例 超过阈值则切换到open状态
- open：打开状态 服务调用被熔断 访问被熔断服务的请求会被拒绝 快速失败 直接走降级逻辑
Open状态将会在设定的熔断时间结束后会进入half-open状态
- half-open：半开状态 放行一次请求 根据执行结果来判断接下来的操作
- 请求成功：则切换到closed状态
- 请求失败：则切换到open状态
断路器熔断策略有三种：慢调用、异常比例、异常数
3.3.1熔断策略-慢调用
慢调用：业务的响应时长(ReponseTime)大于指定时长的请求认定为慢调用请求
在指定时间内 如果请求数量超过设定的最小数量 慢调用比例大于设定的阈值 则触发熔断
解读：RT超过500ms的调用是慢调用 统计最近10000ms(10s)内的请求
如果请求量超过10次 并且慢调用比例大于0.5 则触发熔断 熔断时长为5秒
然后进入half-open状态 5秒后再放行一次请求做测试 若扔失败则进入open状态 反之切换到closed状态
3.3.2熔断策略-异常比例、异常数
异常比例或异常数：统计指定时间内的调用 如果调用次数超过指定请求数
并且出现异常的比例达到设定的比例阈值(或超过指定异常数)则触发熔断
例如 一个异常比例设置：
解读：统计最近1000ms内的请求 如果请求量超过10次 并且异常比例不低于0.4 则触发熔断。
一个异常数设置：
解读：统计最近1000ms内的请求 如果请求量超过10次 并且异常比例不低于2次 则触发熔断
4.授权规则
授权规则可以对请求方来源做判断和控制
4.1授权规则
4.1.1基本规则
授权规则可以对调用方的来源做控制 有白名单和黑名单两种方式
- 白名单：来源（origin）在白名单内的调用者允许访问
- 黑名单：来源（origin）在黑名单内的调用者不允许访问
点击左侧菜单的授权，可以看到授权规则：
- 资源名：就是受保护的资源 例如/order/{orderId}
- 流控应用：是来源者的名单，
- 如果是勾选白名单，则名单中的来源被许可访问。
- 如果是勾选黑名单 则名单中的来源被禁止访问。
允许请求从gateway到order-service 不允许浏览器直接访问order-service
那么白名单中就要填写网关的来源名称（origin）
4.1.2获取网关来源名称(origin)
允许请求从gateway到order-service，不允许浏览器访问order-service，那么白名单中就要填写网关的来源名称（origin） 。
4.1.2.如何获取origin
Sentinel是通过RequestOriginParser这个接口的parseOrigin来获取请求的来源的。
public interface RequestOriginParser { /** * 从请求request对象中获取origin，获取方式自定义 */ String parseOrigin(HttpServletRequest request); }
这个方法的作用就是从request对象中 获取请求者的origin值并返回。
默认情况下 sentinel不管请求者从哪里来 返回值永远是default 即一切请求的来源都被认为是一样的值default
因此 需要自定义这个接口的实现 让不同的请求 返回不同的origin
package cn.itcast.order.sentinel; import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.RequestOriginParser; import org.springframework.stereotype.Component; import org.springframework.util.StringUtils; import javax.servlet.http.HttpServletRequest; @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"; } // 3.返回请求头中的值 return origin; } }
4.1.3为网关添加请求头
让所有从gateway路由到微服务的请求都带上origin头
利用之前学习的一个GatewayFilter来实现 AddRequestHeaderGatewayFilter
修改gateway服务中的application.yml 添加一个defaultFilter：
spring: cloud: gateway: default-filters: - AddRequestHeader=origin,gateway routes: # ...略
这样 从gateway路由的所有请求都会带上origin头 值为gateway 而从其它地方到达微服务的请求则没有这个头
4.2自定义异常结果
默认情况下 发生限流、降级、授权拦截时 都会抛出异常到调用方
异常结果都是flow limmiting(限流) 这样不够友好 无法得知是限流还是降级还是授权拦截 故出现自定义异常
4.2.1异常类型
如果要自定义异常时的返回结果，需要实现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 | 系统规则异常 |
4.2.2自定义异常处理
在order-service中定义自定义异常处理类SentinelExceptionHandler：
package cn.itcast.order.sentinel; import com.alibaba.csp.sentinel.adapter.spring.webmvc.callback.BlockExceptionHandler; import com.alibaba.csp.sentinel.slots.block.BlockException; import com.alibaba.csp.sentinel.slots.block.authority.AuthorityException; import com.alibaba.csp.sentinel.slots.block.degrade.DegradeException; import com.alibaba.csp.sentinel.slots.block.flow.FlowException; import com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowException; import org.springframework.stereotype.Component; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; @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 + "}"); } }
5.规则持久化
当前sentinel的所有规则都是内存存储 重启后所有规则都会丢失
在生产环境下 必须确保这些规则的持久化 避免丢失
5.1规则管理模式
规则是否能持久化 取决于规则管理模式 sentinel支持三种规则管理模式：
- 原始模式：Sentinel的默认模式 将规则保存在内存 重启服务会丢失 (不支持数据持久化)
- pull模式：保存在本地或数据库中 定时去读取 (数据一致性的时效性较差)
- push模式：保存在nacos 监听变更实时更新
5.1.1规则管理模式-pull模式
pull模式：控制台将配置的规则推送到Sentinel客户端 而客户端会将配置规则保存在本地文件或数据库中
以后会定时去本地文件或数据库中查询(轮询) 更新本地规则
5.1.2规则管理模式-push模式
push模式：控制台将配置规则推送到远程配置中心 例如Nacos。Sentinel客户端监听Nacos
获取配置变更的推送消息 完成本地配置更新
5.2实现push模式
修改OrderService 让其监听Nacos中的sentinel规则配置
5.2.1引入依赖
在order-service中引入sentinel监听nacos的依赖：
<dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-datasource-nacos</artifactId> </dependency>
5.2.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-flow
