文章目录

  • 前言
  • hystrix 使用
  • resilienc4j 使用
  • sentinel 使用
  • 对比
  • 总结


前言

在前面第6~13章中,我们分析了 Soul 网关核心功能“代理转发”的设计,并且以 Http 和 Dubbo 为切入点分析了其关键节点的底层实现。本来还剩下 Sofa 和 tars 代理的相关插件需要分析的,但是我发现它们在实现上和 Dubbo 代理的非常相似,因此这两个协议的代理就准备留给有兴趣的小伙伴自己去分析了。

不知道小伙伴还记得第六章、第七章所画的哪些图中,有一些粉红色的插件,这些插件不是代理转发所必须的插件,但它们在 Soul 中同样重要。我们知道一个应用服务仅仅是提供核心功能是无法满足企业级要求的,必须需要一些非功能性需求来确保服务的稳定性、扩展性和健壮性,而 Soul 天然就集成了一套丰富的插件来满足上面的需求。它们将是我们后面学习的内容,同时我们还是和之前学习代理转发流程一样,先学习如何使用,再学习其设计和代码实现。

本篇登场的主角是hystrix,resilienc4j,sentinel 插件,它们都是提供熔断的相关功能,我们接下来就先去学习一下如何使用它们,并将它们做一个简单的对比。

hystrix 使用

Soul 网关服务添加依赖,重启服务:

<!-- soul hystrix plugin start-->
<dependency>
    <groupId>org.dromara</groupId>
    <artifactId>soul-spring-boot-starter-plugin-hystrix</artifactId>
     <version>${last.version}</version>
</dependency>
<!-- soul hystrix plugin end-->

登录控制台,打开 hystrix 插件:

resilience4j 配置fallback sentinel resilience4j_java


配置 hystrix 选择器:

resilience4j 配置fallback sentinel resilience4j_java_02


配置 hystrix 规则:

resilience4j 配置fallback sentinel resilience4j_Java_03


上面有一点必须注意:callBackUrl 的接口必须在网关服务这边实现,也就是要用户自己在网关服务这边添加,不能是用户自己的服务接口。

先使用命令工具进行压测:ab -n1000 -c100 localhost:9195/http/order/findById?id=1

再通过 postman 请求:

resilience4j 配置fallback sentinel resilience4j_java_04

resilienc4j 使用

引入依赖:

<dependency>
      <groupId>org.dromara</groupId>
      <artifactId>soul-spring-boot-starter-plugin-resilience4j</artifactId>
       <version>${last.version}</version>
  </dependency>

登录控制台打开 resilienc4j 插件,同时配置选择器,这两部直接参考上面 hystrix 的即可,步骤几乎一模一样。这里主要贴一下 Rule 的配置:

resilience4j 配置fallback sentinel resilience4j_java_05


这里我把令牌调成了只有一个,刷新时间要 100s,所以只要多点几次 postman,即可触发熔断:

resilience4j 配置fallback sentinel resilience4j_spring_06

sentinel 使用

添加依赖:

<dependency>
    <groupId>org.dromara</groupId>
    <artifactId>soul-spring-boot-starter-plugin-sentinel</artifactId>
    <version>${last.version}</version>
</dependency>

参考 hystrix 步骤,打开 sentinel 插件,同时创建 Selector Data。

对测试接口创建 Rule:

resilience4j 配置fallback sentinel resilience4j_java_07

  • degrade count:熔断阈值(上面为了方便测试设置为1)。
  • whether to open the degrade:是否开启熔断(1或0)。
  • degrade type: 熔断策略,支持秒级 RT/秒级异常比例/分钟级异常数。
  • degrade window size:降级的时间,单位为 s。
  • control behavior: 流控效果(直接拒绝 / 排队等待 / 慢启动模式),不支持按调用关系限流。
  • grade count:限流阈值。
  • whether control behavior is enabled:是否开启流控(1或0)。
  • grade type:限流阈值类型,QPS 或线程数模式。

上面我设置了熔断窗口是10s并且只允许1个请求通过,所以直接快速多次点击 postman 发送请求即可:

resilience4j 配置fallback sentinel resilience4j_java_08

对比

最后给出一个阿里 Sentinel Githup 上关于三个熔断框架的功能的对比:

Sentinel

Hystrix

resilience4j

隔离策略

信号量隔离(并发控制)

线程池隔离/信号量隔离

信号量隔离

熔断降级策略

基于慢调用比例、异常比例、异常数

基于异常比例

基于异常比例、响应时间

实时统计实现

滑动窗口(LeapArray)

滑动窗口(基于 RxJava)

Ring Bit Buffer

动态规则配置

支持多种数据源

支持多种数据源

有限支持

扩展性

多个扩展点

插件的形式

接口的形式

基于注解的支持

支持

支持

支持

限流

基于 QPS,支持基于调用关系的限流

有限的支持

Rate Limiter

流量整形

支持预热模式与匀速排队控制效果

不支持

简单的 Rate Limiter 模式

系统自适应保护

支持

不支持

不支持

多语言支持

Java/Go/C++

Java

Java

Service Mesh 支持

支持 Envoy/Istio

不支持

不支持

控制台

提供开箱即用的控制台,可配置规则、实时监控、机器发现等

简单的监控查看

不提供控制台,可对接其它监控系统

总结

本篇文章简单的演示 hystrix,resilienc4j,sentinel 三个插件的使用,测试的用例都比较简单,主要是认识一下这三个插件各个配置项的使用,方便后面的源码分析,更加复杂的应用场景可能需要用户自行结合 Soul 官方文档和插件的官方文档进行进一步的探索。