前言：
Sentinel 服务容错简介
Doker安装与整合Spring cloud alibaba
作用在资源之上，定义以什么样的方式保护资源，主要包括流量控制规则、熔断降级规则、热点规则以及系统保
护规则。本质就是用来定义如何进行保护资源。

流控规则 flow

• 流量控制，其原理是监控应用流量的 QPS(每秒查询率) 或 并发线程数 等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。它是针对服务提供方进行设置的。
  

一条限流规则主要由下面几个因素组成，我们可以组合这些元素来实现不同的限流效果：

• resource ：资源名，即限流规则的作用对象
• limitApp : 流控针对的调用来源，若为 default 则不区分调用来源
• grade : 限流阈值类型（并发线程数 或 QPS）
• count : 限流阈值
• strategy : 调用关系限流策略（直接，关联，链路）
• controlBehavior : 流量控制效果（快速失败、Warm Up、匀速排队）
  

流量控制主要有两种统计类型，一种是统计并发线程数，另外一种则是统计 QPS(访问数）。类型由 FlowRule 的grade 字段来定义。其中0 代表根据并发数量来限流，1 代表根据 QPS 来进行流量控制。其中线程数、QPS 值，都是由 StatisticSlot 实时统计获取的。
超出流控限制后便会报错（可通过代码更改报错信息）

1、QPS流控

• grade 字段为1，根据对资源的访问次数进行流控。

2、并发线程数流控

• 并发数控制用于保护业务线程池不被慢调用耗尽。
• 假设线程数设置为1，当一个线程请求时，如果还没有响应的情况下，另一个线程又进来访问，则这些请求都会排除在外，直到响应后再处理下一个线程。
• 例如，当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加，对于调用者来说，意味着吞吐量下降和更多的线程数占用，极端情况下甚至导致线程池耗
  尽。
  • 为应对太多线程占用的情况，业内有使用隔离的方案，比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢（线程池隔离）。这种隔离方案虽然隔离性比较好，但是代价就是线程数目太多，线程上下文切换的 overhead 比较大，特别是对低延时的调用有比较大的影响。
• Sentinel 并发控制不负责创建和管理线程池，而是简单统计当前请求上下文的线程数目（正在执行的调用数目），如果超出阈值，新的请求会被立即拒绝，效果类似于信号量隔离。并发数控制通常在调用端进行配置。

3、流控模式

• 直接：接口达到限流条件时，开启限流。即只对指定的接口进行流控。也是默认的模式。
• 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流。
  • 当两个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联。
  • 比如对数据库同一个字段的 读操作和写操作 存在争抢，读的速度过高会影响写得速度，写的速度过高会影响读的速度。如果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢。
  • 为读操作增加关联流控关联写操作，这样写操作的次数也会被统计在读操作流控中，而对于写操作本身没有任何影响。
• 链路：统计从指定上级接口链路访问到本资源的请求，触发阈值时，对指定链路限流。
  • 例如，OrderController 控制器类中的 message1 和 message2 这两个方法都会调用 Service 中的 message 方法，这时就可以针对这两个链路的 message资源 进行限流了。
  • 注意：
    • Service 中的 message 方法需要用 @SentinelResource 注解指定资源名（或异常处理函数，因为不会走统一异常处理）
    • Sentinel 1.7 版本后，Sentinel默认会将Controller方法做context收敛，导致链路模式的流控失效，
      需要添加配置：

spring.cloud.sentinel.webContextUnify=false # 关闭context收敛

4、流控效果

所谓流控效果，是指当服务被流控了，以什么样的效果去处理。在 Sentinel 中，内置了以下三种处理方式：

• 快速失败（默认）: 是默认的流量控制方式，当超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException 。这种方式适用于对系统处理能力确切已知的情况下，比如通过压测确定了系统的准确水位时。
• Warm Up（预热）：即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在预热时长内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。
  • 冷加载因子：codeFactor 默认是3，即请求 QPS 从 count / 3 开始，经预热时长逐渐升至设定的 count 阈值 。
  • 需要设置 预热时长（秒）
• 排队等待：会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。
  • 需要设置 超时时长（毫秒）
  • 让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。

熔断（降级）规则 degrade

熔断规则就是设置当满足什么条件的时候，对服务进行降级。
它通常是在服务消费端来进行配置。
熔断降级规则（DegradeRule）包含下面几个重要的属性：

Field	说明	默认值
resource	资源名，即规则的作用对象
grade	熔断策略，支持慢调用比例/异常比例/异常数策略	慢调用比例
count	慢调用比例模式下为 慢调用临界 RT（超出该值计为慢调用）异常比例/异常数模式下为 对应的阈值
timeWindow	熔断时长，单位为 sminRequestAmount
熔断触发的最小请求数，请求数小于该值时即使异常比率超出阈值也不会熔断（1.7.0 引入）	5
statIntervalMs	统计时长（单位为 ms），如 60*1000 代表分钟级（1.8.0引入）	1000m
sslowRatioThreshold	慢调用比例阈值，仅慢调用比例模式有效（1.8.0 引入）

1、慢调用比例

• 选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（最大响应时间 毫秒），请求的响应时间大于该值则统计为慢调用。
• 当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。
• 经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若下一个请求响应时间小于设置的慢调用 RT 则结束熔断，否则会再次被熔断。
  

2、异常比例

• 当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。
• 经过熔断时长后熔断器会进入探测恢复状态（HALFOPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0] ，代表0% - 100%。
  

3、异常数

• 当单位统计时长内的异常数目超过阈值之后会自动进行熔断。
• 经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。
• 注意：异常降级 仅针对业务异常 ，对 Sentinel 限流降级本身的异常（ BlockException ）不生效。

热点规则 param-flow

何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如：

• 商品 ID 为参数，统计一段时间内最常购买的商品 ID 并进行限制

• 用户 ID 为参数，针对一段时间内频繁访问的用户 ID 并进行限制
  热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。
  热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。
  

• Sentinel 利用 LRU 策略统计最近最常访问的热点参数，结合令牌桶算法来进行参数级别的流控。热点参数限流支持集群模式。

• 热点参数规则（ParamFlowRule ）类似于流量控制规则（FlowRule ）：

属性	说明	默认值
resource	资源名，必填
count	限流阈值，必填
grade	限流模式	QPS 模式
durationInSec	统计窗口时间长度（单位为秒），1.6.0 版本开始支持	1s
controlBehavior	流控效果（支持快速失败和匀速排队模式），1.6.0 版本开始支持	快速失败maxQueueingTimeMs
sparamIdx	热点参数的索引，必填，对应 SphU.entry(xxx, args) 中的参数索引位置paramFlowItemList	参数例外项，可以针对指定的参数值单独设置限流阈值，不受前面 count 阈值的限制。 仅支持基本类型和字符串类型
clusterMode	是否是集群参数流控规则	false
clusterConfig	集群流控相关配置

• 注意：要实现热点参数规则，必须使用 @SentinelResouce 注解来指定资源，否则热点规则将不会生
  效。

@GetMapping("/message1")
@SentinelResource(value = "messages1", blockHandler = "hotBlock")
public String message1(Integer id) throws Exception {return "message1" + id;
}
public String hotBlock(Integer id, BlockException e) {return "热点规则限流....";
}

• 先添加热点规则
  

• 可以在热点规则里添加 参数例外项（对指定参数进行额外处理）
  

授权规则 authority

• 很多时候，我们需要根据调用来源来判断该次请求是否允许放行，这时候可以使用 Sentinel 的来源访问控制（黑白名单控制）的功能。
• 来源访问控制根据资源的请求来源（origin）限制资源是否通过
  • 若配置白名单则只有请求来源位于白名单内时才可通过；
  • 若配置黑名单则请求来源位于黑名单时不通过，其余的请求通过。
• 来源访问控制规则（ AuthorityRule ）非常简单，主要有以下配置项：
  • resource ：资源名，即限流规则的作用对象。
  • limitApp ：对应的 黑名单/白名单，不同 origin 用 , 分隔，如 appA,appB 。
  • strategy ：限制模式， AUTHORITY_WHITE 为白名单模式， AUTHORITY_BLACK 为黑名单模式，默认为白名单模式。

1、应用场景

• 假设有三个微服，分别为 A、B 和 C。而 A 和 B 都会访问 C。如果希望 A 可以访问 C，而 B 不能访问
  C，则可以进行授权规则配置来实现。
  

• 流控应用：是来源标识，Sentinel 提供了 RequestOriginParser 接口来处理来源。只
  要 Sentinel 保护的接口资源被访问，Sentinel 就会调用 RequestOriginParser 的实现类去解析访问来源。

2、自定义来源

• 区分来源，本质是从 request 作用域中获取参数，交给流控应用处使用。
• 在 微服中创建一个 config 包，并在这个包下新建一个
  类（例如 RequestOriginParserDefinition），并让这个类实现 Sentinel 提供的
  RequestOriginParser 接口，并添加注解注入Spring，然后重写 parseOrigin 方法即可。

@Configuration
public class RequestOriginParserDefinition implements RequestOriginParser {@Overridepublic String parseOrigin(HttpServletRequest request) {return request.getParameter("serverName");}
}

3、授权规则配置

• 启动微服务，浏览器正常访问接口，在url地址后添加?serverName=来源，例如：
  http://localhost:8072/order/message1?serverName=pc
• 然后再 Sentinel 客户端中添加授权即可。

系统规则

• 系统保护规则是从应用级别的入口流量进行控制，从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和 并发线程数等几个维度监控应用指标，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
• 系统保护规则是应用整体维度的，而不是资源维度的，并且仅对入口流量 (进入应用的流量) 生效。
• Load 自适应（仅对 Linux/Unix-like 机器生效）：系统的 load1 作为启发指标，进行自适应系统保护。当系统 load1 超过设定的启发值，且系统当前的并发线程数超过估算的系统容量时才会触发系统
  保护（BBR 阶段）。系统容量由系统的 maxQps * minRt 估算得出。设定参考值一般是 CPU cores *2.5 。
• CPU 使用率（1.5.0+ 版本）：当系统 CPU 使用率超过阈值即触发系统保护（取值范围 0.0-1.0），比较灵敏。
• 平均 RT：当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
• 并发线程数：当单台机器上所有入口流量的并发线程数达到 阈值 即触发系统保护。
• 入口 QPS：当单台机器上所有入口流量的 QPS 达到 阈值 即触发系统保护。