微服务保护--Sentinel

@toc

一、雪崩问题

解释：微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。（一个服务器的Tomcat资源耗尽，导致依赖的服务全部故障）

1.1 解决办法

解决雪崩问题有四种办法如下：

• 超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待。 -- 因服务故障引起的雪崩问题
• 舱壁模式：限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。 -- 因服务故障
• 熔断降级：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。 -- 因服务故障
• 流量控制：限制业务访问的QPS，避免服务因流量的突增而故障。（QPS:每秒钟处理请求的数量） -- 因高并发流量导致服务故障

二、服务保护技术的对比

Sentinel的对比，Hystrix已经不维护了。具体对比如下：

三、安装并整合Sentinel控制台

• sentinel官方提供了UI控制台，方便我们对系统做限流设置。下载好的jar包，将其拷贝到一个你能记住的非中文目录，然后运行命令：java -jar sentinel-dashboard-1.8.1.jar，然后访问：localhost:8080 即可看到控制台页面，默认的账户和密码都是sentinel。
• 打开在命令行的nacos的bin目录下输入startup.cmd -m standalone启动nacos。接着打开实用篇的代码，将yaml文件的信息做出相应的修改，这是本人的，MySQL有5和8两个版本，由于前面是匹配虚拟机里的数据库，换回MySQL5，端口3305。还有将前面的nacos地址换回localhost，还需要修改order-service的端口号，不然与sentinel的控制台端口冲突。
• 在order-service中整合Sentinel，并且连接Sentinel的控制台。引入sentinel依赖；配置控制台地址；访问微服务的任意端点，触发sentinel监控。

四、限流规则

4.1 簇点链路

• 项目内的调用链路，链路中被监控的每个接口就是一个资源。默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。 流控、熔断等都是针对簇点链路中的资源来设置的。
• 流控规则入门案例：给 /order/{orderId}这个资源设置流控规则，QPS不能超过 5。然后利用jemeter测试。

4.2 流控模式

添加限流规则时，点击高级选项，可以选择三种流控模式：

• 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式。
• 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流。（满足下面条件：两个有竞争关系的资源；一个优先级较高，一个优先级较低限流）
• 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流。（有查询订单和创建订单业务，两者都需要查询商品。针对从查询订单进入到查询商品的请求统计，并设置限流。）

4.3 流控效果

流控效果是指请求达到流控阈值时应该采取的措施，包括三种：

• 快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
• warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。（给/order/{orderId}这个资源设置限流，最大QPS为10，利用warm up效果，预热时长为5秒）
• 排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长（给/order/{orderId}这个资源设置限流，最大QPS为10，利用排队的流控效果，超时时长设置为5s）

4.4 热点参数限流

• 之前的限流是统计访问某个资源的所有请求，判断是否超过QPS阈值。而热点参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。
• 案例：给/order/{orderId}这个资源添加热点参数限流，规则如下：默认的热点参数规则是每1秒请求量不超过2；给102这个参数设置例外：每1秒请求量不超过4；给103这个参数设置例外：每1秒请求量不超过10。
• 热点参数限流对默认的SpringMVC资源无效。

五、隔离和降级

限流可以尽量避免因高并发而引起的服务故障，但服务还会因为其它原因而故障。而要将这些故障控制在一定范围，避免雪崩，就要靠线程隔离（舱壁模式）和熔断降级手段了。不管是线程隔离还是熔断降级，都是对客户端（调用方）的保护。

5.1 Feign整合Sentinel

SpringCloud中，微服务调用都是通过Feign来实现的，因此做客户端保护必须整合Feign和Sentinel。

Feign整合Sentinel的步骤如下：

• 在application.yml中配置：feign.sentienl.enable=true。
• 给FeignClient编写FallbackFactory并注册为Bean。
• 将FallbackFactory配置到FeignClient

5.2 线程隔离

线程隔离有两种方式实现：

• 案例：线程隔离（舱壁模式）-- 给 UserClient的查询用户接口设置流控规则，线程数不能超过 2。然后利用jemeter测试。
• 信号量隔离的特点：基于计数器模式，简单，开销小。
• 线程池隔离的特点：基于线程池模式，有额外开销，但隔离控制更强。

5.3 熔断降级

熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路器会放行访问该服务的请求。

断路器熔断策略有三种：慢调用、异常比例、异常数。

• 慢调用：业务的响应时长（RT）大于指定时长的请求认定为慢调用请求。在指定时间内，如果请求数量超过设定的最小数量，慢调用比例大于设定的阈值，则触发熔断。
• 案例：给 UserClient的查询用户接口设置降级规则，慢调用的RT阈值为50ms，统计时间为1秒，最小请求数量为5，失败阈值比例为0.4，熔断时长为5。提示：为了触发慢调用规则，我们需要修改UserService中的业务，增加业务耗时。
• 异常比例或异常数：统计指定时间内的调用，如果调用次数超过指定请求数，并且出现异常的比例达到设定的比例阈值（或超过指定异常数），则触发熔断。
• 案例：给 UserClient的查询用户接口设置降级规则，统计时间为1秒，最小请求数量为5，失败阈值比例为0.4，熔断时长为5s。

六、授权规则

授权规则可以对调用方的来源做控制，有白名单和黑名单两种方式。

• 白名单：来源（origin）在白名单内的调用者允许访问。
• 黑名单：来源（origin）在黑名单内的调用者不允许访问。

获取请求来源的接口--RequestOriginParser。

七、自定义异常结果

默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。如果要自定义异常时的返回结果，需要实现BlockExceptionHandler接口。

八、规则持久化

8.1 规则管理模式

Sentinel的控制台规则管理有三种模式：

• 原始模式：控制台配置的规则直接推送到Sentinel客户端，也就是我们的应用。然后保存在内存中，服务重启则丢失。
• pull模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。
• push模式：控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel客户端监听Nacos，获取配置变更的推送消息，完成本地配置更新。

记录每一个学习瞬间