Dubbo filter扩展

Posted 2023-03-15

参考技术A filter其实是一种责任链模式，每个filter只负责完成自己职责的部分，解除耦合，这种设计模式很利于扩展。
大家可能对Dubbo的filter不太熟悉，但是应该都写过Servlet的filter，让我们先来回顾一下Servlet的Filter：

我们重写doFilter，在chain.doFilter(request, response) 前后做一些切面的工作，比如防XSS攻击、CROS跨域请求处理、记录相关日志等，调用逻辑可以用下图来概括：

类似于Servlet中的filter，Dubbo也可以通过扩展filter来增强功能，Dubbo服务提供方和服务消费方均支持调用过程拦截，并且Dubbo 自身的大多功能均基于此扩展点实现，下面例举部分filter：
EchoFilter -> 用于provider的回声测试，检测服务是否正常
ContextFilter -> 用于provider接收RpcContext的参数
ConsumerContextFilter -> 用于consumer传递RpcContext的参数
ExecuteLimitFilter -> 用于provider的限流
ActiveLimitFilter -> 用于consumer的限流
ExceptionFilter -> 用于provider对异常进行封装
GenericFilter -> 用于provider的泛化调用，可用于集成通用服务测试框架或为其他语言调用服务提供Restful接口的支持
AccessLogFilter -> 用于provider 的access log记录
ClassLoaderFilter -> 用于provider切换当前的ClassLoader
MonitorFilter -> 用于dubbo monitor模块对consumer和provider进行监控

Dubbo filter的调用逻辑可以用下图来概括：

那么Dubbo是怎么将多个filter串起来的呢？
答案就位于ProtocolFilterWrapper这个类的buildInvokerChain方法。

看明白这里首先要理解Dubbo的SPI扩展点机制，List<Filter> filters = ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl(), key, group);这一行是获取Filter接口的所有被标注为@Activate的扩展点，然后基于回调让前一个filter调用后一个filter从而串成一个调用链，调用的先后顺序是由每个filter定义的order属性决定的（不声明默认为0），order值越小则调用优先级越高。

了解了Dubbo filter的作用和原理，那让我们来看看如何扩展：
Maven 项目结构：

src
  |-main
    |-java
      |-com
        |-xxx
           |-XxxFilter.java (实现Filter接口)

Dubbo自身的过滤器配置都放在resources/META-INF/dubbo/internal下，我们扩展的过滤器一版放在resources/META-INF/dubbo/下：
     |-resources
      |-META-INF
        |-dubbo
          |-com.alibaba.dubbo.rpc.Filter (纯文本文件，内容为：xxx=com.xxx.XxxFilter)

XxxFilter.java：

META-INF/dubbo/com.alibaba.dubbo.rpc.Filter：

xxx=com.xxx.XxxFilter

我司生产环境中利用Dubbo filter扩展来记录服务调用日志和服务调用链追踪。

1.服务调用日志记录：
服务调用日志记录分为provider日志和consumer日志两部分，provider日志记录的是当前工程作为provider的服务提供日志，consumer日志记录的是当前工程作为consumer的服务消费日志，以下是部分consumer日志内容：

日志会记录每一次调用的consumer的ip、端口、调用时间、provider的ip、端口、接口请求的时间、调用的方法、调用耗时、调用结果（成功或失败，失败则打印异常）、方法入参（可选）、返回值（可选）等。
由于每次调用的入参和返回值的内容比较多，所以方法入参和返回值是否打印都是可以配置的，filter会根据当前配置的日志等级去打印。

2.调用链追踪：
Dubbo Filter结合brave + zipkin实现RPC调用链追踪和梳理项目间的依赖关系，filter中用brave向zipkin服务器异步发送http请求（也可以用kafka），zipkin服务器对数据进行分析汇总，很容易分析出性能的瓶颈在哪，效果如下：

如果有人对这些具体实现感兴趣，笔者会开放源码。

最后提醒一点，filter的实现中不要写太耗时的方法，会影响性能。