朝花夕拾---dubbo源码分析

前言

该篇博客意在做dubbo启动调用流程做源码分析，采用先给出部分结论，然后推导出整个调用流程的过程

一  服务发布

dubbo服务的每个标记了@service的类和在xml配置中带有标签<dubbo:service>，均会被解析成ServiceBean,服务发布的故事就从serviceBean这个类开始

首先看一下serviceBean的类继承关系：

从类继承图中，我们发现了几个重要的接口：

serviceConfig       这个是和dubbo服务发布相关的

ApplicationListener    spring的事件相关

InitializingBean       初始化相关

当然最重要的就是ApplicationListener的监听方法了：

 以下是服务发布的几个重要路径：

ServiceBean#export();

     ServiceConfig#doExport()

              doExportUrlsFor1Protocol()

在doExportUrlsFor1Protocol这里就是服务发布的重点了

 以上截图就是dubbo在做服务发布的核心代码了，这里dubbo使用了动态代理(SPI)+装饰器模式，完整的构造了一个Invoker和Exporter

DUBBO的SPI：ExtensionLoader  通过加载指定路径下，配置的key-value形式的类。同时还支持代理和增强(Wrapper + 装饰)，有兴趣的同学可以认真研究一下dubbo的SPI机制，这里只做简单概括，比如里面2个最重要的代理对象：proxyFacotory,protocol,他们的源码分别截图如下：

proxyFactory:

protocol:

 从以上截图不难发现：protocol和proxyFactory的处理逻辑大体类似：通过url获取指定参数，如果为空，就使用默认值：然后通过ExtensionLoader加载从url中获取的对象

首先看一下通过proxyFactory获取的Invoker对象：

 想一下，为什么extName是javassist，获取到的ProxyFactory却是:StubProxyFactoryWrapper?按照之前说的SPI机制，应该获取的是：JavassistProxyFactory?

这是因为：在ExtensionLoader#createExtension时

 

 cachedWrapperClasses的写入是在读取指定路径的文件时写入的，通过判断加载的类是否有，包含相同接口的构造器做判断的：

 

这里真正干活的还是:JavassistProxyFactory

所以，真正构建Invoker的代码如下：

其实就是构建了一个AbstractProxyInvoker,其中的Wrapper简单的理解成一个包装类即可(这就是dubbo动态生成类的方式，其实没有什么多大的技术问题，只是觉得就是装X而已)，代码如下：

 

再来看看export过程：

 同样的，extName是registry,实际的加载类是:ProtocolListenerWrapper

 

 而ProtocolListenerWrapper里面包装的protocol是：ProtocolFilterWrapper,而ProtocolFilterWrapper里面包装的protocol是RegistryProtocol(真正干活的)

可以看下最终生成的Exporter的结构：

 

其中DubboExporter是在DubboProtocol类中构造的，还是和之前一样，通过装饰器，一层一层递进构造的：

至此，服务的发布已经完成，其中有些步骤跳跃可能稍微大一点，感兴趣的同学请自行本地调试 

二  服务调用

dubbo中每一个标记了@Reference域和在xml中配置了<dubbo:reference>的元素，均会被解析成一个ReferenceBean

首先，看一下ReferenceBean的类关系：

其中FactoryBean就是spring的工厂Bean，和ServiceBean类似，ReferenceBean也继承一个Config类，如上，服务调用的故事就从ReferenceConfig的#get()开始

ReferenceBean#getObject()

    ReferenceConfig#get()

         init();

相信使用过动态代理的同学都知道，使用动态代理的使用，通过代理对象，在自己的逻辑里面就可以"为所欲为"了。dubbo在服务调用的时候也是这么干的！

init方法就是创建代理的入口，方法比较长，咱们捡重点说，前面就是一些校验，判断，最主要的方法入口：

 创建代理需要一个map，看看这个map里面的信息如下：

 下面正式开启创建代理的过程，老规矩，忽略掉无关精要的代码，直接上干货：

 这个refprotocol就是在前面截图的那个Protocol$Adaptive代码，这里咱们为了方便调试，直接把代码替换一下：

 

 和服务发布过程一样，extName是registry，获取到的实例却是:ProtocolListenerWrapper(装饰器模式)

 大概装饰层级就是：

ProtocolListenerWrapper

   ProtocolFilterWrapper

      RegistryProtocol

 在RegistryProtocol是真正干活的地方：

 一路debug调试，最终返回到创建代理的代码入口：

在之前的服务发布过程中，我们已经帖出了proxyFactory的相关代码(dubbo这里做了动态加载，不利于调试，咱们做个替换)

替换后的代码如下：

现在将要进行真正的动态代理的创建过程：

 和其他的Adaptive一样，真正干活的是JavassistProxyFactory,使用StubProxyFactoryWrapper做装饰

真正干活的是JavassistProxyFactory

 

看到这里，熟悉动态代理的同学已经很熟悉了。真正的执行逻辑就在InvokerInvocationHandler里面了，在这个handler里面是不是为所欲为呢？

截图如下：

由截图可知，在InvokerInvocationHandler里面真正调用就是使用invoker调用逻辑

当真正调用时，一路dubug

 这个Invoker也是一个装饰器。咱们一步一步调试进入：

首先：MockClusterInvoker

 真正的调用又委托给了:FailoverClusterInvoker

 从以上代码注释中可以看出，FailoverClusterInvoker，通过负载均衡器选择"最优"的Invoker发起远程调用

这里选择了：RegistryDirectory$DeleteInvoker其实就是一个InvokerWrapper

 真正干活的是ListenerInvokerWrapper

 继续递进：调用ProtocolFilterWrapper

 最终来到了ProtocolFilterWrapper的匿名内部类：

把调用过程委托给了filter调用链路，至此，Invoker的使命完成了。相信更深的调用逻辑，通过分析Filter就能找到答案了

三  FailOverClusterInvoker选择Invoker过程既FilterChain调用链的组装

在第二节中，有分析服务发布调用过程，最红是委托给了Filter调用。我们在分析的时候，有意的忽略掉了部分调用细节，只是为了更好的梳理出整个调用链路。下面就分析一下在负载均衡器选择Invoker的详细逻辑

故事的开始当然是从FailoverClusterInvoker的invoke开始,FailoverClusterInvoker没有自己实现invoke，其父类AbstractClusterInvoker实现了：

寻找Invoker的时候委托给了RegistryDirectory：

 最终的Invoker寻找在RegistryDirectory里面维护的一个字段:methodInvokerMap里面查询即可

 查询到全量的数据之后，就通过负载均衡器选择，完成Invoker的选择

那RegistryDirectory的methodInvokerMap又是在什么时候获得调用方法和Invoker的对应关系的呢？

通过跟踪字段的调用来源

最终确认： RegistryProtocol#doRefer时会调用到如上方法里面，生成method和Invokers的对应关系

以上，将服务发布，服务调用的过程做了较为粗略和完整的说明

四 结论证明

在前言部分有说过，先给出部分结论：

1 所有被标记了@service和使用<dubbo:service>标记的元素，均会被spring解析成ServiceBean

2 所有被标记了@Reference和使用<dubbo:reference>的元素，均会被spring解析成ReferenceBean

这是怎么做到的呢？

在结合xml使用的时候，dubbo有引入DubboNamespaceHandler,该handler会解析相关的xml标签，完成如上功能：

而在springboot应用中，dubbo有引入：ServiceAnnotationBeanPostProcessor

该类是一个前置处理器，会扫描@service标记的类，通过构建BeanDefinitionBuilder完成ServiceBean的注册：

 同样的：springboot应用中引入了ReferenceAnnotationBeanPostProcessor

ReferenceAnnotationBeanPostProcessor是一个后置处理器，在Bean初始化时会被调用，注入相应的代理类

创作不易，如果对你有帮助，请点赞+收藏！