Dubbo 國內影響力最大的開源框架之一,非常適合構建大規模微服務集群的,提供開發框架、高性能通信、豐富服務治理等能力,同時 Dubbo 無縫支持 Spring、Spring Boot 模式的開發,這篇文章幫助大家理解 Dubbo 是怎么和 Spring 做集成的,非常適合關心原理是先的開發者,
感興趣的朋友可以直接訪問官網體驗 Spring+Dubbo 開發微服務 或搜索關注官方微信公眾號:Apache Dubbo
Spring Context Initialization
首先,我們先來看一下Spring context初始化主要流程,如下圖所示:

相關代碼:org.springframework.context.support.AbstractApplicationContext#refresh()
簡單描述一下每個步驟包含的內容:
- 創建BeanFactory:讀取加載XML/注解定義的BeanDefinition,
- prepareBeanFactory: 注冊提前加載的各種內置post-processor以及環境變數等,
- invokeBeanFactoryPostProcessors: 加載BeanDefinitionRegistryPostProcessor和 BeanFactoryPostProcessor,注意這里的加載順序比較復雜,還涉及到多次加載,詳細請查看代碼, 常用于加載較早初始化的組件,如屬性配置器PropertyPlaceholderConfigurer和PropertySourcesPlaceholderConfigurer, 還有一個比較重要的ConfigurationClassPostProcessor實作了BeanDefinitionRegistryPostProcessor介面,用于加載@Configuration類,決議@Bean定義并注冊BeanDefinition, 這個階段常用于注冊自定義BeanDefinition,
- registerBeanPostProcessors: 加載并注冊各種BeanPostProcessor,常用于修改或包裝(代理)bean實體,如Seata的GlobalTransactionScanner,
- registerListeners: 加載并注冊ApplicationListener,處理earlyApplicationEvents
- finishBeanFactoryInitialization: 注冊EmbeddedValueResolver,凍結配置
- preInstantiateSingletons: 遍歷加載單例bean,也就是加載普通的bean,包括@Controller, @Service, DAO等,
FactoryBean
Spring容器支持兩種bean:普通bean和工廠bean(FactoryBean),我們經常寫的@Controller/@Service這種被Spring直接初始化的bean就是普通bean, 而FactoryBean則是先由Spring先創建FactoryBean實體,然后由其再創建最終的bean實體,
[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分為注冊和創建實體兩大階段,將從Spring XML/注解決議到的bean資訊放到BeanDefinition,然后將其注冊到BeanFactory,后面會根據BeanDefinition來初始化bean實體, 不管是普通bean還是工廠bean,都是先注冊bean definition,然后按照依賴順序進行初始化,
兩者BeanDefinition的差異是:
- 普遍bean的BeanDefinition的beanClassName為最終bean的class
- 工廠bean的BeanDefinition的beanClassName為工廠bean的class
注冊Bean主要有幾種方式:
- 在Spring XML中定義< bean />,由Spring決議生成并BeanDefinition
- 在Spring java config中宣告@Bean方法,由Spring決議生成并BeanDefinition
- 呼叫BeanDefinitionRegistry.registerBeanDefinition()方法手工注冊BeanDefinition
- 通過SingletonBeanRegistry.registerSingleton()方法注冊bean實體,
注意:注冊bean實體與前面三種注冊BeanDefinition有本質的區別, 打個比方,注冊BeanDefinition是新兒子,Spring會管理bean的初始化及依賴注入及解決屬性占位符,呼叫BeanPostProcessor進行處理等, 而注冊bean實體就是別人的兒子,Spring將其視為已經完成初始化的bean,不會解決其依賴和屬性占位符,后面會講到Dubbo 2.7/3兩個版本Reference注解注冊bean的差異,
初始化bean
創建bean大概有下面幾個步驟:
- 創建實體 createBeanInstance
- 解決依賴 resolveDependency
- 解決屬性占位符 applyPropertyValues
其中多次呼叫BeanPostProcessor進行處理,如果某些BeanPostProcessor此時還沒注冊,則可能導致遺漏處理了當前的bean, 后面會講到dubbo 2.7中提前加載config bean導致的一系列問題,
其中關鍵邏輯請參考代碼:AbstractAutowireCapableBeanFactory#doCreateBean()
解決依賴
在Spring注解流行起來之后,通常是使用@Autowire注解來注入依賴的bean,此種注入方式大概的流程如下:
- 查找匹配屬性型別的beanName串列
- 根據@Qualifier/@Primary/propertyName等選擇合適的bean 關鍵邏輯請參考代碼:DefaultListableBeanFactory#doResolveDependency(),
其中第一步,查找匹配型別的beanName串列時會呼叫ListableBeanFactory#getBeanNamesForType()來列舉檢查所有的beanDefinition, 檢查bean type的邏輯請查看 AbstractBeanFactory#isTypeMatch(), 涉及的邏輯比較復雜,這里只簡單講一下重要的分支:
- 如果是普通bean,則檢查BeanDefinition的beanClass是否匹配
- 如果是FactoryBean,則通過多種方式來預測bean type
FactoryBean的型別預測主要包括下面幾種:
- 如果有DecoratedDefinition,則覆寫BeanDefinition,檢查合并后的beanClass是否匹配
- 通過FactoryBean.OBJECT_TYPE_ATTRIBUTE屬性獲取beanType (since 5.2)
- 實體化這個FactoryBean,呼叫getObjectType()方法來獲取beanType 上面提到的第三種情況可能會出現實體化失敗(如解決屬性占位符失敗)而被多次創建的問題,即每次預測bean type都會嘗試實體化,而每次都失敗,直到它所依賴的組件都就緒才成功,
Dubbo ReferenceBean本身也是一個FactoryBean,在2.7中經常因為預測bean type導致被自動初始化,后面會詳細講這個問題,
解決屬性
在Spring中一般是通過 PropertyPlaceholderConfigurer/PropertySourcesPlaceholderConfigurer來解決XML/@Value中的屬性占位符${...}, 二者都實作了BeanFactoryPostProcessor介面,會在invokeBeanFactoryPostProcessors階段被加載,然后遍歷處理所有BeanDefinition中的屬性占位符,
[決議注冊BeanDefinition] => [PropertyResourceConfigurer 解決屬性占位符] => [加載BeanPostProcessor] => [初始化單例bean]
由此可知,如果在PropertyPlaceholderConfigurer/PropertySourcesPlaceholderConfigurer加載前去初始化某個bean,則這個bean的屬性占位符是不會被解決的, 這個就是Dubbo config bean 被過早加載導致無法解決占位符的根因,
Dubbo Spring的一些問題及解決辦法
Dubbo spring 2.7 初始化程序
初始化入口是ReferenceBean#prepareDubboConfigBeans(),即當第一個ReferenceBean初始化完成時,嘗試加載其他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);
}
存在的問題:
- 沒有一個固定的初始化時機,而是與ReferenceBean初始化相關, 如果ReferenceBean被過早初始化,經常出現dubbo配置丟失、屬性占位符未解決等錯誤,
- 可能在BeanPostProcessor加載完成前初始化ReferenceBean,將導致類似Seata這種通過BeanPostProcessor機制的組件攔截失敗,
Dubbo spring 3的初始化程序
Dubbo 3 中進行大量重構,上面的痛點問題已經被解決,初始化主要流程如下:
[Spring決議XML/@Configuration class注冊BeanDefinition] => [加載BeanFactoryPostProcessor(包含PropertyResourceConfigurer)]
=> [1.決議@DubboReference/@DubboService注解并注冊BeanDefinition]
=> [加載并注冊BeanPostProcessor]
=> [加載ApplicationListener] => [2.加載DubboConfigBeanInitializer初始化config bean]
=> [初始化單例bean] => [依賴注入ReferenceBean]
=> [3.監聽ContextRefreshedEvent事件,啟動dubbo框架]
主要包含3個階段:
- 在BeanFactoryPostProcessor階段決議@DubboReference/@DubboService注解并注冊BeanDefinition,因為此時還是BeanDefinition處理階段, 故注冊的ReferenceBean可以被后續加載的業務bean使用@Autowire依賴注入,同時,也擴展支持在@Configuration bean 方法使用@DubboReference/@DubboService注解,
- 在加載完所有PropertyResourceConfigurer和BeanPostProcessor之后才會執行DubboConfigBeanInitializer初始化config bean,解決了屬性 占位符未解決和BeanPostProcessor攔截失敗的問題,
- 監聽在Spring context事件,在其加載完畢時啟動dubbo框架,
支持在@Configuration bean 方法使用@DubboReference/@DubboService注解
參考Dubbo spring 3的初始化程序的第1階段,
屬性占位符解決失敗
參考Dubbo spring 3的初始化程序的第2階段,
ReferenceBean被過早初始化問題
預測ReferenceBean beanType導致
Dubbo ReferenceBean本身也是一個FactoryBean,在2.7中經常因為預測bean type導致被自動初始化, 例如用戶自定義的某個BeanFactoryPostProcessor bean使用了@Autowire注解依賴注入某個業務bean, 而且這個自定義的BeanFactoryPostProcessor bean優先級比解決屬性占位符的PropertyResourceConfigurer高,則此時出現解決屬性占位符失敗,
Dubbo 3中ReferenceBean通過下面兩種方式解決預測type的問題:
FactoryBean的型別預測主要包括下面幾種:
如果有DecoratedDefinition,則覆寫BeanDefinition,檢查合并后的beanClass是否匹配
通過FactoryBean.OBJECT_TYPE_ATTRIBUTE屬性獲取beanType (since 5.2)
ReferenceBean被直接依賴導致過早初始
如果在Dubbo config bean初始化前被依賴自動創建ReferenceBean實體,并創建一個Lazy proxy類注入到依賴的類中,不需要解決屬性占位符,不會拉起Dubbo框架, 其他的config bean則固定在PropertyResourceConfigurer和BeanPostProcessor加載完成后才會執行初始化,避免了上述問題,
Reference注解可能出現@Autowire注入失敗的問題
在Dubbo 2.7中,在BeanPostProcessor中決議@DubboReference/@Reference注解,創建并注入ReferenceBean實體到Spring容器,這種方式有幾個問題:
@DubboReference/@Reference注解與XML定義的< dubbo:reference />初始化方式不一致,前者是由dubbo初始化,后者是由Spring容器負責初始化,
執行時機導致的依賴注入失敗問題,按照正常的在invokeBeanFactoryPostProcessors階段注冊完畢所有BeanDefinition,而dubbo 2.7的ReferenceAnnotationBeanPostProcessor 是在BeanPostProcessor執行時才創建ReferenceBean,可能出現某些比它早初始化的bean使用@Autowire注入失敗的情況,
在Dubbo 3中,改成在BeanFactoryPostProcessor決議@DubboReference/@Reference注解并注冊ReferenceBean的BeanDefinition,記錄欄位將要注入的referenceBeanName, 在BeanPostProcessor執行時通過BeanFactory().getBean(referenceBeanName)獲取到ReferenceBean實體,
搜索關注官方微信公眾號:Apache Dubbo,了解更多業界最新動態,掌握大廠面試必備 Dubbo 技能
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/539213.html
標籤:其他
