SpringCloudAlibaba 微服務組件 Nacos 之配置中心源碼深度解析

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

大家好，這篇文章跟大家聊下 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 事件。