?【Alibaba中介軟體技術系列】「Nacos技術專題」配置中心載入原理和配置實時更新原理分析（上）

浩宇天尚發表於2022-01-20

官方資源

https://nacos.io/zh-cn/docs/quick-start.html

Nacos之配置中心

  • 動態配置管理是 Nacos的三大功能之一，通過動態配置服務，可以在所有環境中以集中和動態的方式管理所有應用程式或服務的配置資訊。
  • 動態配置中心可以實現配置更新時無需重新部署應用程式和服務即可使相應的配置資訊生效，這極大了增加了系統的運維能力。

動態配置

Nacos的動態配置的能力，看看 Nacos是如何以簡單、優雅、高效的方式管理配置，實現配置的動態變更的，接下來來了解下 Nacos 的動態配置的功能。

環境準備

首先我們要準備一個 Nacos 的服務端，現在有兩種方式獲取 Nacos 的服務端：

  • 通過原始碼編譯
  • 下載Release包

注意：自己去編譯可以瞭解一些過程也有可能會碰到一些問題，這些都是很重要的經驗，好了那我們直接原始碼編譯吧。

  1. clone 一份 nacos 的程式碼到自己的 github 庫，然後把程式碼 clone 到本地。

    git clone https://github.com/alibaba/nacos.git

  2. 在專案的根目錄下執行以下命令（假設我們已經配置好了 java 和 maven 環境）：

    cd nacos/
mvn -Prelease-nacos -Dmaven.test.skip=true clean install -U

  3. 執行成功之後你將會看到如下圖所示的結果：

  4. 在專案的 distribution 目錄下我們就可以找到可執行程式了，包括兩個壓縮包，這兩個壓縮包就是nacos 的 github 官網上釋出的 Release 包。

ls -al distribution/target/
// change the $version to your actual path
cd distribution/target/nacos-server-$version/nacos/bin

  1. 把編譯好的兩個壓縮包拷貝出來，解壓出來直接使用，這樣就相當於我們下載了 Release 包了。

  2. 解壓後檔案結構和nacos-server一樣，我們直接執行 startup.sh 即可啟動一個單機的 Nacos 服務端了。

啟動服務端

Linux/Unix/Mac

啟動命令(standalone代表著單機模式執行，非叢集模式):

sh startup.sh -m standalone

如果您使用的是ubuntu系統，或者執行指令碼報錯提示[[符號找不到，可嘗試如下執行：

bash startup.sh -m standalone

Windows

啟動命令(standalone代表著單機模式執行，非叢集模式):

startup.cmd -m standalone

適用場景

動態配置管理的效果之後，我們知道了大概的原理了，Nacos 服務端儲存了配置資訊，客戶端連線到服務端之後，根據 dataID，group可以獲取到具體的配置資訊，當服務端的配置發生變更時，客戶端會收到通知。當客戶端拿到變更後的最新配置資訊後，就可以做自己的處理了，這非常有用，所有需要使用配置的場景都可以通過 Nacos 來進行管理。可以說 Nacos 有很多的適用場景，包括但不限於以下這些情況：

  • 資料庫連線資訊
  • 限流規則和降級開關
  • 流量的動態排程

推還是拉

瞭解了 Nacos 的配置管理的功能了，但是有一個問題我們需要弄明白，那就是 Nacos 客戶端是怎麼實時獲取到 Nacos 服務端的最新資料的。其實客戶端和服務端之間的資料互動，無外乎兩種情況：

  1. 服務端推資料給客戶端
  2. 客戶端從服務端拉資料

建立 ConfigService

首先是建立了一個 ConfigService。而 ConfigService 是通過 ConfigFactory 類建立的，如下圖所示：

這裡並沒有通過單例或者快取技術，也就是說每次呼叫都會重新建立一個 ConfigService的例項。

例項化 ConfigService

來看下 NacosConfigService 的構造方法，看看 ConfigService 是怎麼例項化的，如下圖所示：

例項化時主要是初始化了兩個物件，他們分別是：HttpAgent和ClientWorker

HttpAgent

agent 是通過裝飾著模式實現的，ServerHttpAgent 是實際工作的類，MetricsHttpAgent 在內部也是呼叫了 ServerHttpAgent 的方法，另外加上了一些統計操作，所以我們只需要關心 ServerHttpAgent 的功能就可以了。

ClientWorker

agent 實際是在 ClientWorker 中發揮能力的，下面我們來看下 ClientWorker 類，以下是 ClientWorker 的構造方法，如下圖所示：

可以看到 ClientWorker 除了將 HttpAgent 維持在自己內部，還建立了兩個執行緒池：

  • 第一個執行緒池是隻擁有一個執行緒用來執行定時任務的 executor，executor 每隔 10ms 就會執行一次 checkConfigInfo() 方法，從方法名上可以知道是每 10 ms 檢查一次配置資訊。

  • 第二個執行緒池是一個普通的執行緒池，從 ThreadFactory 的名稱可以看到這個執行緒池是做長輪詢的。

現在讓我們來看下 executor 每 10ms 執行的方法到底是幹什麼的，如下圖所示：

  • checkConfigInfo方法是取出了一批任務，提交給 executorService 執行緒池去執行，執行的任務就是 LongPollingRunnable，每個任務都有一個 taskId。

  • LongPollingRunnable做了什麼，主要分為兩部分，第一部分是檢查本地的配置資訊，第二部分是獲取服務端的配置資訊然後更新到本地。

本地檢查

首先取出與該 taskId 相關的 CacheData，然後對 CacheData 進行檢查，包括本地配置檢查和監聽器的 md5 檢查，本地檢查主要是做一個故障容錯，當服務端掛掉後，Nacos 客戶端可以從本地的檔案系統中獲取相關的配置資訊，如下圖所示：

通過跟蹤 checkLocalConfig 方法，可以看到 Nacos 將配置資訊儲存在了

~/nacos/config/fixed-{address}_8848_nacos/snapshot/DEFAULT_GROUP/{dataId}
服務端檢查

  1. 通過 checkUpdateDataIds() 方法從服務端獲取那些值發生了變化的 dataId 列表，

  2. 通過 getServerConfig 方法，根據 dataId 到服務端獲取最新的配置資訊，接著將最新的配置資訊儲存到 CacheData 中。

  3. 呼叫 CacheData 的 checkListenerMd5 方法。

可以看到，在該任務的最後，也就是在 finally 中又重新通過 executorService 提交了本任務。

ConfigListener

ConfigService 來新增一個 Listener 了，最終是呼叫了 ClientWorker 的 addTenantListeners 方法，如下圖所示：

該方法分為兩個部分，首先根據 dataId，group 和當前的場景獲取一個 CacheData 物件，然後將當前要新增的 listener 物件新增到 CacheData 中去。

也就是說 listener 最終是被這裡的 CacheData 所持有了，那 listener 的回撥方法 receiveConfigInfo 就應該是在 CacheData 中觸發的。

我們發現 CacheData 是出現頻率非常高的一個類，在 LongPollingRunnable 的任務中，幾乎所有的方法都圍繞著 CacheData 類，現在新增 Listener 的時候，實際上該 Listener 也被委託給了 CacheData，那我們要重點關注下 CacheData 類了。

CacheData

首先讓我們來看一下 CacheData 中的成員變數，如下圖所示：

可以看到除了 dataId，group，content，taskId 這些跟配置相關的屬性，還有兩個比較重要的屬性：listeners、md5。

listeners 是該 CacheData 所關聯的所有 listener，不過不是儲存的原始的 Listener 物件，而是包裝後的 ManagerListenerWrap 物件，該物件除了持有 Listener 物件，還持有了一個 lastCallMd5 屬性。

另外一個屬性 md5 就是根據當前物件的 content 計算出來的 md5 值。

觸發回撥

ConfigService 的 Listener 是在什麼時候觸發回撥方法 receiveConfigInfo 的。

在 ClientWorker 中的定時任務中，啟動了一個長輪詢的任務：LongPollingRunnable，該任務多次執行了 cacheData.checkListenerMd5() 方法，那現在就讓我們來看下這個方法到底做了些什麼，如下圖所示：

該方法會檢查 CacheData 當前的 md5 與 CacheData 持有的所有 Listener 中儲存的 md5 的值是否一致，如果不一致，就執行一個安全的監聽器的通知方法：safeNotifyListener，通知 Listener 的使用者，該 Listener 所關注的配置資訊已經發生改變了。

safeNotifyListener 方法

Md5何時變更

那 CacheData 的 md5 值是何時發生改變的呢？我們可以回想一下，在上面的 LongPollingRunnable 所執行的任務中，在獲取服務端發生變更的配置資訊時，將最新的 content 資料寫入了 CacheData 中，我們可以看下該方法如下：

可以看到是在長輪詢的任務中，當服務端配置資訊發生變更時，客戶端將最新的資料獲取下來之後，儲存在了 CacheData 中，同時更新了該 CacheData 的 md5 值，所以當下次執行 checkListenerMd5 方法時，就會發現當前 listener 所持有的 md5 值已經和 CacheData 的 md5 值不一樣了，也就意味著服務端的配置資訊發生改變了，這時就需要將最新的資料通知給 Listener 的持有者。

至此配置中心的完整流程已經分析完畢了，可以發現，Nacos 並不是通過推的方式將服務端最新的配置資訊傳送給客戶端的，而是客戶端維護了一個長輪詢的任務，定時去拉取發生變更的配置資訊，然後將最新的資料推送給 Listener 的持有者。

客戶端是通過一個定時任務來檢查自己監聽的配置項的資料的，一旦服務端的資料發生變化時，客戶端將會獲取到最新的資料，並將最新的資料儲存在一個 CacheData 物件中，然後會重新計算 CacheData 的 md5 屬性的值，此時就會對該 CacheData 所繫結的 Listener 觸發 receiveConfigInfo 回撥。

拉的優勢

客戶端拉取服務端的資料與服務端推送資料給客戶端相比，優勢在哪呢，為什麼 Nacos 不設計成主動推送資料，而是要客戶端去拉取呢？如果用推的方式，服務端需要維持與客戶端的長連線，這樣的話需要耗費大量的資源，並且還需要考慮連線的有效性，例如需要通過心跳來維持兩者之間的連線。而用拉的方式，客戶端只需要通過一個無狀態的 http 請求即可獲取到服務端的資料。

此外考慮到服務端故障的問題，客戶端將最新資料獲取後會儲存在本地的 snapshot 檔案中，以後會優先從檔案中獲取配置資訊的值。

相關文章