sentinel配置
# Sentinel的配置
## 流量控制相关的配置
### 详细说明
|选项|说明|
|---|---|
|**来源**|来源默认是default, 即所有的请求, 只要是请求这个资源就算, 不论来源|
|**阈值类型**|QPS: 每秒请求量 <br/> 线程数: 访问该资源占用服务的线程数|
|**流控模式**| 直接: 直接监控该资源, 无论是直接访问或间接访问, 一旦到达阈值就会流控<br/> 关联: 即该资源关联另一个资源, 另一个资源若被限流了, 该资源也会被限流<br/>链路: 链路可以指定一个入口资源, 如果是该入口资源开始调用的, 且最终调用到该资源, 且阈值达到, 才会被限流, 如果不是该入口资源调用的, 那么不会被记录, 不会被限流|
|**流控效果**|快速失败: 一旦达到阈值, 直接失败, 走流控阻塞逻辑<br/> WarmUp: 如果阈值是M, 预热时长为N, 那么一开始的阈值为M/N, 经N秒后阈值变为M, 一旦超过, 直接失败<br/>排队等待: 一旦超过阈值, 超过的请求进入队列等待, 直到超时失败|
## 降级相关的配置
|选项|说明|
|---|---|
|**降级策略**|RT: 最大响应时间, 如果超过该响应时间且满足最小请求数, 就会进入降级(熔断或限流)<br/>异常比例: 即调用微服务发生异常的次数占总次数的比例, 超过该比例则降级<br/>异常数: 即调用微服务发生的异常数, 如果叨叨了阈值, 就会降级|
|**时间窗口**|一旦降级, 就会进入时间窗口, 一直熔断或限流, 直到窗口期结束, 继续判断是否达到阈值, 若达到继续降级, 否则解除降级|
## 资源的定义
### 基于代码式定义资源
```java
try (Entry entry = SphU.entry("resourceName")) {
// 被保护的业务逻辑
// do something here...
} catch (BlockException ex) {
// 资源访问阻止，被限流或被降级
// 在此处进行相应的处理操作
}
```
#### 优点
> 基于代码式定义资源非常的灵活, 可以指定受保护的资源范围
#### 缺点
> 每次都要手写代码, 非常的麻烦
### 基于注解式定义资源
```java
// 原本的业务方法.
@SentinelResource(blockHandler = "blockHandlerForGetUser")
public User getUserById(String id) {
throw new RuntimeException("getUserById command failed");
}
// blockHandler 函数，原方法调用被限流/降级/系统保护的时候调用
public User blockHandlerForGetUser(String id, BlockException ex) {
return new User("admin");
}
```
#### 优点
> 非常的方便, 不需要写代码即可声明和保护资源
#### 缺点
> 缺少了灵活度, 不能自定义受保护的资源范围
#### 要点
1. **如上示例所示, 降级方法的返回值类型必须要一样, 参数列表在必须要一样的基础上加上BlockException的参数, 否则会报错**
2. 如果@SentinalResource设置了fallback, 那么会优先调用fallback对应的方法(该方法可以处理所有的异常)
3. fallback和blockhandler最大的区别是处理的异常范围不同, 如果更具有针对性应选择后者, 如果普遍情况应选择前者
4. **如果fallback方法和原方法不在同一个类中, 那么fallback方法必须是静态**
5. **blockhandler不能声明在其他类**
## 网关限流
[参考文档](https://help.aliyun.com/document_detail/118482.html)
### 前提
> **如果想使用网管限流, sentinel的dashboard版本必须在1.7.1以上, 如果版本低于该版本, 是无法进行网关限流的**
### 配置
```xml
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-sentinel-gateway</artifactId>
</dependency>
```
> 如果引入了依赖, 没有下面的页面, 可以重启sentinel的控制台还有微服务, 就有了
### 说明
|选项|说明|
|----|----|
|**API类型**| Route ID: 路由ID, 就是我们在网关设置的路由规则对应的id, 可以对整个路由规则进行流控<br/>API分组: 网关设置可以设置API分组, 即对整个分组的资源进行流控|
|**属性参数**|这里就是属性匹配, 即如果客户端IP, 远程主机, 请求头, URL参数或Cookie信息满足这里设置的规则才进行流控, 这里可以做对拉某个IP的黑名单|
|**流控方式**|快速失败: 如果超过了阈值, 直接返回流控后的逻辑<br/>匀速排队: 匀速排队和普通排队差不多, 超过阈值的请求去排队, 超过超时时间自动返回流控后的规则|
> **注意: 这里有`Burst size`, 这个的意思是, 通常情况下, 有可能某个时刻超过流控的QPS阈值, 这里的大小为允许超出多少的QPS, 为了处理突发状况**
> **这里有一个间隔, 表示这个间隔时间段内不饿能超过该QPS阈值**
## API分组
|选项|说明|
|--|--|
|**API名称**| API名称就是该分组的名称|
|**匹配模式**| 精确: 资源名必须是后面的匹配串, 才能加入分组<br/>前缀: 类似于JavaPath一样的, 如/abc/**, 这个前缀下的所有资源(主要针对path资源)<br/>正则: 通过正则表达式匹配资源
> 有了API分组, 就可以更好的管理资源, 直接从网管这里对这些资源进行流控降级