【Dubbo】过滤器及实现

左手的ㄟ右手 2023-01-19 08:06 57阅读 0赞

主要内容 ：

*  Dubbo 过滤器概述 ；
 *  过滤器链初始化的实现原理 ；
 *  服务提供者过滤器的实现 ；
 *  消费者过滤器的实现 。

首先介绍 Dubbo 过滤器的总体概况 ， 包括如何配置和使用一些框架自定义的规则约束,整个过滤器接口的总体结构 ， Dubbo 框架中内置过滤器的不同用途 ； 然后介绍众多的过滤器是如何初始化成一个过滤器链的 ； 最后 ， 由于有的过滤器会在服务提供者端生效 ， 有的会在消费者端生效 ， 因此我们会分为服务提供者和消费者两端来分别介绍各端的过滤器的实现原理 。

# 1 Dubbo 过滤器概述 #

做过 Java Web 开发的读者对过滤器应该都不会陌生 , Dubbo 中的过滤器和 Web 应用中的过滤器的概念是一样的 ， 提供了在服务调用前后插入自定义逻辑的途径 。 过滤器是整个 Dubbo 框架中非常重要的组成部分 ， Dubbo 中有很多功能都是基于过滤器扩展而来的 。 过滤器提供了服务提供者和消费者调用过程的拦截 ， 即每次执行 RPC 调用的时候 ， 对应的过滤器都会生效 。 虽然过滤器的功能强大 ， 但由于每次调用时都会执行 ， 因此在使用的时候需要注意它对性能的影响

## 1.1 过滤器的使用 ##

我们知道 Dubbo 中巳经有很多内置的过滤器 ， 并且大多数都是默认启用的 ， 如 ContextFiltero对于自行扩展的过滤器 ， 要如何启用呢 ？ 一种方式是使用妙 Activate 注解默认启用 ； 另一种方式是在配置文件中配置 ， 下面是官方文档中的配置

<dubbo:reference filter="xxx , yyy" />
    < ! -- 消费方调用过程默认拦截器 ， 将拦截所有 reference -->
    <dubbo:consumer filter="xxx,yyy"/>
    
    <dubbo:service filter="xxx , yyy" />
    
    <dubbo:provider filter="xxx , yyy"/>

以上就是常见的配置方式 ， 下面我们来了解一下配置上的一些 “ 潜规则 ” ：

*  （1） 过滤器顺序 。
    
     *  用户自定义的过滤器的顺序默认会在框架内置过滤器之后 ， 我们可以使用 filter=“xxx,default” 这种配置方式让自定义的过滤器顺序靠前 。
     *  我们在配置 filter= ” xxx,yyy ” 时 ， 写在前面的 xxx 会比 yyy 的顺序要靠前 。
 *  （2） 剔除过滤器 。 对于一些默认的过滤器或自动激活的过滤器 ， 有些方法不想使用这些过滤器 ， 则可以使用加过滤器名称来过滤 ， 如 filter="-xxFilter" 会让 xxFilter 不生效 。 如果不想使用所有默认启用的过滤器 ， 则可以配置 filter="-defaulf 来进行剔除 。
 *  （3） 过滤器的叠加 。 如果服务提供者 、 消费者端都配置了过滤器 ， 则两边的过滤器不会互相覆盖 ， 而是互相叠加 ， 都会生效 。 如果需要覆盖 ， 则可以在消费方使用气 ” 的方式剔除对应的过滤器 。

## 1.2 过滤器的总体结构 ##

在了解过滤器的使用方式后 ， 我们先从 “ 上帝视角 ” 看一下接口关系  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]  
从图可以看到所有的内置过滤器中除了 CompatibleFilter 特别突出 ， 只继承了 Filter接口 ， 即不会被默认激活 ， 其他的内置过滤器都使用了 @Activate 注解 ， 即默认被激活 。 Filter接口上有也 SPI 注解 ， 说明过滤器是一个扩展点 ， 用户可以基于这个扩展点接口实现自己的过滤器 。 所有的过滤器会被分为消费者和服务提供者两种类型 ， 消费者类型的过滤器只会在服务引用时被加入 Invoker, 服务提供者类型的过滤器只会在服务暴露的时候被加入对应的 Invoker 。

MonitorFilter 比较特殊 ， 它会同时在暴露和引用时被加入 Invoker o 具体的过滤器加入 Invoker的实现原理会在 2 节讲解 。  
我们来了解一下每个过滤器的作用 ， 如表所示  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 1]

每个过滤器的使用方不一样 ， 有的是服务提供者使用 ， 有的是消费者使用 。 Dubbo 是如何保证服务提供者不会使用消费者的过滤器的呢 ？ 答案就在 @Activate 注解上 ， 该注解可以设置过滤器激活的条件和顺序 ， 如 @Activate (group = Constants. PROVIDER, order = -110000) 表示在服务提供端扩展点实现才有效 ， 并且过滤器的顺序是 -110000

# 2 过滤器链初始化的实现原理 #

这么多默认的过滤器实现类都会在扩展点初始化的时候进行加载 、 排序等 ， 这部分的实现原理在 Dubbo 扩展点加载机制已经讲解过 。 使用过 Filter 的读者都知道 ， 所有的 Filter 会连接成一个过滤器链 ， 每个请求都会经过整个链路中的每一个 Filter。 那么这个过滤器链在 Dubbo 框架中是如何组装起来的呢 ？

我们在前面的讲解己经了解过 ， 服务的暴露与引用会使用 Protocol 层 ， 而 ProtocolFilterWrapper包装类则实现了过滤器链的组装 。 在服务的暴露与引用过程中 ， 会使用 ProtocolFilterWrapper\#buildInvokerChain 方法组装整个过滤器链

*服务的暴露与引用过程*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 2]  
然后我们来关注一下 buildlnvokerChain 方法是如何构造调用链的 ， 总的来说可以分为两步 ：

*  (1) 获取并遍历所有过滤器 。 通过 ExtensionLoader\#getActivateExtension 方法获取所有的过滤器并遍历 。
 *  (2) 使用装饰器模式 ， 增强原有 Invoker, 组装过滤器链 。 使用装饰器模式 ， 像俄罗斯套娃一样 ， 把过滤器一个又一个地 “ 套 ” 到 Invoker

*构造调用链源码*![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 3]

源码中为什么要倒排遍历呢 ？ 因为是通过从里到外构造匿名类的方式构造 Invoker 的 ， 所以只有倒排 ， 最外层的 Invoker 才能是第一个过滤器 。 我们来看一个例子 ：假设有过滤器 A 、 B 、 C 和 Invoker, 会按照 C 、 B 、 A 倒序遍历 ， 过滤器链构建顺序为 ：C — Invoker, B — C — Invoker, A — B — C — Invoker 。 最终调用时的顺序就会变为 A 是第一个过滤器 。

上面已经介绍了整个过滤器链在框架中组装的实现原理 ， 下面针对每个过滤器的实现原理进行讲解 。 把过滤器分为服务提供者端和消费者端两大类分别进行讲解 。

# 3 服务提供者过滤器的实现原理 #

在上表中 ， @Activate 注解上可以设置 group 属性 ， 从而设定某些过滤器只有在服务提供者端才生效 。 本节将详细介绍每一个在服务提供者端生效的过滤器 ， 共 8 个 。 服务提供者端的过滤器数量明显比消费者端多 。

## 3.1 AccessLogFilter 的实现原理 ##

**1. AccessLogFilter 的使用**

AccessLogFilter 是一个日志过滤器 ， 如果想记录服务每一次的请求日志 ， 则可以开启这个过滤器 。 虽然 AccessLogFilter 有旧 Activate 注解 ， 默认会被激活 ， 但还是需要手动配置来开启日志的打印 。 我们有两种方式来配置开启 AccessLogFilter

*AccessLogFilter 配置示例*  
![在这里插入图片描述][20210508205433229.png]  
我们设置将日志输出到应用本身的日志组件 （ 如 log4j 、 logback 等 ） 时 ， 可以配置 accesslog的值为 true 或 defaulto 如果想输出到指定路径的文件 ， 则可以直接设置 accesslog 的值作为文件路径 。

**2. AccessLogFilter 的实现**

AccessLogFilter 的实现步骤比较简短 ， 主要分为构造方法和 invoke 方法两大逻辑 。 在AccessLogFilter 的构造方法中会加锁并初始化一个定时线程池 ScheduledThreadPool 该线程池只有在指定了输出的 log 文件时才会用到 , ScheduledThreadPool 中的线程会定时把队列中的日志数据写入文件 。 在构造方法中主要是初始化线程池,而打印日志的逻辑主要在 invoke 方法中 ，其逻辑如下 ：

*  （1） 获取参数 。 获取上下文 、 接口名 、 版本 、 分组信息等参数 ， 用于日志的构建 。
 *  （2） 构建日志字符串 。 根据步骤 （ 1 ） 中的数据开始组装日志 ， 最终会得到一个日志字符串 ， 类似于\[2019-01-15 20:13:58\] 192.168.1.17:20881 -> 192.168.1.17:20882 - com.test.demo.Demo.Service testFunction （ java . lang.String ） \[null\]
 *  （3） 日志打印 。 如果用户配置了使用应用本身的日志组件 ， 则直接通过封装的LoggerFactory 打印日志 ； 如果用户配置了日志要输出到自定义的文件中 ， 则会把日志加入一个 ConcurrentMap<String, ConcurrentHashSet<String>> 中暂存 ， key 是自定义的 accesslog 值（ 如 accesslogicustom-access.log ” ） ， value 就是对应的日志集合 。 后续等待定时线程不断遍历整个 Map, 把日志写入对应的文件 。

这里有两个问题需要注意 ， 首先由于 Set 集合是无序的 ， 因此日志输出到文件也是无序的 ；其次由于是异步刷盘 ， 突然宕机会导致一小部分日志丢失 。

## 3.2 ExecuteLimitFilter 的实现原理 ##

ExecuteLimitFilter 用于限制每个服务中每个方法的最大并发数 ， 有接口级别和方法级别的配置方式 。 我们先看看官方文档中是如何配置的  
![在这里插入图片描述][202105082054581.png]  
如果不设置 ， 则默认不做限制 ； 如果设置了小于等于 0 的数值 ， 那么也会不做任何限制 。其实现原理是 ： 在框架中使用一个 ConcurrentMap 缓存了并发数的计数器 。 为每个请求 URL生成一个 Identity String, 并以此为 key ； 再以每个 IdentityString 生成一个 RpcStatus 对象 ， 并以此为 value 。 RpcStatus 对象用于记录对应的并发数 。 在过滤器中 ， 会以 try-catch-finally 的形式调用过滤器链的下一个节点 。 因此 ， 在开始调用之前 ， 会通过 URL 获得 RpcStatus 对象 ， 把对象中的并发数计数器原子+1 ， 在 finally 中再将原子- 1 。 只要在计数器 +1 的时候 ， 发现当前计数比设置的最大并发数大时 ， 就会抛出异常 ， 提示己经超过最大并发数 ， 请求就会被终止并直接返回 。

## 3.3 ClassLoaderFilter 的实现原理 ##

如果读者对 Java 的类加载机制不清楚的话 ， 那么会感觉 ClassLoaderFilter 过滤器不好理解 。ClassLoaderFilter 主要的工作是 ： 切换当前工作线程的类加载器到接口的类加载器 ， 以便和接口的类加载器的上下文一起工作 。 我们先来看一下 ClassLoaderFilter 的源码 ， 非常简短

*ClassLoaderFilter 源码*  
![在这里插入图片描述][20210508205521255.png]  
代码很好理解 ， 就是临时切换了一下上下文类加载器 。 为什么要这么做呢 ？ 如果要实现违反双亲委派模型来查找Class, 那么通常会使用上下文类加载器 ( ContextClassLoader) 。 当前框架线程的类加载器可能和 Invoker 接口的类加载器不是同一个 ， 而当前框架线程中又需要获取 Invoker 的类加载器中的一些 Class, 为 了避免出现 ClassNotFoundException, 此时只需要使用 Thread . currentThread( ) .getContextClassLoader( ) 就可以获取 Invoker 的类加载器 ， 进而获得这个类加载器中的 Class

常见的使用例子有 DubboProtocol\#optimizeSerialization 方法 ， 会根据 Invoker 中配置的optimizer 参数获取扩展的自定义序列化处理类 ， 这些外部引入的序列化类在框架的类加载器中肯定没有 ， 因此需要使用 Invoker 的类加载器获取对应的类 。

## 3.4 ContextFilter 的实现原理 ##

ContextFilter 主要记录每个请求的调用上下文 。 每个调用都有可能产生很多中间临时信息 ，我们不可能要求在每个接口上都加一个上下文的参数 ， 然后一路往下传 。 通常做法都是放在ThreadLocal 中 ， 作为一个全局参数 ， 当前线程中的任何一个地方都可以直接读/写上下文信息 。

ContextFilter 就是统一在过滤器中处理请求的上下文信息 ， 它为每个请求维护一个 RpcContext 对象 ， 该对象中维护两个 InternalThreadLocal (它是优化过的 ThreadLocal, 具体可以搜索 Netty 的 InternalThreadLocal 做了什么优化) ， 分别记录 local 和 server 的上下文 。 每次收到或发起 RPC 调用的时候 ， 上下文信息都会发生改变 。 例如 ： A 调用 B, B 调用 C 。 当 A 调用 B 且 B 还未调用 C 时 ， RpcContext 中保存 A 调用 B 的上下文 ； 当 B 开始调用 C 的时候 ，RpcContext 中保存 B 调用 C 的上下文 。 发起调用时候的上下文是由 ConsumerContextFilter 实现的 ， 这个是消费者端的过滤器。

ContextFilter 的主要逻辑如下 ：

*  (1) 清除异步属性 。 防止异步属性传到过滤器链的下一个环节 。
 *  (2) 设置当前请求的上下文 ， 如 Invoker 信息 、 地址信息 、 端口信息等 。 如果前面的过滤器已经对上下文设置了一些附件信息 ( attachments 是一个 Map, 里面可以保存各种 key-value数据) ， 则和 Invoker 的附件信息合并 。
 *  (3) 调用过滤器链的下一个节点 。
 *  (4) 清除上下文信息 。 对于异步调用的场景 ， 即使是同一个线程 ， 处理不同的请求也会创建一个新的 RpcContext 对象 。 因此调用完成后 ， 需要清理对应的上下文信息 。

## 3.5 ExceptionFilter 的实现原理 ##

光看 ExceptionFilter 很容易会认为它和我们平时写业务时统一处理异常的过滤器一样 。 它的关注点不在于捕获异常 ， 而是为了找到那些返回的自定义异常 ， 但异常类可能不存在于消费者端 ， 从而防止消费者端序列化失败 。 对于所有没有声明 Unchecked 的方法抛出的异常 ，ExceptionFilter 会把未引入的异常包装到 RuntimeException 中 ， 并把异常原因字符串化后返回 因此 ， ExceptionFilter 的逻辑都在 onResponse 方法中 。ExceptionFilter 过滤器会打印出 ERROR 级别的错误日志 ， 但并不会处理泛化调用 ， 即 Invoker的接口是 GenericService

下面我们来看一下 onResponse 方法中是如何处理异常的 ：

*  (1) 判断是否是泛化调用 。 如果是泛化调用则直接不处理了 。
 *  (2) 直接抛出一些异常 。 如果异常是 Java 自带异常 ， 并且是必须显式使用 try-catch 来捕获的异常 ， 则直接抛出 。 如果异常在 Invoker 的签名中出现 ， 则直接抛出异常 ， 并打印 error log。如果异常类和接口类在同一个 jar 包中 ， 则直接抛出异常 ； 如果是 JDK 中的异常 ， 则直接抛出 ；如果是 Dubb 。 中定义的异常 ， 则直接抛出 。
 *  (3) 处理在步骤 (2) 中无法处理的异常 。 把异常转换为字符串 ， 并包装成一个 RuntimeException放入 RpcResult 中返回 。

## 3.6 TimeoutFilter 的实现原理 ##

TimeoutFilter 主要是日志类型的过滤器 ， 它会记录每个 Invoker 的调用时间 ， 如果超过了接口设置的 timeout 值 ， 则会打印一条警告日志 ， 并不会干扰业务的正常运行 ，

*TimeoutFilter 源码*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 4]

## 3.7 TokenFilter 的实现原理 ##

在 Dubbo 中 ， 如果某些服务提供者不想让消费者绕过注册中心直连自己 ， 则可以使用令牌验证 。 总体的工作原理是 ， 服务提供者在发布自己的服务时会生成令牌 ， 与服务一起注册到注册中心 。 消费者必须通过注册中心才能获取有令牌的服务提供者的 URL 。 TokenFilter 是在服务提供者端生效的过滤器 ， 它的工作就是对请求的令牌做校验 。 我们首先来看一下开启令牌校验的配置方式

*开启令牌校验的配置方式*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 5]  
我们来看一下整个令牌的工作流程 ：

*  (1) 消费者从注册中心获得服务提供者包含令牌的 URL
 *  (2) 消费者 RPC 调用设置令牌 。 具体是在 Rpclnvocation 的构造方法中 ， 把服务提供者的令牌设置到附件 (attachments) 中一起请求服务提供者 。
 *  (3) 服务提供者认证令牌 。

这就是 TokenFilter 所做的工作 。TokenFilter 的工作原理很简单 ， 收到请求后 ， 首先检查这个暴露出去的服务是否有令牌信息 。 如果有 ， 则获取请求中的令牌 ， 如果和接口的令牌匹配 ， 则认证通过 ， 否则认证失败并抛出异常 。

## 3.8 TpsLimitFilter 的实现原理 ##

TpsLimitFilter 主要用于服务提供者端的限流 。 我们会发现在 org. apache, dubbo. rpc . Filter这个 SPI 配置文件中 ， 并没有 TpsLimitFilter 的配置 ， 因此如果需要使用 ， 则用户要自己添加对应的配置 。 TpsLimitFilter 的限流是基于令牌的 ， 即一个时间段内只分配 N 个令牌 ， 每个请求过来都会消耗一个令牌 ， 耗完即止 ， 后面再来的请求都会被拒绝 。 限流对象的维度支持分组 、 版本和接口级别 ， 默认通过 interface + group + version 作为唯一标识来判断是否超过最大值 。 我们先看一下如何配置 ：  
![在这里插入图片描述][20210508205808613.png]  
具体的实现逻辑主要关注 DefaultTPSLimiter\#isAllowable, 会用这个方法判断是否触发限流 ， 如果不触发就直接通过了 。 isAllowable 方法的逻辑如下 ：

*  （1） 获取 URL 中的参数 ， 包含每次发放的令牌数 、 令牌刷新时间间隔
 *  （2） 如果设置了每次发放的令牌数则开始限流校验 。 DefaultTPSLimiter 内部用一个  
    ConcurrentMap 缓存每个接 口的令牌数 ， key 是 interface + group + version, value 是一个 Statitem对象 ， 它包装了令牌刷新时间间隔 、 每次发放的令牌数等属性 。 首先判断上次发放令牌的时间点到现在是否超过时间间隔了 ， 如果超过了就重新发放令牌 ， 之前没用完的不会叠加 ， 而是直接覆盖 。 然后 ， 通过 CAS 的方式 -1 令牌 ， 减掉后令牌数如果小于 0 则会触发限流 。

# 4 消费者过滤器的实现原理 #

## 4.1 ActiveLimitFilter 的实现原理 ##

和服务提供者端的 ExecuteLimitFilter 相似 ， ActiveLimitFilter 是消费者端的过滤器 ， 限制的是客户端的并发数 。 官方文档中使用的配置如下 ：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 6]  
如果 <dubbo:service> 和 <dubbo:reference> 都配了 actives, 则 <dubbo : reference> 优先 。 如果设置了 actives 小于等于 0, 则不做并发限制 。 下面我们看一下 ActiveLimitFilter 的具体实现逻辑 ：

*  (1) 获取参数 。 获取方法名 、 最大并发数等参数 ， 为下面的逻辑做准备 。
 *  (2) 如果达到限流阈值 ， 和服务提供者端的逻辑并不一样 ， 并不是直接抛出异常 ， 而是先等待直到超时 ， 因为请求是有 timeout 属性的 。 当并发数达到阈值时 ， 会先加锁抢占当前接口的RpcStatus 对象 ， 然后通过 wait 方法进行等待 。 此时会有两种结果 ， 第一种是某个 Invoker 在调用结束后 ， 并发把计数器原子 -1 并触发一个 notify, 会有一个在 wait 状态的线程被唤醒并继续执行逻辑 。 第二种是 wait 等待超时都没有被唤醒 ， 此时直接抛出异常

*ActiveLimitFilter 源码*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 7]

*  (3) 如果满足调用阈值 ， 则直接进行调用 ， 成功或失败都会原子 -1 对应并发计数 。 最后会唤醒一个等待中的线程 。

细心的读者肯定已经发现 ， 这种方式的限流是有问题的 。 在大并发场景下容易出现超过限流阈值的情况 。 例如 ： 当 10 个线程同时获取当前并发数时 ， 都发现还差 1 个计数到达阈值 ， 此时 10 个线程都符合要求并往下执行 ， 即超了 9 个限额 。 不过这个问题在新版本中己经修复 。

## 4.2 ConsumerContextFilter 的实现原理 ##

ConsumerContextFilter 会和 ContextFilter 配合使用 。 因为在微服务环境中 ， 有很多链式调用 ，如 A-B-C-D 。 收到请求时 ， 当前节点可以被看作一个服务提供者 ， 由 ContextFilter 设置上下文 。 当发起请求到下一个服务时 ， 当前服务变为一个消费者 ， 由 ConsumerContextFilter 设置上下文 。 其工作逻辑主要如下 ：

*  (1) 设置当前请求上下文 ， 如 Invoker 信息 、 地址信息 、 端口信息等 。
 *  (2) 服务调用 。 清除 Response 下文 ， 然后继续调用过滤器链的下一个节点 。
 *  (3) 清除上下文信息 。 每次服务调用完成 ， 都会把附件上下文清除 ， 如隐式传参 。

## 4.3 DeprecatedFilter 的实现原理 ##

DeprecatedFilter 会检查所有调用 ， 如果方法已经通过 dubbo:parameter 设置了 deprecated=true,则会打印一段 ERROR 级别的日志 。 这个错误日志只会打印一次 ， 判断是否打印过的 key 维度是 ： 接口名 + 方法名 。 打印过的 key 都会被加入一个 Set 中保存 ， 后续就不会再打印了 ，

*DeprecatedFilter 源码*  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 8]

## 4.4 FutureFilter 的实现原理 ##

FutureFilter 主要实现框架在调用前后出现异常时 ， 触发调用用户配置的回调方法 ， 如以下配置  
![在这里插入图片描述][20210508210012421.png]  
调用前的回调实现就很简单了 ， 由于整个逻辑是在过滤器链中执行的 ， FutureFilter 在执行下一个节点的 invoke 方法前调用 onInvoke 回调方法就能实现调用前的回调 。 方法在服务引用初始化的时候就会把配置文件中的回调方法保存到 ConsumerMethodModel 中 ， 后续使用的时候,直接取出来就可以调用 。 不过需要注意的是 ， onInvoke 回调只会对异步调用有效 。

当调用有返回结果的时候 ， 会执行 FutureFilter\#onResponse 的逻辑 。 对于同步调用的方法 ， 则直接判断返回的 result 是否有异常 ， 有异常则同步调用 onthrow 回调方法 ， 没有异常则同步调用 onretum 回调方法 。 对于异步调用 ， 会通过 CompletableFuture 的 thenApply 方法来执行onthrow 或 onretum 的回调 。 CompletableFuture 是 JDK8 中的新特性

# 5 小结 #

首先介绍了 Dubbo 框架中所有过滤器的总体大图 ， 讲解了每个过滤器的作用及归属 ， 过滤器分为服务提供者端生效和消费者端生效两种 ， 其中服务提供者端有 11 种过滤器 ， 消费者端有 5 种过滤器 。 有一个特殊的 Monitor 过滤器在两端都会生效 ， 还有一个 CompatibleFilter 过滤器并没有默认启用 。 然后 ， 我们介绍了整个过滤器链串联起来的原理 ， 框架在ProtocolFilterWrapper 中为每个 Invoker 包上了一层又一层的过滤器 ， 最终形成一个过滤器链 。最后 ， 我们分别详细介绍了服务提供者 、 消费者端的每个过滤器的实现原理

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]: /images/20221021/703a166cb4c04e18b9f55aa1a189aef8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 1]: /images/20221021/d74d47d75c6d471c8255fa228793c220.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 2]: /images/20221021/44184b5af303467b827bedad5ea5be74.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 3]: /images/20221021/c6068b7bbca54814ae6dab6ef0315df9.png
[20210508205433229.png]: /images/20221021/61ed3f78fa064618921a5152fab10370.png
[202105082054581.png]: /images/20221021/c8807250939340fab5605ccd259f3bb6.png
[20210508205521255.png]: /images/20221021/15a1199106514b1a8c28506e5e4f10a7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 4]: /images/20221021/f47ac737b3ba48c080d47f6ea43d5ec4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 5]: /images/20221021/1ade72b3f50b450ca13aa2b5dfd0625a.png
[20210508205808613.png]: /images/20221021/0f5f858e6d344cc0ab40ebdeb71bde84.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 6]: /images/20221021/9dd92e7be03545dea2a117265fcfbdbd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 7]: /images/20221021/aa4c2b4ea0e54926a6130cdbcb89116b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 8]: /images/20221021/311db33fc7804d86b133cff51bb8f29a.png
[20210508210012421.png]: /images/20221021/00896c14f75c442891e0a5f2274c3929.png