wordpress文章发布器,排名优化哪家专业,工业设计公司网站如何建设,asp 制作网站开发目录 一、FeignClient 整合 Sentinel
1.1、整合原因
1.2、实现步骤
1.2.1、修改 OrderService 中的 application.yml 文件
1.2.2、给 FeignClient 编写失败后的降级逻辑
二、线程隔离
2.1、线程隔离的两种方式
2.1.1、线程池隔离
2.1.2、信号量隔离#xff08;Sentin…目录 一、FeignClient 整合 Sentinel
1.1、整合原因
1.2、实现步骤
1.2.1、修改 OrderService 中的 application.yml 文件
1.2.2、给 FeignClient 编写失败后的降级逻辑
二、线程隔离
2.1、线程隔离的两种方式
2.1.1、线程池隔离
2.1.2、信号量隔离Sentinel 默认采用方式
2.2、实现线程隔离舱壁模式
a添加流控规则
b使用 JMeter 进行测试
c分析结果
三、熔断降级
3.1、什么是熔断降级
3.2、熔断策略——慢调用
a在 Sentinel 上给远程调用添加降级规则
b在浏览器中连续刷新分析结果
3.3、熔断策略——异常比例、异常数
a在 Sentinel 上给远程调用添加降级规则
b在浏览器中连续刷新分析结果 一、FeignClient 整合 Sentinel 1.1、整合原因
前面我们学习到的限流虽然可以避免因高并发引起的服务故障但是服务还是可能会因为其他原因故障. 如果要将这些故障控制住避免雪崩就需要靠线程隔离和熔断降级的了.
但不管是线程隔离还是熔断降级都是对 客户端调用方的保护避免服务的调用者被故障的服务拖垮因此我们要就需要在微服务发起远程调用的时候去做隔离和降级也就是说通过 Feign 整合 Sentinel 去做 隔离和降级. 1.2、实现步骤
1.2.1、修改 OrderService 中的 application.yml 文件
在 application.yml 中开启 Feign 的 Sentinel 功能.
feign:sentinel:enabled: true # 开启Feign的Sentinel功能1.2.2、给 FeignClient 编写失败后的降级逻辑
这里有一下两种方式实现降级逻辑.
FallbackClass无法对远程嗲用的异常做处理.FallbackFactory可以对远程调用的异常做处理.
这里我们选择第二种方式具体实现如下
a在 feign-api 项目中自定义类 UserClientFallbackFactory 实现 FallbackFactory 接口
Slf4j
public class UserClientFallbackFactory implements FallbackFactoryUserClient {Overridepublic UserClient create(Throwable throwable) {return new UserClient() {Overridepublic User findById(Long id) {//记录异常信息log.error(查询用户失败!);//根据业务需求返回数据这里返回一个空对象return new User();}};}
}b在 feign-api 项目的 配置类 中将 UserClientFallbackFactory 注册为一个 Bean Beanpublic UserClientFallbackFactory userClientFallbackFactory() {return new UserClientFallbackFactory();}c在 feign-api 项目中的 UserClient 接口feign 远程调用接口中使用 UserClientFallbackFactor.
FeignClient(value userservice, fallbackFactory UserClientFallbackFactory.class)
public interface UserClient {GetMapping(/user/{id})User findById(PathVariable(id) Long id);}二、线程隔离 2.1、线程隔离的两种方式
2.1.1、线程池隔离
线程隔离就是给每个业务划分独立的线程池实现隔离.
比如说我现在有 a、b、c 三个服务而 a 依赖 b 形成一个业务a 依赖 c 形成一个业务那么线程池隔离就会给每个业务所依赖的服务都创建一个线程池也就说这里创建两个线程池一个给b一个给 c. 当有请求到达 a 的时候不会去使用请求本身的这个线程而是去这两个池子里分别去取线程此时这个线程就可以去调用 feign 的客户端发起远程调用.
这样就把两个服务给隔离开了.如果服务 b 出现了故障那么最多也就是把他这边池子里的线程给用完如果还有新的请求还想访问这个服务但是池子满了他还能进来了吗这样一来就不会把服务 a 里面的资源给耗尽了. 优点 1. 支持主动超时线程池模式会给每一个远程调用分配一个独立的线程也就意味着可以通过线程池来控制他. 如果发现有一个请求耗时久了就可以立即终止这个线程.
2. 支持异步调用每次调用都是线程池分配的一个独立的线程不是原来处理 tomcat 请求的线程而不同的服务又是不同的线程池因此可以在给某一个服务处理的请求的同时再给其他服务处理远程调用. 缺点 1. 线程的额外开销比较大每次调用都有独立的线程线程越多开销越大别的不说光是 cpu 上下文切换也是比较耗时的. 适用场景 1.适用于 “低扇出”低扇出就是指我这里有一个服务依赖于其他服务依赖的服务越多扇出越高. 每次远程调用都有独立的线程因此为了避免多线程开销问题更适用于低扇出场景. 2.1.2、信号量隔离Sentinel 默认采用方式
信号量就相当于之前所讲到过的 Semaphore.
比如说我有服务a 和 服务b服务a 依赖于 服务b. 现在又请求到 a 了那么信号量不会去创建独立的线程而是去使用你原本处理请求的线程直接去调用 Feign 客户端那他是怎么做到隔离的呢他维持了一个计数器每次请求来了都做一个判断判断计数器里还有没有.
比如计数器总量是 10每进入一个请求计数器都会减一请求处理完了都会加一. 如果当有 10 个请求同时来访问的的时候那么10 个信号都被取完了此时如果再来新的请求就会直接拒绝因此也能起到故障隔离的作用. 优点 1. 轻量级没有额外开销实际上就是给线程池做了一个弥补因为他只是一个计数器不需要开启线程. 缺点 1. 不支持主动超时请求来了以后只是判断一下信号量有没有如果就给你分配一个但是信号量就不受控制了没法中途停掉只能依赖于 Feign 本身的超时时间所有不能做主动超时.
2. 不支持异步调用都没有独立的线程更不用提异步调用了. 适用场景 1. 高频调用高扇出因为 信号量 开销低. 网关 就是一个高扇出的场景 他把请求路由到你的各个微服务当中扇出相当的庞大因此网关也基本上都是用的是 信号量模式也是 sentinel 为什么适用信号量模式的原因. 2.2、实现线程隔离舱壁模式
在 Sentinel 控制台中添加先流规则时可以选择两种阈值类型
QPS每秒请求数之前演示过了.线程数该资源能使用的 tomcat 线程数的最大值. 通过限制线程数实现舱壁模式. 这里通过一个案例演示给 UserClient 的查询用户接口设置流控规则线程数不能超过 2. 由于前面已经配置 FeignClient 整合 Sentinel访问查询订单资源就可以在 Sentinel 中看到如下远程调用资源. a添加流控规则 b使用 JMeter 进行测试 c分析结果
在结果树中可以看到所有请求成功了这是因为我们基于 Feign 整合了 Sentinel 保护机制而保护的策略就是“打印异常日志返回空对象”.
可以看到前面几个请求时成功返回信息而后面的请求都返回的是空对象是因为触发了 Sentinel 的刚刚配置的流控机制. 也可以在 IDEA 上看到日志的打印 三、熔断降级 3.1、什么是熔断降级
熔断降级就是通过一个短路器取统计服务调用的时候 “异常比例、慢调用比例、异常数量”比如说统计的是异常比例那么如果异常比例过高触发了阈值就会熔断该服务这样就把故障的服务隔离开了.
这就像是古代的武侠人士手被毒蛇咬了赶紧手起刀落把手砍断防止毒扩散到全身但是这把手砍了算不了什么本事啊能接回来才是真本事.
而 Sentinel 就可以在服务恢复时让熔断器放行访问该服务的请求.
具体的熔断器有以下三种状态 3.2、熔断策略——慢调用
慢调用就指看你的响应时间如果过长超过了指定的时间那么就认为你这个请求的很慢占用额外资源会拖慢整个服务.
因此如果慢调用的比例达到阈值也就是说每次服务调用你都很慢那就会触发熔断.
在 Sentinel 的控制台中可有新增降级规则这里就描述了何时触发熔断例如 解读RTResponseTIme 响应时间超过 500ms 就是慢调用统计最近 10000ms 内的请求如果慢调用的比例超过 0.5就会触发熔断熔断时常为 5s. 之后进入 half-open半打开状态放行一次请求做测试. 这里我用一个案例来演示给 UserClient 查询用户接口设置降级规则RT为 50ms统计时间 1s最小请求数量为 5失败阈值比例为 0.4熔断时长为 5s. 注意这里为了触发慢调用规则我修改了 UserService 中的业务增加业务耗时. a在 Sentinel 上给远程调用添加降级规则
在簇点链路中即可配置 规则如下 b在浏览器中连续刷新分析结果
快速刷新几次之后就可以看到已经发生熔断触发降级策略也就是返回空用户信息. 随后过 5 秒后在发送一次请求就会发现进入 half-open 模式给你一次测试的机会. 3.3、熔断策略——异常比例、异常数
异常比例就是统计在指定之间内调用的次数到达指定的请求数并且出现的异常超过设置的比例那么就会触发熔断.
异常数和异常比例差不多这里就不演示了顾名思义就是统计指定时间内调用的次数到达指定请求数并且超过异常数阈值就会触发熔断.
例如 解读统计最近 1000 ms 内请求如果请求量超过 10 次且异常比例不低于 0.5则触发熔断熔断的时间为 5s. 这里我用一个案例来演示 异常比例给 UserClient的查询用户接口设置降级规则统计时间为 1 秒最小请求数量为 5 失败阈值比例为 0.4 熔断时长为 5 s 注意为了触发异常统计我修改了 UserService 中的业务抛出异常. a在 Sentinel 上给远程调用添加降级规则 b在浏览器中连续刷新分析结果
连续刷新 5 次就可以观察到触发熔断. 5 秒后恢复这里需要在换成 /order/101 的请求这样远程调用的也是获取 id 1 的用户否则继续使用 /order/102 请求远程调用 id 2 的用户会继续引发异常而当前还处于 half-open 状态就有又回到 open 熔断状态了.
