SpringCloudAlibaba 微服務組件 Nacos 之配置中心原始碼深度決議-有解無憂

大家好，這篇文章跟大家聊下 SpringCloudAlibaba 中的微服務組件 Nacos，Nacos 既能做注冊中心，又能做配置中心，這篇文章主要來聊下做配置中心時 client 端的一些設計，主要從原始碼層面進行分析，相信看完這篇文章你對 Nacos client 端的作業原理應該有比較深刻的了解，

SpringCloud 應用啟動拉去配置

我們之前寫過一篇文章，介紹了一些 Spring 提供的擴展機制，其中說到了 ApplicationContextInitializer，該擴展是在背景關系準備階段（prepareContext），容器重繪之前做一些初始化作業，比如我們常用的配置中心 client 基本都是繼承該初始化器，在容器重繪前將配置從遠程拉到本地，然后封裝成 PropertySource 放到 Environment 中供使用，

在 SpringCloud 場景下，SpringCloud 規范中提供了 PropertySourceBootstrapConfiguration 繼承 ApplicationContextInitializer，另外還提供了個 PropertySourceLocator，二者配合完成配置中心的接入，

從上述截圖可以看出，在 PropertySourceBootstrapConfiguration 這個單例物件初始化的時候會將 Spring 容器中所有的 PropertySourceLocator 實作注入進來，然后在 initialize 方法中回圈所有的 PropertySourceLocator 進行配置的獲取，從這兒可以看出 SpringCloud 應用是支持我們引入多個配置中心實作的，獲取到配置后呼叫 insertPropertySources 方法將所有的 PropertySource（封裝的一個個組態檔）添加到 Spring 的環境變數 environment 中，

上圖展示了在 spring-cloud-starter-alibaba-nacos-config 包提供的自動裝配類中進行了 NacosPropertySourceLocator 的定義，該類繼承自上述說的 PropertySourceLocator，重寫了 locate 方法進行配置的讀取，

我們來分析下 NacosPropertySourceLocator，locate 方法只提取了主要流程代碼，可以看到 Nacos 啟動會加載以下三種組態檔，也就是我們在 bootstrap.yml 檔案里配置的擴展配置 extension-configs、共享配置 shared-configs 以及應用自己的配置，加載到組態檔后會封裝成 NacosPropertySource 回傳，

    public PropertySource<?> locate(Environment env) {
        // 生成 NacosConfigService 實體，后續配置操作都是圍繞該類進行
        ConfigService configService = nacosConfigManager.getConfigService();
        if (null == configService) {
            log.warn("no instance of config service found, can't load config from nacos");
            return null;
        }
        long timeout = nacosConfigProperties.getTimeout();
        // 配置獲取（使用 configService）、配置封裝、配置快取等操作
        nacosPropertySourceBuilder = new NacosPropertySourceBuilder(configService,
                timeout);
        CompositePropertySource composite = new CompositePropertySource(
                NACOS_PROPERTY_SOURCE_NAME);
        loadSharedConfiguration(composite);
        loadExtConfiguration(composite);
        loadApplicationConfiguration(composite, dataIdPrefix, nacosConfigProperties, env);
        return composite;
    }

loadApplicationConfiguration 加載應用配置時，同時會加載以下三種配置，分別是

不帶擴展名后綴，application

帶擴展名后綴，application.yml

帶環境，帶擴展名后綴，application-prod.yml

并且從上到下，優先級依次增高

加載的核心方法是 loadNacosDataIfPresent -> loadNacosPropertySource

build 方法呼叫 loadNacosData 獲取配置，然后封裝成 NacosPropertySource，并且將該物件快取到 NacosPropertySourceRepository 中，后續會用到，

loadNacosData 方法中會將實際配置加載請求委托給 configService 去做，然后決議回傳的字串，決議器實作了 PropertySourceLoader 介面，支持 yml、properties、xml、json 這幾種，

getConfig 方法會呼叫到 getConfigInner 方法，通過 namespace, dataId, group 唯一定位一個組態檔

首先獲取本地快取檔案的配置內容，如果有直接回傳

如果步驟 1 從本地沒找到相應組態檔，開始從遠處拉去，Nacos 2.0 以上版本使用 Grpc 協議進行遠程通信，1.0 及以下使用 Http 協議進行遠程通信，我們這邊以 1.x 為例來解讀

getServerConfig 方法會構造最終的 http 請求引數進行呼叫，如果回傳 ok，則將回傳內容寫入到本地快取檔案中，并進行回傳，

至此，在專案啟動的時候（背景關系準備階段）我們就拉到了遠程 Nacos 中的配置，并且封裝成 NacosPropertySource 放到了 Spring 的環境變數里，

監聽器注冊

上面章節我們說了服務啟動的時候從遠程 Nacos 服務端拉到配置，這個章節我們來說下配置變動怎么實時通知到客戶端，首先需要注冊監聽器，

主要看 NacosContextRefresher 類，該類會監聽服務啟動發布的 ApplicationReadyEvent 事件，然后進行配置監聽器的注冊，

registerNacosListenersForApplications 方法里會進行判斷，如果自動重繪機制是開啟的，則進行監聽器注冊，上個章節我們說到了會將拉到的配置快取到 NacosPropertySourceRepository 中，這兒就從快取中獲取所有的配置，然后回圈進行監聽器注冊（如果組態檔中配置 refresh 欄位為 false，則不注冊監聽器），

我們可以看到，監聽器是以 dataId + groupId + namespace 為維度進行注冊的，監聽器的主要操作就三步，

REFRESH_COUNT ++，在上述說的 loadNacosPropertySource 方法有用到

往 NacosRefreshHistory#records 中添加一條重繪記錄

發布一個 RefreshEvent 事件，該事件是 SpringCloud 提供的，主要就是用來做環境變更重繪用的

注冊操作經過 ConfigService，在 ClientWorker 中處理，這塊會創建一個 CacheData 物件，該物件主要就是用來管理監聽器的，也是非常重要的一個類，

CacheData 中欄位如下圖，ManagerListenerWrap 對 Listener 做層包裝，內部會保存 listener、上次變更的 content 以及 md5（用來判斷配置有沒有變更用），

并且在 addCacheDataIfAbsent 方法中會將剛才創建的 CacheData 快取到 ClientWorker 中的一個 Map 中，后續會用到，

至此，在服務啟動后向每一個需要支持熱更新的配置都注冊了一個監聽器，用來監聽遠程配置的變動，以及做相應的處理

配置熱更新

上面章節我們講了服務啟動的時候從遠程 Nacos 服務端拉到配置，以及服務啟動后對需要支持熱更新的配置都注冊了一個監聽器，這個章節我們來說下配置變動后具體是怎么處理的，

回到上述說過的 NacosPropertySourceLocator 的 locate 方法看看，該方法首先會獲取一個 ConfigService，

NacosConfigManager 中會進行一個 ConfigService 單例物件的創建，創建流程最侄訓委托給 ConfigFactory，使用反射方式創建一個 NacosConfigService 的實體物件，NacosConfigService 是一個很核心的類，配置的獲取，監聽器的注冊都需要經此，

我們看下 NacosConfigService 的建構式，會去創建一個 ClientWorker 類的物件，這個類是實作配置熱更新的核心類，

ClientWorker 的建構式里會去創建兩個執行緒池，executor 會每隔 10ms 進行一次配置變更的檢查，executorService 主要是用來處理長輪詢請求的，

checkConfigInfo 方法中會創建一個長輪詢任務丟到 executorService 執行緒池中去處理，

LongPollingRunnable 的 run 方法代碼有點多，主要流程如下：

獲取上個章節中說到的快取 cacheMap，然后遍歷，判斷如果該配置使用的是本地快取模式，則呼叫 checkListenerMd5 去檢查讀到的本地快取檔案中內容的 Md5 跟上次更新的 Md5 是不是一樣，不一樣則呼叫 safeNotifyListener 去通知監聽器處理，并且更新 listenerWrap 中的 content、Md5

checkUpdateDataIds 該方法中，會將所有的 dataId 按定義格式拼接出一個字串，構造一個長輪詢請求，發給服務端，Long-Pulling-Timeout 超時時間默認 30s，如果服務端沒有配置變更，則會保持該請求直到超時，有配置變更則直接回傳有變更的 dataId 串列，

拿到第二步有變更的 dataId 后會呼叫 getServerConfig 獲取最新的配置內容，然后遍歷呼叫 checkListenerMd5 去檢查最新拉取的配置內容的 Md5 跟上次更新的 Md5 是不是一樣，不一樣則呼叫 safeNotifyListener 去通知監聽器處理，并且更新 listenerWrap 中的 content、Md5

checkListenerMd5 方法如下，主要就是判斷兩個 md5 是不是相同，不同則呼叫 safeNotifyListener 處理，

safeNotifyListener 方法主要就是呼叫監聽器的 receiveConfigInfo 方法，然后更新監聽器包裝器中的 lastContent、lastCallMd5 欄位，

監聽器要執行的方法我們上面也已經講過了，這邊再貼下截圖，主要就是發布 RefreshEvent 事件，

至此，Nacos 的處理流程已經結束了，RefreshEvent 事件主要由 SpringCloud 相關類來處理，

RefreshEvent 事件處理

RefreshEvent 事件會由 RefreshEventListener 來處理，該 listener 含有一個 ContextRefresher 的物件，

如下圖所示，refreshEnvironment 會去重繪 Spring 環境變數，實際上是交給 updateEnvironment 方法去做的重繪，具體重繪思想就是重新創建一個 Spring 容器，然后將這個新容器中的環境資訊設定到原有的 Spring 環境中，拿到所有變化的配置項后，發布一個環境變化的 EnvironmentChangeEvent 事件，