擼了一個簡易的配置中心，順帶整合到了SpringCloud

大家好，我是三友~~ 最近突然心血來潮（就是閑的）就想著擼一個簡單的配置中心，順便也照葫蘆畫瓢給整合到SpringCloud。本文大綱配置中心的概述隨著歷史的車輪不斷的前進，技術不斷的進步，單體架構的系統都逐漸轉向微服務架構。雖然微服務架構有諸多優點，但是隨著越來越多的服務實例的數量，配置的不 ...

大家好，我是三友~~

最近突然心血來潮（就是閑的）就想著擼一個簡單的配置中心，順便也照葫蘆畫瓢給整合到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。