問題背景

我們項目的配置文件一直是通過Apollo進行管理，但是近期由于某些特殊的部署需求，需要使用K8S的原生對象來獲取配置，如此一來的話，就需要使用環(huán)境變量spring.config.location來指定application.properties文件的路徑，以便動態(tài)的獲取配置。

說明：項目是一個dubbo項目，配置文件中主要包括一些基礎(chǔ)組件的配置、以及dubbo相關(guān)的配置。

這時候問題來了，在所有配置及代碼都沒有變化的情況下，如果不指定環(huán)境變量使用本地的application.properties，則沒有異常任何，項目可以正常啟動，但是一但通過spring.config.location 來加載配置，則項目會直接啟動失敗，并報如下異常：

NoSuchBeanDefinitionException，這個異常前期誤導(dǎo)我不少時間，它一般是Spring在容器初始化時，進行依賴注入的時候沒有找到對應(yīng)的bean定義，也就意味著這個bean壓根沒有被注冊到BeanFactory中，這就很奇怪，只是配置文件的加載方式不同，為何會影響到bean的注冊？

過程

找不到bean，最常見的問題有兩種：要么是配置問題，比如掃描的包配置錯誤、配置未生效等。要么就是IoC容器的問題，存在多個容器，導(dǎo)致bean隔離。

定位

在這個問題場景下，兩種原因都有可能，不過問題可以復(fù)現(xiàn)，就比較好解決。我們直接驗證一下，最簡單粗暴的法子就是斷點伺候，對比兩種配置加載方式方式的差異。我們知道除了延遲加載的bean之外，所有bean都是在org.springframework.beans.factory.support.DefaultListableBeanFactory#preInstantiateSingletons初始化的，那么在這個方法里以異常信息中的bean名稱，打個條件斷點看看

通過斷點，可以拿到兩個信息

1、通過當前的堆棧，可以看到當前的初始化bean邏輯并不是SpringBoot的IoC容器觸發(fā)的，而是SpringCloud

2、beanNames，也就是當前beanFactory中所有已注冊的bean中，沒有加載到任何通過Spring的@Service注解標識的bean，但是卻加載到了所有被Dubbo的@Service加載到的bean。

這樣一來我們可以確定的是確實存在多容器隔離，SpringCloud也會通過BootstrapApplicationListener這個監(jiān)聽器創(chuàng)建一個IoC容器，查看官方說明：

A Spring Cloud application operates by creating a “bootstrap” context, which is a parent context for the main application. It is responsible for loading configuration properties from the external sources and for decrypting properties in the local external configuration files. The two contexts share an Environment, which is the source of external properties for any Spring application. By default, bootstrap properties (not bootstrap.properties but properties that are loaded during the bootstrap phase) are added with high precedence, so they cannot be overridden by local configuration.

SpringCloud創(chuàng)建的容器的加載順序比SpringBoot要早，是它的父容器，并且它們共享同一個Environment。

雖然現(xiàn)在知道了異常產(chǎn)生的原因，但是為什么換了配置加載方式就會由父容器加載？根據(jù)上面的第二個信息，被Dubbo注解標識的bean都被加載了，但是這些bean依賴的SpringBean還沒有加載進來，這意味著由于配置文件加載方式的變化，導(dǎo)致Dubbo標記的bean加載時機發(fā)生的改變。

根因

那接下來就是看一下Dubbo的bean加載邏輯，我們的服務(wù)比較老了，使用的spring-boot-starter-dubbo來整合SpringBoot與Dubbo。一般spring-boot-starter都是通過@EnableXXX或spring.factories來自動裝載相關(guān)的bean，而spring-boot-starter-dubbo沒有使用@Enable，那直接找到j(luò)ar包下的spring.factories文件，找到對應(yīng)的Initializer：

它實現(xiàn)的是ApplicationContextInitiailizer，這些接口會在準備完Context環(huán)境，在prepareContext中調(diào)用，那么很明顯，父容器肯定先會執(zhí)行，子容器后執(zhí)行。 看代碼邏輯，它只有在讀取到spring.dubbo.scan有值時，才會去注冊bean，到這里原因已經(jīng)比較明顯了，使用application.properties時父容器讀不到配置，而使用spring.config.location加載配置時，父容器可以讀到配置。

配置加載順序

上面提到的SpringCloud文檔中有這么一句話：

By default, bootstrap properties (not bootstrap.properties but properties that are loaded during the bootstrap phase) are added with high precedence

那么通過spring.config.location方式加載屬性是不是在bootstrap phase中呢，直接找到SpringCloud的加載類BootstrapApplicationListener，搜索spring.config.location，發(fā)現(xiàn)它確實優(yōu)先加載

而如果是使用application.properties，那么配置文件則不會被SpringCloud加載到，會由子容器加載。

解決

問題根因找到了，想解決就比較簡單了，兩種方式：

• 直接關(guān)閉SpringCloud的boostrap listener，通過配置spring.cloud.bootstrap.enabled=false即可
• 這個問題其實也是dubbo的整合方式不合理導(dǎo)致的，使用Dubbo自帶的注解掃描，不使用配置文件的方式

問題其實比較簡單，但是挺有意思，分享一下過程與思路*~*

到此這篇關(guān)于Spring配置文件加載方式變化引發(fā)的異常的文章就介紹到這了,更多相關(guān)Spring配置文件加載方式內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論