引言

Dubbo 國內(nèi)影響力最大的開源框架之一，非常適合構(gòu)建大規(guī)模微服務(wù)集群的，提供開發(fā)框架、高性能通信、豐富服務(wù)治理等能力。同時(shí) Dubbo 無縫支持 Spring、Spring Boot 模式的開發(fā)，這篇文章幫助大家理解 Dubbo 是怎么和 Spring 做集成的，非常適合關(guān)心原理是先的開發(fā)者。

感興趣的朋友可以直接訪問官網(wǎng)體驗(yàn) Spring+Dubbo 開發(fā)微服務(wù) 

Spring Context Initialization

首先，我們先來看一下Spring context初始化主要流程，如下圖所示：

相關(guān)代碼：org.springframework.context.support.AbstractApplicationContext#refresh()

簡單描述一下每個(gè)步驟包含的內(nèi)容：

• 創(chuàng)建BeanFactory：讀取加載XML/注解定義的BeanDefinition。
• prepareBeanFactory: 注冊(cè)提前加載的各種內(nèi)置post-processor以及環(huán)境變量等。
• invokeBeanFactoryPostProcessors: 加載BeanDefinitionRegistryPostProcessor和 BeanFactoryPostProcessor。注意這里的加載順序比較復(fù)雜，還涉及到多次加載，詳細(xì)請(qǐng)查看代碼。 常用于加載較早初始化的組件，如屬性配置器PropertyPlaceholderConfigurer和PropertySourcesPlaceholderConfigurer。 還有一個(gè)比較重要的ConfigurationClassPostProcessor實(shí)現(xiàn)了BeanDefinitionRegistryPostProcessor接口，用于加載@Configuration類，解析@Bean定義并注冊(cè)BeanDefinition。 這個(gè)階段常用于注冊(cè)自定義BeanDefinition。
• registerBeanPostProcessors: 加載并注冊(cè)各種BeanPostProcessor，常用于修改或包裝(代理)bean實(shí)例，如Seata的GlobalTransactionScanner。
• registerListeners: 加載并注冊(cè)ApplicationListener，處理earlyApplicationEvents
• finishBeanFactoryInitialization: 注冊(cè)EmbeddedValueResolver，凍結(jié)配置
• preInstantiateSingletons: 遍歷加載單例bean，也就是加載普通的bean，包括@Controller, @Service, DAO等。

FactoryBean

Spring容器支持兩種bean：普通bean和工廠bean(FactoryBean)。我們經(jīng)常寫的@Controller/@Service這種被Spring直接初始化的bean就是普通bean， 而FactoryBean則是先由Spring先創(chuàng)建FactoryBean實(shí)例，然后由其再創(chuàng)建最終的bean實(shí)例。

[Spring BeanFactory] --create---> [XxxFactoryBean instance] --create--> [Final Bean Instance]
FactoryBean接口如下：

public interface FactoryBean<T> {
  /**
   * Return an instance (possibly shared or independent) of the object managed by this factory.
   */
	T getObject() throws Exception;
  /**
   * Return the type of object that this FactoryBean creates, or null if not known in advance.
   * This allows one to check for specific types of beans without instantiating objects, for example on autowiring.
   */
  Class<?> getObjectType();
}

BeanDefinition

Spring bean分為注冊(cè)和創(chuàng)建實(shí)例兩大階段。將從Spring XML/注解解析到的bean信息放到BeanDefinition，然后將其注冊(cè)到BeanFactory，后面會(huì)根據(jù)BeanDefinition來初始化bean實(shí)例。 不管是普通bean還是工廠bean，都是先注冊(cè)bean definition，然后按照依賴順序進(jìn)行初始化。

兩者BeanDefinition的差異是：

• 普遍bean的BeanDefinition的beanClassName為最終bean的class
• 工廠bean的BeanDefinition的beanClassName為工廠bean的class

注冊(cè)Bean主要有幾種方式：

• 在Spring XML中定義< bean />，由Spring解析生成并BeanDefinition
• 在Spring java config中聲明@Bean方法，由Spring解析生成并BeanDefinition
• 調(diào)用BeanDefinitionRegistry.registerBeanDefinition()方法手工注冊(cè)BeanDefinition
• 通過SingletonBeanRegistry.registerSingleton()方法注冊(cè)bean實(shí)例。

注意：注冊(cè)bean實(shí)例與前面三種注冊(cè)BeanDefinition有本質(zhì)的區(qū)別。 打個(gè)比方，注冊(cè)BeanDefinition是新兒子，Spring會(huì)管理bean的初始化及依賴注入及解決屬性占位符，調(diào)用BeanPostProcessor進(jìn)行處理等。 而注冊(cè)bean實(shí)例就是別人的兒子，Spring將其視為已經(jīng)完成初始化的bean，不會(huì)解決其依賴和屬性占位符。后面會(huì)講到Dubbo 2.7/3兩個(gè)版本Reference注解注冊(cè)bean的差異。

初始化bean

創(chuàng)建bean大概有下面幾個(gè)步驟：

• 創(chuàng)建實(shí)例 createBeanInstance
• 解決依賴 resolveDependency
• 解決屬性占位符 applyPropertyValues

其中多次調(diào)用BeanPostProcessor進(jìn)行處理，如果某些BeanPostProcessor此時(shí)還沒注冊(cè)，則可能導(dǎo)致遺漏處理了當(dāng)前的bean。 后面會(huì)講到dubbo 2.7中提前加載config bean導(dǎo)致的一系列問題。

其中關(guān)鍵邏輯請(qǐng)參考代碼：AbstractAutowireCapableBeanFactory#doCreateBean()

解決依賴

在Spring注解流行起來之后，通常是使用@Autowire注解來注入依賴的bean。此種注入方式大概的流程如下：

• 查找匹配屬性類型的beanName列表
• 根據(jù)@Qualifier/@Primary/propertyName等選擇合適的bean 關(guān)鍵邏輯請(qǐng)參考代碼：DefaultListableBeanFactory#doResolveDependency()。

其中第一步，查找匹配類型的beanName列表時(shí)會(huì)調(diào)用ListableBeanFactory#getBeanNamesForType()來枚舉檢查所有的beanDefinition。 檢查bean type的邏輯請(qǐng)查看 AbstractBeanFactory#isTypeMatch()。 涉及的邏輯比較復(fù)雜，這里只簡單講一下重要的分支：

• 如果是普通bean，則檢查BeanDefinition的beanClass是否匹配
• 如果是FactoryBean，則通過多種方式來預(yù)測bean type

FactoryBean的類型預(yù)測主要包括下面幾種：

• 如果有DecoratedDefinition，則覆蓋BeanDefinition，檢查合并后的beanClass是否匹配
• 通過FactoryBean.OBJECT_TYPE_ATTRIBUTE屬性獲取beanType (since 5.2)
• 實(shí)例化這個(gè)FactoryBean，調(diào)用getObjectType()方法來獲取beanType 上面提到的第三種情況可能會(huì)出現(xiàn)實(shí)例化失?。ㄈ缃鉀Q屬性占位符失?。┒欢啻蝿?chuàng)建的問題，即每次預(yù)測bean type都會(huì)嘗試實(shí)例化，而每次都失敗，直到它所依賴的組件都就緒才成功。

Dubbo ReferenceBean本身也是一個(gè)FactoryBean，在2.7中經(jīng)常因?yàn)轭A(yù)測bean type導(dǎo)致被自動(dòng)初始化，后面會(huì)詳細(xì)講這個(gè)問題。

解決屬性

在Spring中一般是通過 PropertyPlaceholderConfigurer/PropertySourcesPlaceholderConfigurer來解決XML/@Value中的屬性占位符${...}。 二者都實(shí)現(xiàn)了BeanFactoryPostProcessor接口，會(huì)在invokeBeanFactoryPostProcessors階段被加載，然后遍歷處理所有BeanDefinition中的屬性占位符。

[解析注冊(cè)BeanDefinition] => [PropertyResourceConfigurer 解決屬性占位符] => [加載BeanPostProcessor] => [初始化單例bean]
由此可知，如果在PropertyPlaceholderConfigurer/PropertySourcesPlaceholderConfigurer加載前去初始化某個(gè)bean，則這個(gè)bean的屬性占位符是不會(huì)被解決的。 這個(gè)就是Dubbo config bean 被過早加載導(dǎo)致無法解決占位符的根因。

Dubbo Spring的一些問題及解決辦法

Dubbo spring 2.7 初始化過程

初始化入口是ReferenceBean#prepareDubboConfigBeans()，即當(dāng)?shù)谝粋€(gè)ReferenceBean初始化完成時(shí)，嘗試加載其他dubbo config bean。

    @Override
    public void afterPropertiesSet() throws Exception {
        // Initializes Dubbo's Config Beans before @Reference bean autowiring
        prepareDubboConfigBeans();
        // lazy init by default.
        if (init == null) {
        init = false;
        }
        // eager init if necessary.
        if (shouldInit()) {
        getObject();
        }
    }
    private void prepareDubboConfigBeans() {
        beansOfTypeIncludingAncestors(applicationContext, ApplicationConfig.class);
        beansOfTypeIncludingAncestors(applicationContext, ModuleConfig.class);
        beansOfTypeIncludingAncestors(applicationContext, RegistryConfig.class);
        beansOfTypeIncludingAncestors(applicationContext, ProtocolConfig.class);
        beansOfTypeIncludingAncestors(applicationContext, MonitorConfig.class);
        beansOfTypeIncludingAncestors(applicationContext, ProviderConfig.class);
        beansOfTypeIncludingAncestors(applicationContext, ConsumerConfig.class);
        beansOfTypeIncludingAncestors(applicationContext, ConfigCenterBean.class);
        beansOfTypeIncludingAncestors(applicationContext, MetadataReportConfig.class);
        beansOfTypeIncludingAncestors(applicationContext, MetricsConfig.class);
        beansOfTypeIncludingAncestors(applicationContext, SslConfig.class);
    }

存在的問題：

• 沒有一個(gè)固定的初始化時(shí)機(jī)，而是與ReferenceBean初始化相關(guān)。 如果ReferenceBean被過早初始化，經(jīng)常出現(xiàn)dubbo配置丟失、屬性占位符未解決等錯(cuò)誤。
• 可能在BeanPostProcessor加載完成前初始化ReferenceBean，將導(dǎo)致類似Seata這種通過BeanPostProcessor機(jī)制的組件攔截失敗。

Dubbo spring 3的初始化過程

Dubbo 3 中進(jìn)行大量重構(gòu)，上面的痛點(diǎn)問題已經(jīng)被解決，初始化主要流程如下：

[Spring解析XML/@Configuration class注冊(cè)BeanDefinition] => [加載BeanFactoryPostProcessor(包含PropertyResourceConfigurer)] 
 => [1.解析@DubboReference/@DubboService注解并注冊(cè)BeanDefinition]
 => [加載并注冊(cè)BeanPostProcessor] 
 => [加載ApplicationListener] => [2.加載DubboConfigBeanInitializer初始化config bean]
 => [初始化單例bean] => [依賴注入ReferenceBean]
 => [3.監(jiān)聽ContextRefreshedEvent事件，啟動(dòng)dubbo框架]

主要包含3個(gè)階段：

• 在BeanFactoryPostProcessor階段解析@DubboReference/@DubboService注解并注冊(cè)BeanDefinition。因?yàn)榇藭r(shí)還是BeanDefinition處理階段， 故注冊(cè)的ReferenceBean可以被后續(xù)加載的業(yè)務(wù)bean使用@Autowire依賴注入。同時(shí)，也擴(kuò)展支持在@Configuration bean 方法使用@DubboReference/@DubboService注解。
• 在加載完所有PropertyResourceConfigurer和BeanPostProcessor之后才會(huì)執(zhí)行DubboConfigBeanInitializer初始化config bean，解決了屬性 占位符未解決和BeanPostProcessor攔截失敗的問題。
• 監(jiān)聽在Spring context事件，在其加載完畢時(shí)啟動(dòng)dubbo框架。

支持在@Configuration bean 方法使用@DubboReference/@DubboService注解

參考Dubbo spring 3的初始化過程的第1階段。

屬性占位符解決失敗

參考Dubbo spring 3的初始化過程的第2階段。

ReferenceBean被過早初始化問題

預(yù)測ReferenceBean beanType導(dǎo)致 Dubbo ReferenceBean本身也是一個(gè)FactoryBean，在2.7中經(jīng)常因?yàn)轭A(yù)測bean type導(dǎo)致被自動(dòng)初始化。 例如用戶自定義的某個(gè)BeanFactoryPostProcessor bean使用了@Autowire注解依賴注入某個(gè)業(yè)務(wù)bean， 而且這個(gè)自定義的BeanFactoryPostProcessor bean優(yōu)先級(jí)比解決屬性占位符的PropertyResourceConfigurer高，則此時(shí)出現(xiàn)解決屬性占位符失敗。

Dubbo 3中ReferenceBean通過下面兩種方式解決預(yù)測type的問題:

FactoryBean的類型預(yù)測主要包括下面幾種：

如果有DecoratedDefinition，則覆蓋BeanDefinition，檢查合并后的beanClass是否匹配

通過FactoryBean.OBJECT_TYPE_ATTRIBUTE屬性獲取beanType (since 5.2)

ReferenceBean被直接依賴導(dǎo)致過早初始</strong> 如果在Dubbo config bean初始化前被依賴自動(dòng)創(chuàng)建ReferenceBean實(shí)例，并創(chuàng)建一個(gè)Lazy proxy類注入到依賴的類中，不需要解決屬性占位符，不會(huì)拉起Dubbo框架。 其他的config bean則固定在PropertyResourceConfigurer和BeanPostProcessor加載完成后才會(huì)執(zhí)行初始化，避免了上述問題。

Reference注解可能出現(xiàn)@Autowire注入失敗的問題

在Dubbo 2.7中，在BeanPostProcessor中解析@DubboReference/@Reference注解，創(chuàng)建并注入ReferenceBean實(shí)例到Spring容器。這種方式有幾個(gè)問題：

@DubboReference/@Reference注解與XML定義的< dubbo:reference />初始化方式不一致，前者是由dubbo初始化，后者是由Spring容器負(fù)責(zé)初始化。

執(zhí)行時(shí)機(jī)導(dǎo)致的依賴注入失敗問題。按照正常的在invokeBeanFactoryPostProcessors階段注冊(cè)完畢所有BeanDefinition，而dubbo 2.7的ReferenceAnnotationBeanPostProcessor 是在BeanPostProcessor執(zhí)行時(shí)才創(chuàng)建ReferenceBean，可能出現(xiàn)某些比它早初始化的bean使用@Autowire注入失敗的情況。

在Dubbo 3中，改成在BeanFactoryPostProcessor解析@DubboReference/@Reference注解并注冊(cè)ReferenceBean的BeanDefinition，記錄字段將要注入的referenceBeanName。 在BeanPostProcessor執(zhí)行時(shí)通過BeanFactory().getBean(referenceBeanName)獲取到ReferenceBean實(shí)例。

以上就是Dubbo3的Spring適配原理與初始化流程源碼解析的詳細(xì)內(nèi)容，更多關(guān)于Dubbo3 Spring適配初始化流程的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論