大家好，我是三友~~

最近突然心血來潮（就是閑的）就想着擼一個簡單的配置中心，順便也照葫蘆畫瓢給整合到SpringCloud。

本文大綱

配置中心的概述

隨着歷史的車輪不斷的前進，技術不斷的進步，單體架構的系統都逐漸轉向微服務架構。雖然微服務架構有諸多優點，但是隨着越來越多的服務實例的數量，配置的不斷增多，傳統的配置文件方式不能再繼續適用業務的發展，所以急需一種可以統一管理配置文件應用，在此之下配置中心就誕生了。

所以配置中心就是用來統一管理各種服務配置的一個組件，本質上就是一個web應用。

配置中心的核心功能

一個配置中心的核心功能其實主要包括兩個：

• 配置的存取
• 配置變更的通知

配置的存取是配置中心不可缺失的功能，配置中心需要能夠將配置進行保存，存在磁盤文件也好，又或是數據庫也罷，總之需要持久化，同時配置中心也得提供配置查詢的功能。

配置變化的通知也是一個很重要的功能，一旦配置中心的配置有變動的話，那麼使用到這個配置的客戶端就需要知道這個配置有變動，從而可以做到相應的變動的操作。

手擼一個簡易的配置中心

上文分析了一個配置中心的核心功能，接下來就實現這兩個核心的功能。

一、文件工程整體分析

文件工程整體分為客戶端與服務端

• 服務端：單獨部署的一個web應用，端口是8888，提供了對於配置增刪改查的http接口
• 客戶端（SDK）：業務系統需要引用對應的依賴，封裝了跟服務端交互的代碼

二、服務端實現詳解

1、配置文件的數據存儲模型ConfigFile

在配置中心存儲配置的時候，需要指明以下信息

public class ConfigFile {

    private String fileId;

    private String name;

    private String extension;

    private String content;

    private Long lastUpdateTimestamp;

}

• fileId： 文件的唯一id，由配置中心服務端在新增配置文件存儲的時候自動生成，全局唯一
• name： 就是文件的名字，沒有什麼要求，見名知意就行
• extension： 文件後綴名，指的是該配置是什麼類型的文件，比如是properties、yml等
• content： 就是配置文件的內容，不同的後綴名有不同的格式要求
• lastUpdateTimestamp： 上一次文件更新的時間戳。當文件存儲或者更新的時候，需要更新時間戳，這個字段是用來判斷文件是否有改動

2、文件存儲層ConfigFileStorage

對於文件存儲層，我提供了一個ConfigFileStorage接口，

public interface ConfigFileStorage {

    void save(ConfigFile configFile);

    void update(ConfigFile configFile);

    void delete(String fileId);

    ConfigFile selectByFileId(String fileId);

    List<ConfigFile> selectAll();

}

這個接口提供了對於配置存儲的crud操作，目前我已經實現了基於內存和磁盤文件的存儲的代碼

可以在項目啟動的時候，在配置文件指定是基於磁盤文件存儲還是基於內存存儲，默認是基於磁盤文件存儲。

當然，如果想把配置信息存儲到數據庫，只要新增一個存儲到數據的實現就行。

3、ConfigController

ConfigController提供了對於配置文件的crud的http接口

ConfigController是通過調用ConfigManager來完成配置文件的crud

4、ConfigManager

其實就是一個service層，就是簡單的參數封裝，最終是調用ConfigFileStorage存儲層的實現來完成配置的存儲功能。

這樣配置中心的配的存取的功能就實現了。

所以，服務端還是比較簡單的。其實就是跟平時寫的業務系統的crud沒什麼區別，就是將數據庫存儲替換成了磁盤文件的存儲。

至於前面說的配置文件變更通知的功能，我是基於客戶端來實現的。

三、客戶端的實現

客戶端工程代碼如下

1、ConfigFileChangedListener

配置變動的監聽器，當客戶端對某個配置監聽的時候，如果這個配置的內容有變化的話，客戶端就會回調這個監聽器，傳入最新的配置

2、ConfigService

封裝了客戶端的核心功能，可以添加對某個文件的監聽器和獲取某個文件的配置內容。

使用示例：

// 創建一個ConfigService，傳入配置中心服務端的地址
ConfigService configService = new ConfigService("localhost:8888");

// 從服務端獲取配置文件的內容，文件的id是新增配置文件時候自動生成
ConfigFile config = configService.getConfig("69af6110-31e4-4cb4-8c03-8687cf012b77");

// 對某個配置文件進行監聽
configService.addListener("69af6110-31e4-4cb4-8c03-8687cf012b77", new ConfigFileChangedListener() {
    @Override
    public void onFileChanged(ConfigFile configFile) {
        System.out.printf("fileId=%s配置文件有變動，最新內容為:%s%n", configFile.getFileId(), configFile.getContent());
    }
});

這裡說一下配置變更通知的實現原理。

首先對於客戶端來說，要想知道哪個配置文件進行了改動，有兩種方式

第一種是通過push的方式來實現。當配置文件發生變動的時候，服務端主動將變動的配置文件push給客戶端。這種方式實現起來比較麻煩，一方面是服務端還得存儲客戶端的服務的信息，因為服務端得知道push到哪台服務器上；另一方面，客戶端需要提供一個接口來接收服務端push的請求，所以這種方式整體實現起來比較麻煩。但是這種push方式時實性比較好，一旦配置文件有變動，第一時間客戶端就能夠知道配置有變動。

第二種方式就是基於pull模式來實現。客戶端定時主動去服務端拉取配置文件，判斷文件內容是否有變動，一旦有變動就進行監聽器的回調。這種實現相比push來說簡單不少，因為服務端不需要關心客戶端的信息，所有的操作都由客戶端來完成。但是這個定時的時間間隔不好控制，太長可能會導致時實性差，太短會導致可能無效請求過多，因為配置壓根可能沒有變化。

但是這裡我選擇了第二種方式，因為實現起來簡單。。

到這，一個簡單的配置中心的服務端的和客戶端就完成了，這裡畫張圖來總結一下配置中心的核心原理。

接下來就把這個簡易的配置中心整合到SpringCloud中。

SpringCloud配置中心的原理

1、項目啟動是如何從配置中心加載數據的？

在SpringCloud環境下，當項目啟動的時候，在SpringBoot應用容器創建之前，會先創建一個容器，這個容器非常重要，這個容器是用來跟配置中心交互，拉取配置的。

這個容器在啟動的時候會幹兩件事：

• 加載bootstrap配置文件，這就是為什麼配置中心的配置信息需要寫在bootstrap配置文件的重要原因

• 加載所有spring.factories文件中的鍵為org.springframework.cloud.bootstrap.BootstrapConfiguration對應的配置類，將這些配置類注入到這個容器中，注意這裡是不會加載@EnbaleAutoConfiguration自動裝配的類

當這兩件事都做好之後，會從這個容器中獲取到所有的PropertySourceLocator這個接口的實現類對象，依次調用locate方法。

這個類很重要，先來看看注釋

Strategy for locating (possibly remote) property sources for the Environment. Implementations should not fail unless they intend to prevent the application from starting.

扔到有道翻譯如下：

為環境定位(可能是遠程)屬性源的策略。實現不應該失敗，除非它們打算阻止應用程序啟動。

說的簡單點就是用來定位到（也就是獲取的意思）項目啟動所需要的屬性信息。同時要注意到括號內的 可能是遠程 告訴我們一個很重要的信息，那就是獲取的配置信息不僅僅可以存在本地，而且還可以存在遠程。

遠程？作者這裡就差直接告訴你可以從配置中心獲取了。。

所以從這個注釋就可以發現，原來PropertySourceLocator就是起到在SpringCloud環境下從配置中心獲取配置的作用。

PropertySourceLocator是一個接口，所以只要不同的配置中心實現這個接口，那麼不同的配置中心就可以整合到了SpringCloud，從而實現從配置中心加載配置屬性到Spring環境中了。

2、如何實現注入到Bean中的屬性動態刷新？

上面講了在項目啟動的時候SpringCloud是如何從配置中心加載數據的，主要是通過新建一個容器，加載bootstrap配置文件和一些配置類，最後會調用PropertySourceLocator來從配置中心獲取到配置信息。

那麼在SpringCloud環境下，是如何實現注入到Bean中的屬性動態刷新的呢？

舉個例子

當在類上加一個@RefreshScope註解之後，那麼當配置中心sanyou.username的屬性有變化的時候，那麼此時注入的username也會跟着變化。

這種變化是如何實現的呢？

SpringCloud中規定，當配置中心客戶端一旦感知到服務端的某個配置有變化的時候，需要發佈一個RefreshEvent事件來告訴SpringCloud配置有變動。

在SpringCloud中RefreshEventListener類會去監聽這個事件，一旦監聽到這個事件，就會進行兩步操作來刷新注入到對象的屬性。

• 從配置中心再次拉取屬性值，而這個拉取的代碼邏輯跟項目啟動時拉取的屬性值核心邏輯幾乎是一樣的，也是創建一個新的spring容器，加載配置文件和配置類，最後通過PropertySourceLocator獲取屬性，這一部分核心的代碼邏輯是復用的。

• 有了最新的屬性之後，就開始刷新對象的屬性。

刷新的邏輯實現的非常的巧妙，可不是你以為的簡單地將新的屬性重新注入對象中，而是通過動態代理的方式來實現的。

對於在類上加了@RefreshScope註解的Bean，Spring在生成這個Bean的時候，會進行動態代理。

這裡我們就上面舉個UserService例子來分析，在生成UserService有兩步操作

• 生成一個UserService對象，將從配置中心拉到的配置sanyou.username注入給UserService對象

• 由於加了@RefreshScope，會給上一步驟生成的UserService對象進行代理，生成一個代理對象

最後真正暴露出去供我們使用的其實是就是這個代理對象，如圖所示

由於暴露出去的是一個代理對象，所以當調用getUsername方法的時候，其實是調用UserService的代理對象的getUsername方法，從而就會找到UserService，調用UserService的getUsername獲取到username的屬性值。

當配置中心的配置有變動刷新屬性的時候，Spring會把UserService這個對象（非代理對象）給銷毀，重新創建一個UserService對象，注入最新的屬性值。

當再次通過UserService代理對象獲取username屬性的時候，就會找最新創建的那個UserService對象，此時就能獲取到最新的屬性值。

配置每刷新一次，UserService對象就會先銷毀再重新創建，但是暴露出去的UserService代理對象一直不會變。

這樣，對於使用者來說，好像是UserService對象的屬性自動刷新了，其實本質上是UserService代理對象最終找的UserService對象發生了變化。

到這應該就知道為什麼加了@RefreshScope的對象能夠實現配置的自動刷新了，其實依靠的是動態代理完成的。

3、源碼執行流程圖

由於上面並沒有涉及整體執行流程的源碼分析，所以我特地結合源碼畫了兩張源碼的執行流程圖，有興趣的小夥伴可以對照着圖翻一翻具體的源碼。

3.1啟動時加載配置流程

最終從配置中心獲取到的屬性會放在項目啟動時創建的 Environment 對象裏面。

3.2配置刷新源碼流程

這個圖新增了對於加了@ConfigurationProperties數據綁定的對象原理的分析。

整合SpringCloud和測試

一、整合SpringCloud

1、ConfigCenterProperties

配置中心的配置信息，這裡需要配置配置中心服務端的地址和使用的配置文件的id。當然這部分信息需要寫在bootstrap配置文件中，前面也說過具體的原因。

2、ConfigCenterPropertySourceLocator

上面分析知道，項目啟動和刷新的時候，SpringCloud是通過PropertySourceLocator的實現從配置中心加載配置信息，所以這裡就得實現一下

核心的邏輯就是根據所配置的文件的id，從配置中心拉取配置信息，然後解析配置。

3、ConfigContextRefresher

這個是用來註冊文件變動的監聽器，來刷新文件的信息的。

因為上面提到，當配置發生變化的時候，需要發佈一個RefreshEvent事件來觸發刷新配置的功能。

核心的邏輯就是當項目啟動的時候，對所使用的配置文件進行註冊一個監聽器，監聽器的實現就是當發生配置改動的時候，就發佈一個RefreshEvent事件。

4、兩個配置類

4.1 ConfigCenterBootstrapConfiguration

配置了ConfigCenterPropertySourceLocator、ConfigCenterProperties、ConfigService

4.2 ConfigCenterAutoConfiguration

配置了ConfigContextRefresher、ConfigCenterProperties、ConfigService

最後需要將兩個配置類在spring.factories配置一下。

這裡有個需要注意，前面說過，SpringCloud會創建新的容器來加載配置，而這個容器只會加載spring.factories文件中鍵為@BootstrapConfiguration註解的配置類，所以需要將ConfigCenterBootstrapConfiguration跟BootstrapConfiguration配對，因為ConfigCenterBootstrapConfiguration配置了ConfigCenterPropertySourceLocator。

好了，到這裡真的就完成了對SpringCloud整合了。

二、測試

1、新增一個配置文件

啟動配置中心的server端，然後打開ApiPost，新增一個配置文件

新增文件類型為properties一個配置，內容為sanyou.username=sanyou鍵值對，當然可以寫很多鍵值對，我這裡就寫了一個，新增成功之後，返回了文件的id：79765c73-c1ef-4ea2-ba77-5d27a64c4685

2、測試客戶端

這裡我為了方便，就把測試代碼跟客戶端寫在同一個服務了，正常情況肯定是把跟SpringCloud代碼打成一個依賴引到項目中。

在bootstrap.yml文件中配置配置中心的相關信息

• 配置中心服務端的地址是：localhost:8888
• 使用的配置文件的id是剛才創建的：79765c73-c1ef-4ea2-ba77-5d27a64c4685

測試Controller

提供一個接口，注入上面提到的UserService

啟動項目，調用接口

從斷這裡可以看出，實際注入的是一個UserService代理對象，並且最終找的是com.sanyou.configcenter.test.UserService@3a1e4fd3這個UserService對象

此時這次調用的返回值就是：sanyou

接下來測試一下自動刷新屬性的功能

現在修改一下配置中心的sanyou.username為sanyou666

靜靜等待5秒鐘。。

此時控制台打印出 Refresh keys changed: [sanyou.username] ，也就是sanyou.username屬性變了

此時再次獲取username

可以看出，UserService代理對象沒變，但是UserService對象已經變成了com.sanyou.configcenter.test.UserService@4237b3cd

此時獲取到的username就已經變成了sanyou666

所以，到這裡就成功將我們自己寫的那個簡易版的配置中心整合到了SpringCloud中了。

不足和改進

雖然我們這裡的配置中心有了配置中心基本的功能，但是其實還有很多的不足和可以改進的地方。

1、配置變更推送問題

問題前面也說過，在判斷配置是否變更的時候，這裡是每隔5s從服務端獲取一次，這裡就會可能5s之後才能感知到配置有變化，達不到真正時實的效果，並且由於這裡是由客戶端根據來判斷，會導致無效的請求過多，因為可能配置壓根沒有變化，但是還是每隔5s獲取一次配置信息，白白浪費資源

解決這個問題可以換成上面提到的push方式來做，或者將輪詢方式改成長輪詢的方式實現也是可以的，如果不清楚push、輪詢、長輪詢的，可以翻一下
RocketMQ的push消費方式實現的太聰明了這篇文章。

2、高可用問題

這裡服務端的實例只有一個，不支持集群的方式，就會有單點故障的問題，不支持高可用。在實際項目中，肯定要支持集群的方式，保證即使有服務實例掛了，整個集群仍然可以繼續對外提供服務，比如nacos就支持集群的方式，並且可以自由選擇是使用AP模式還是CP模式。

3、通信協議和序列化協議

對於通信協議，這裡為了方便，我選擇了客戶端和服務端的通信方式是基於http協議的，當然也可以自定義協議，或者使用其它的協議，比如gRPC協議。其實在nacos2.x的版本中，nacos開始全面擁抱gRPC協議了。

至於序列化協議，這裡選擇了json協議，因為很簡單、常見、使用範圍廣、跨語言，當然也可以選擇其它的，比如hessian序列化協議等等。

4、多租戶隔離

一個合格的配置中心需要能支持不同應用的隔離，還有同一個應用不同環境的隔離，這裡就圖省事，直接就是有一個文件id來表示，雖然也可以做到隔離（不同系統用不同的文件id），但是這種方式比較low。像nacos會自動根據配置的名稱和後綴名之類的，生成文件id（dataId），同時還有分組的概念，其實就是為了做到隔離的效果。

5、鑒權

鑒權是一個系統比較常見的東西，這裡就不做過多贅述

6、控制頁面

上面所有對於配置的crud都是基於ApiPost來的，但是實際怎麼也得通過一個頁面來操作吧，至於這裡我為啥不自己寫個頁面，給你個眼神自己體會~~

最後，本文代碼地址：

//github.com/sanyou3/sanyou-config-center

往期熱門文章推薦

RocketMQ保姆級教程

三萬字盤點Spring/Boot的那些常用擴展點

RocketMQ的push消費方式實現的太聰明了

一網打盡異步神器CompletableFuture

@Async註解的坑，小心

掃碼或者搜索關注公眾號 三友的java日記 ，及時乾貨不錯過，公眾號致力於通過畫圖加上通俗易懂的語言講解技術，讓技術更加容易學習，回復 面試 即可獲得一套面試真題。