网站域名申请程序,深圳网站优化网站,苏州公司注册查询,wordpress 网站特效基于Dubbo 3.1#xff0c;详细介绍了Dubbo服务的发布与引用的源码。 此前我们学习了Dubbo3.1版本的服务引入的总体流程#xff0c;当然真正的服务远程引入、以及配置迁移啥的都还没讲#xff0c;但是本次我们先不接着讲MigrationRuleListener#onRefer方法#xff0c;而是先… 基于Dubbo 3.1详细介绍了Dubbo服务的发布与引用的源码。 此前我们学习了Dubbo3.1版本的服务引入的总体流程当然真正的服务远程引入、以及配置迁移啥的都还没讲但是本次我们先不接着讲MigrationRuleListener#onRefer方法而是先学习服务引用bean的获取以及懒加载原理。
Dubbo 3.x服务引用源码
Dubbo 3.x源码(11)—Dubbo服务的发布与引用的入口Dubbo 3.x源码(18)—Dubbo服务引用源码(1)Dubbo 3.x源码(19)—Dubbo服务引用源码(2)Dubbo 3.x源码(20)—Dubbo服务引用源码(3)Dubbo 3.x源码(21)—Dubbo服务引用源码(4)Dubbo 3.x源码(22)—Dubbo服务引用源码(5)服务引用bean的获取以及懒加载原理Dubbo 3.x源码(23)—Dubbo服务引用源码(6)MigrationRuleListener迁移规则监听器
Dubbo 3.x服务发布源码
Dubbo 3.x源码(11)—Dubbo服务的发布与引用的入口Dubbo 3.x源码(12)—Dubbo服务发布导出源码(1)Dubbo 3.x源码(13)—Dubbo服务发布导出源码(2)Dubbo 3.x源码(14)—Dubbo服务发布导出源码(3)Dubbo 3.x源码(15)—Dubbo服务发布导出源码(4)Dubbo 3.x源码(16)—Dubbo服务发布导出源码(5)Dubbo 3.x源码(17)—Dubbo服务发布导出源码(6) 文章目录 1 服务引用bean的获取以及懒加载原理2 createLazyProxy创建懒加载代理对象3 DubboReferenceLazyInitTargetSource目标源4 代理对象层次以及懒加载的原理5 总结 1 服务引用bean的获取以及懒加载原理
上面的几篇文章中我们学习了Dubbo 服务引入的流程我们知道在进行了服务引入并创建了服务引入Invoker之后在最后会调用proxyFactory.getProxy方法根据invoker创建一个服务接口代理对象返回并且赋值给ReferenceConfig的ref属性。
而我们知道在业务代码中通过DubboReference注解实际引入的也是一个服务接口代理对象实例。
那么这两个代理对象就是同一个对象吗还是说业务代码中实际引用的是另一个代理对象呢 首先我们此前就学习过reference xml标签或者DubboReference注解等方式引入的服务最终会被构建为一个ReferenceBean实例并存入spring容器。
ReferenceBean实现了FactoryBean接口那么我们实际上在业务代码中注入的服务接口代理对象实例来自于它的getObject方法的实现。
/*** Create bean instance.** p/p* Why we need a lazy proxy?** p/* When Spring searches beans by type, if Spring cannot determine the type of a factory bean, it may try to initialize it.* The ReferenceBean is also a FactoryBean.* br/* (This has already been resolved by decorating the BeanDefinition: {link DubboBeanDefinitionParser#configReferenceBean})** p/* In addition, if some ReferenceBeans are dependent on beans that are initialized very early,* and dubbo config beans are not ready yet, there will be many unexpected problems if initializing the dubbo reference immediately.** p/* When it is initialized, only a lazy proxy object will be created,* and dubbo reference-related resources will not be initialized.* br/* In this way, the influence of Spring is eliminated, and the dubbo configuration initialization is controllable.*** see DubboConfigBeanInitializer* see ReferenceBeanManager#initReferenceBean(ReferenceBean)* see DubboBeanDefinitionParser#configReferenceBean*** ReferenceBean的方法* * 创建bean实例。**/
Override
public T getObject() {//如果懒加载的代理对象为null那么创建要给懒加载的代理对象if (lazyProxy null) {createLazyProxy();}//返回懒加载的代理对象return (T) lazyProxy;
}可以看到该方法有很长的注释说明并且该方法会返回一个懒加载的代理对象。但是实际上目前版本Dubbo服务默认情况下都是随着应用的启动而引入的真正调用懒加载对象的方法的时候对应的Dubbo服务已经引入了。
所以这里的懒加载的目的并不是为了节省启动时间那么简单那么为什么我们需要一个懒惰的代理基于官方的注释如下
当Spring按类型搜索bean时如果Spring不能确定工厂bean的类型它可能会尝试初始化它。ReferenceBean也是一个工厂bean。(这已经通过DubboBeanDefinitionParser.configReferenceBean方法解决了解决方法就是为ReferenceBean设置decoratedDefinition并且设置beanClass为接口的class。)此外如果一些referencebean依赖于很早就初始化的bean而dubbo配置bean还没有准备好那么如果立即初始化dubbo引用将会出现许多意想不到的问题。当它初始化时只会创建一个惰性代理对象并且不会初始化与dubbo引用相关的资源。这样就消除了Spring的影响并且dubbo配置初始化是可控的。
2 createLazyProxy创建懒加载代理对象
为当前服务接口创建一个懒加载代理对象到这里我们明白了业务代码中实际引用的服务接口代理对象实例和ReferenceConfig内部的服务接口代理对象实例ref并不是同一个代理对象。
这里代理对象是通过ProxyFactory代理工厂创建的对象而ProxyFactory是spring包中的类spring aop也是是通过ProxyFactory创建代理对象的我们在此前学习spring aop源码的时候就学过它具体的AOP创建代理对象的源码可以看之前的文章https://blog.csdn.net/weixin_43767015/article/details/109851001
最终我们创建的代理及接口实例是基于JDK的动态代理并且实现了目标代理接口、EchoService、Destroyable这三个接口targetSource目标源为DubboReferenceLazyInitTargetSource。
/*** ReferenceBean的方法* p* 创建引用服务接口的懒加载的代理对象*/
private void createLazyProxy() {//set proxy interfaces//see also: org.apache.dubbo.rpc.proxy.AbstractProxyFactory.getProxy(org.apache.dubbo.rpc.InvokerT, boolean)//新建一个ProxyFactory代理工厂对象用于创建代理//这里的ProxyFactory是spring包中的类ProxyFactory proxyFactory new ProxyFactory();//创建DubboReferenceLazyInitTargetSource对象添加到proxyFactory的targetSource属性中通过此可以获取源目标对象proxyFactory.setTargetSource(new DubboReferenceLazyInitTargetSource());//代理对象需要实现的接口引用服务接口proxyFactory.addInterface(interfaceClass);//代理对象需要实现的内部接口EchoService、DestroyableClass?[] internalInterfaces AbstractProxyFactory.getInternalInterfaces();for (Class? anInterface : internalInterfaces) {proxyFactory.addInterface(anInterface);}if (!StringUtils.isEquals(interfaceClass.getName(), interfaceName)) {//add service interfacetry {Class? serviceInterface ClassUtils.forName(interfaceName, beanClassLoader);proxyFactory.addInterface(serviceInterface);} catch (ClassNotFoundException e) {// generic call maybe without service interface class locally}}/** 通过proxyFactory获取代理对象*/this.lazyProxy proxyFactory.getProxy(this.beanClassLoader);
}3 DubboReferenceLazyInitTargetSource目标源
每个代理对象保存了一个targetSource对象这个targetSource对象内部封装了一个AOP的目标对象也就是被代理对象通过getTarget方法可获取目标对象然后就能通过目标对象调用被代理的原始方法了。
dubbo服务代理对象的目标源是一个DubboReferenceLazyInitTargetSource对象它是ReferenceBean类的一个内部类我们来看看它的实现。
/*** ReferenceBean的方法** return 获取调用的代理对象*/
private Object getCallProxy() throws Exception {//如果ReferenceBean内部的referenceConfig不存在则抛出异常if (referenceConfig null) {throw new IllegalStateException(ReferenceBean is not ready yet, please make sure to call reference interface method after dubbo is started.);}//get reference proxy/** 返回referenceConfig内部的代理引用服务实例ref*/return referenceConfig.get();
}private class DubboReferenceLazyInitTargetSource extends AbstractLazyCreationTargetSource {/*** 获取代理目标对象*/Overrideprotected Object createObject() throws Exception {return getCallProxy();}/*** 获取代理目标接口*/Overridepublic synchronized Class? getTargetClass() {return getInterfaceClass();}
}4 代理对象层次以及懒加载的原理
getCallProxy方法内部调用的ReferenceConfig#get方法我们在本文的最开始就学习过了将会返回内部的ref那么一切都变得明朗起来实际上业务代码中获取的代理对象内部的代理目标对象就是ReferenceConfig内部的服务接口代理对象实例ref这就是它们之间的关系。
如果我们对应某个引用的服务设置属性init false那么在此前讲的DefaultModuleDeployer#referServices方法批量引用服务的时候在shouldInit方法就会返回false那么就不会调用ReferenceConfig#get方法自然在启动的时候就不会去真正的进行服务引用。
而当我们调用代理对象的方法的时候在获取代理目标对象的时候getCallProxy方法中会调用ReferenceConfig#get方法这样就把对于服务的引用从服务启动的时候延迟到了真正调用服务接口的时候这就是Dubbo懒加载的实现原理。
真正调用的时候调用逻辑为业务引入的接口代理对象ReferenceBean内部的lazyProxy- 代理目标对象ReferenceConfig内部的接口代理对象ref后续就是InvokerInvocationHandler、Invoker等真正dubbo相关的调用处理逻辑了这些我们在后面dubbo服务调用的文章中讲解。
5 总结
本次我们学习了Dubbo服务引用bean的获取以及懒加载原理。
接下来我们将会继续学习MigrationRuleListener#onRefer方法该方法才是真正的服务引入入口MigrationRuleListener以及真正的服务引入的逻辑以及服务迁移到底是个什么东西我们后面学习。
