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

前言

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

一  服务发布

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

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

朝花夕拾---dubbo源码分析_第1张图片

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

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

ApplicationListener    spring的事件相关

InitializingBean       初始化相关

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

朝花夕拾---dubbo源码分析_第2张图片

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

ServiceBean#export();

     ServiceConfig#doExport()

              doExportUrlsFor1Protocol()

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

朝花夕拾---dubbo源码分析_第3张图片

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

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

proxyFactory:

朝花夕拾---dubbo源码分析_第4张图片

protocol:

朝花夕拾---dubbo源码分析_第5张图片 从以上截图不难发现:protocol和proxyFactory的处理逻辑大体类似:通过url获取指定参数,如果为空,就使用默认值:然后通过ExtensionLoader加载从url中获取的对象

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

朝花夕拾---dubbo源码分析_第6张图片

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

这是因为:在ExtensionLoader#createExtension时

 朝花夕拾---dubbo源码分析_第7张图片

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

朝花夕拾---dubbo源码分析_第8张图片

 朝花夕拾---dubbo源码分析_第9张图片

这里真正干活的还是:JavassistProxyFactory

所以,真正构建Invoker的代码如下:

朝花夕拾---dubbo源码分析_第10张图片

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

朝花夕拾---dubbo源码分析_第11张图片

 朝花夕拾---dubbo源码分析_第12张图片

再来看看export过程:

朝花夕拾---dubbo源码分析_第13张图片 同样的,extName是registry,实际的加载类是:ProtocolListenerWrapper

 朝花夕拾---dubbo源码分析_第14张图片

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

朝花夕拾---dubbo源码分析_第15张图片

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

 朝花夕拾---dubbo源码分析_第16张图片

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

朝花夕拾---dubbo源码分析_第17张图片

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

二  服务调用

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

首先,看一下ReferenceBean的类关系:

朝花夕拾---dubbo源码分析_第18张图片

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

ReferenceBean#getObject()

    ReferenceConfig#get()

         init();

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

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

朝花夕拾---dubbo源码分析_第19张图片

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

朝花夕拾---dubbo源码分析_第20张图片

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

朝花夕拾---dubbo源码分析_第21张图片

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

朝花夕拾---dubbo源码分析_第22张图片

 朝花夕拾---dubbo源码分析_第23张图片

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

朝花夕拾---dubbo源码分析_第24张图片

 大概装饰层级就是:

ProtocolListenerWrapper

   ProtocolFilterWrapper

      RegistryProtocol

 在RegistryProtocol是真正干活的地方:

朝花夕拾---dubbo源码分析_第25张图片

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

朝花夕拾---dubbo源码分析_第26张图片

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

替换后的代码如下:

朝花夕拾---dubbo源码分析_第27张图片

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

朝花夕拾---dubbo源码分析_第28张图片 和其他的Adaptive一样,真正干活的是JavassistProxyFactory,使用StubProxyFactoryWrapper做装饰

朝花夕拾---dubbo源码分析_第29张图片

真正干活的是JavassistProxyFactory

 朝花夕拾---dubbo源码分析_第30张图片

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

截图如下:

朝花夕拾---dubbo源码分析_第31张图片

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

当真正调用时,一路dubug

朝花夕拾---dubbo源码分析_第32张图片

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

首先:MockClusterInvoker

朝花夕拾---dubbo源码分析_第33张图片

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

朝花夕拾---dubbo源码分析_第34张图片

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

朝花夕拾---dubbo源码分析_第35张图片

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

朝花夕拾---dubbo源码分析_第36张图片

 真正干活的是ListenerInvokerWrapper

朝花夕拾---dubbo源码分析_第37张图片

 继续递进:调用ProtocolFilterWrapper

朝花夕拾---dubbo源码分析_第38张图片

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

朝花夕拾---dubbo源码分析_第39张图片

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

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

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

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

朝花夕拾---dubbo源码分析_第40张图片

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

朝花夕拾---dubbo源码分析_第41张图片 最终的Invoker寻找在RegistryDirectory里面维护的一个字段:methodInvokerMap里面查询即可

朝花夕拾---dubbo源码分析_第42张图片

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

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

通过跟踪字段的调用来源

朝花夕拾---dubbo源码分析_第43张图片

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

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

四 结论证明

在前言部分有说过,先给出部分结论:

1 所有被标记了@service和使用标记的元素,均会被spring解析成ServiceBean

2 所有被标记了@Reference和使用的元素,均会被spring解析成ReferenceBean

这是怎么做到的呢?

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

朝花夕拾---dubbo源码分析_第44张图片

而在springboot应用中,dubbo有引入:ServiceAnnotationBeanPostProcessor

朝花夕拾---dubbo源码分析_第45张图片

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

朝花夕拾---dubbo源码分析_第46张图片

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

朝花夕拾---dubbo源码分析_第47张图片

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

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

你可能感兴趣的:(dubbo,java,数据库)