Java最全Sentinel Dubbo 适配器看限流与熔断(实战思考篇)(2)，StringBoot编程式事务与声明式事务

最新推荐文章于 2024-07-27 16:36:06 发布

2401_84006757

最新推荐文章于 2024-07-27 16:36:06 发布

阅读量988

点赞数 19

分类专栏：程序员文章标签： java 面试学习

本文链接：https://blog.csdn.net/2401_84006757/article/details/138665802

版权

程序员专栏收录该内容

196 篇文章 0 订阅

订阅专栏

总结

如果你选择了IT行业并坚定的走下去，这个方向肯定是没有一丝问题的，这是个高薪行业，但是高薪是凭自己的努力学习获取来的，这次我把P8大佬用过的一些学习笔记（pdf）都整理在本文中了

《Java中高级核心知识全面解析》

小米商场项目实战，别再担心面试没有实战项目：

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

在这里插入图片描述

消费者会维护一个服务提供者列表，然后再发一起一个服务调用的时候会首先根据负载均衡算法从中选择一个服务提供者，然后发起 RPC 调用，在请求真实发送之前会依次通过客户端设置的过滤器链(Filter)，然后经过网络传输到到达服务提供者，并执行完服务提供者端的 Filter，最后进入到业务逻辑执行并返回结果。

Sentinel 与 Dubbo 的整合就是利用了 Dubbo 的 Filter 机制，为 Dubbo 提供对应的过滤器，无缝实现限流、熔断等功能，做到业务无感知，即业务代码无需使用 Sentinel 相关的 API。

接下来请大家带着在 Dubbo 中如何使用限流、熔断方面来看官方给出的解决方案。

思考题：在看接下来的内容之前，建议大家稍作停顿，思考一下，在服务调用模型中，限流、熔断通常在哪个端做比较合适。

1、从消费端来看限流与熔断

在这里插入图片描述从消费端的视角，虽然提供了服务端的负载均衡，但从客户端不管是向192.168.1.3还是向192.168.1.4发送RPC调用，都会经过同一个 Sentinel Dubbo Filter。这个看似简单明了，但这是我们接下来思考的最基本最核心的点。

我们先来看看官方提供的 Dubbo 适配器的核心实现：

SentinelDubboConsumerFilter#invoke

在这里插入图片描述

消费端这边使用到了两个资源名称，一个是接口级别，例如 com.demo.service.UserService，另外一是方法级别，例如 com.demo.servcie.UserServce#findUser(Ljava.lang.String)。

定义了两个资源后，Sentinel 会使用滑动窗口机制，为上述两个资源收集实时的调用信息，为后续的限流、熔断提供数据依据。

限流规则是依附于具体某一个项目的，例如如下图所示：

在这里插入图片描述限流、熔断都是根据资源级别，如果需要对消费端的调用进行限流的话，就需要为这两个资源配置对应的限流规则，如果不配置则默认通过，表示不限流。

1.1 服务调用端(消费方)是否需要配置限流规则

在 dubbo 的服务调用场景中，在消费端设置限流的规则的话，这个调用链是针对整个集群所有服务提供者的，例如当前集群中包含3个服务提供者，每个服务提供者用于1000tps的服务能力，那消费端的限流，应该配置的限流TPS应该为3000tps，如果设置为1000tps，则无法完整的利用服务端的能力，基于这样的情况，通常消费端无需配置限流规则。

那是不是说消费端就没必要配置限流规则呢？其实也不是，有如下这个场景，例如调用第三方外部的计费类服务接口，对方通常为特定的账户等级设置对应的TPS上限，如果超过该调用频率就会抛出错误，这种情况还是需要设置限流规则，确保消费端以不超过要求进行调用，避免业务异常。

1.2 服务调用端(消费方)是否需要配置熔断

引入熔断的目的是避免服务端单节点响应慢而导致这个服务不稳定，例如示例中有3个服务提供者，如果192.168.1.3的服务提供者由于触发了BUG导致响应时间大大增加，导致发往该服务提供者的请求大概率超时，在这样的情况下希望在接下来某段时间内消费方发往这这个服务提供者的请求快速熔断降级，返回错误，由客户端重试其他服务提供者。其实现效果如下：

在这里插入图片描述

当前的 Sentinel 默认是否能满足上述的需求呢？

我们以 Sentinel 基于异常比例熔断策略来进行阐述，如果资源的调用异常比例超过一定值是会触发降级熔断，抛出 DegradeException 异常。

由于总共只有三个服务提供者，其中发往192.168.1.3的请求大概率会由于超时失败，则异常比例会超过设置的熔断降级规则，会触发降级，造成的效果是整个服务调用都会发送熔断降级，即调用192.168.1.4,5两个请求都不会被熔断，造成整个服务调用不可用，与期望不一致。即还是会出现一个节点的不稳定而导致整个服务不稳定的情况。

其造成的根本原因是因为其资源的定义并没有包含服务提供者的信息，改进的初步方案：

在过滤器中再定义一个资源，加上服务提供的IP与端口号，例如 SphU.entry(“com.d.s.UserService@ip:port”)，对单个服务提供者进行单独收集调用信息，并且需要提供一可配置的项，用来标记该类型的资源在做熔断判断可使用某一个资源的配置，例如配置为 com.d.s.UserService，表示用这个配置规则来判断熔断。
在熔断规则判断的时候，该资源使用被引用资源的熔断规则进行判断。

最后来解答一下，熔断规则通常只需要配置在调用方即可。

2、从服务来看限流与熔断

由于服务端看限流与熔断就比较简单，因为服务端与客户端存在一个非常大的区别是客户端存在负载均衡机制，一个消费端对于同一资源来说，会调用多个服务提供者，而服务提供者对于一个资源来就是其自身，故限流规则，熔断规则都是针对个体，其复杂度降低。

为了知识体系的完备性，我们来看一下 Sentinel Dubbo 在服务端的适配器的实现。

SentinelDubboProviderFilter#invoke

在这里插入图片描述