技術文章 » SpringCloudAlibaba 微服務元件 Nacos 之設定中心原始碼深度解析

SpringCloudAlibaba 微服務元件 Nacos 之設定中心原始碼深度解析

2022-11-10 21:00:54

大家好，這篇文章跟大家聊下 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 載入應用設定時，同時會載入以下三種設定，分別是

  1. 不帶擴充套件名字尾，application

  2. 帶擴充套件名字尾，application.yml

  3. 帶環境，帶擴充套件名字尾，application-prod.yml

並且從上到下，優先順序依次增高

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

build 方法呼叫 loadNacosData 獲取設定，然後封裝成 NacosPropertySource，並且將該物件快取到 NacosPropertySourceRepository 中，後續會用到。

loadNacosData 方法中會將實際設定載入請求委託給 configService 去做，然後解析返回的字串，解析器實現了 PropertySourceLoader 介面，支援 yml、properties、xml、json 這幾種。

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

  1. 首先獲取本地快取檔案的設定內容，如果有直接返回

  2. 如果步驟 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 為維度進行註冊的，監聽器的主要操作就三步。

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

  2. 往 NacosRefreshHistory#records 中新增一條重新整理記錄

  3. 釋出一個 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 方法程式碼有點多，主要流程如下：

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

  1. checkUpdateDataIds 該方法中，會將所有的 dataId 按定義格式拼接出一個字串，構造一個長輪詢請求，發給伺服器端，Long-Pulling-Timeout 超時時間預設 30s，如果伺服器端沒有設定變更，則會保持該請求直到超時，有設定變更則直接返回有變更的 dataId 列表。

  1. 拿到第二步有變更的 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 事件。

ConfigurationPropertiesRebinder 會監聽 EnvironmentChangeEvent 事件，監聽到事件後會對所有的標註有 ConfigurationProperties 註解的設定類進行銷燬後重新初始化的操作，完之後我們的設定類中的屬性就是最新的了。

這裡我們說到了會對標有 ConfigurationProperties 註解的設定類進行 rebind，那對於普通元件類裡標有 @Value 註解的屬性要怎麼生效呢？這個其實需要配合 @RefreshScope 註解來生效的。

我們繼續回到上述的 refresh() 方法，接著會有一步 refreshAll 的操作，會呼叫父類別的 destroy 方法。

父類別就是 GenericScope，我們知道 Spring 中的 Bean 是有Scope 的概念的，Spring 預設 Scope 有單例和原型兩種，同時提供了 Scope 擴充套件介面，通過實現該介面我們可以定義自己的 Scope。

通過doGetBean 方法可以看出，這些自定義 Scope 型別物件的管理會交給相應的 Scope 實現去管理。

SpringCloud 實現的 RefreshScope 就是用來在執行時動態重新整理 Bean 用的，RefreshScope 繼承 GenericScope，提供 get 和 destroy 方法。

GenericScope 內部有一個 cache，用來儲存所有該 Scope 型別的物件。

回到主線，所以在 refreshAll 中呼叫 super.destroy 方法時會將該 scope 的這些 Bean 都銷燬掉，在下次 get 的時候在重新建立 Bean，新建立的 Bean 就有了我們最新的設定。

至此，我們就實現了設定熱更新的效果了。

總結

文章從服務啟動時的設定拉取，服務啟動後的設定監聽器註冊，以及設定變動後的熱更新實現三個方面從原始碼層面解析了整個的原理，希望對大家有所幫助。

個人開源專案

DynamicTp 是一個基於設定中心實現的輕量級動態執行緒池管理工具，主要功能可以總結為動態調參、通知報警、執行監控、三方包執行緒池管理等幾大類。

目前累計 2.2k star，歡迎大家試用，感謝你的 star，歡迎 pr，業務之餘一起給開源貢獻一份力量

官網：https://dynamictp.cn

gitee 地址：https://gitee.com/dromara/dynamic-tp

github 地址：https://github.com/dromara/dynamic-tp