云端网络网站搭建一个平台

基于Dubbo 3.1，详细介绍了Dubbo服务的发布与引用的源码。

此前我们学习了Dubbo3.1版本的服务引入的总体流程，当然真正的服务远程引入、以及配置迁移啥的都还没讲，但是本次我们先不接着讲MigrationRuleListener#onRefer方法，而是先学习服务引用bean的获取以及懒加载原理。

Dubbo 3.x服务引用源码：

1. Dubbo 3.x源码(11)—Dubbo服务的发布与引用的入口
2. Dubbo 3.x源码(18)—Dubbo服务引用源码(1)
3. Dubbo 3.x源码(19)—Dubbo服务引用源码(2)
4. Dubbo 3.x源码(20)—Dubbo服务引用源码(3)
5. Dubbo 3.x源码(21)—Dubbo服务引用源码(4)
6. Dubbo 3.x源码(22)—Dubbo服务引用源码(5)服务引用bean的获取以及懒加载原理
7. Dubbo 3.x源码(23)—Dubbo服务引用源码(6)MigrationRuleListener迁移规则监听器

Dubbo 3.x服务发布源码：

1. Dubbo 3.x源码(11)—Dubbo服务的发布与引用的入口
2. Dubbo 3.x源码(12)—Dubbo服务发布导出源码(1)
3. Dubbo 3.x源码(13)—Dubbo服务发布导出源码(2)
4. Dubbo 3.x源码(14)—Dubbo服务发布导出源码(3)
5. Dubbo 3.x源码(15)—Dubbo服务发布导出源码(4)
6. Dubbo 3.x源码(16)—Dubbo服务发布导出源码(5)
7. Dubbo 3.x源码(17)—Dubbo服务发布导出源码(6)

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服务已经引入了。

所以这里的懒加载的目的并不是为了节省启动时间那么简单，那么为什么我们需要一个懒惰的代理？基于官方的注释如下：

1. 当Spring按类型搜索bean时，如果Spring不能确定工厂bean的类型，它可能会尝试初始化它。ReferenceBean也是一个工厂bean。(这已经通过DubboBeanDefinitionParser.configReferenceBean方法解决了，解决方法就是为ReferenceBean设置decoratedDefinition并且设置beanClass为接口的class。)
2. 此外，如果一些referencebean依赖于很早就初始化的bean，而dubbo配置bean还没有准备好，那么如果立即初始化dubbo引用，将会出现许多意想不到的问题。
3. 当它初始化时，只会创建一个惰性代理对象，并且不会初始化与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.Invoker<T>, 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以及真正的服务引入的逻辑，以及服务迁移到底是个什么东西？我们后面学习。