來源：三友的java日記

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

本文大綱

配置中心的概述

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

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

配置中心的核心功能

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

配置的存取

配置變更的通知

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

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

手擼一個簡易的配置中心

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

一、文件工程整體分析

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

服務端：單獨部署的一個web應用，端口是8888，提供了對于配置增刪改查的http接口

客戶端（SDK）：業(yè)務系統(tǒng)需要引用對應的依賴，封裝了跟服務端交互的代碼

二、服務端實現(xiàn)詳解

1、配置文件的數(shù)據(jù)存儲模型ConfigFile

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

publicclassConfigFile{

privateStringfileId;

privateStringname;

privateStringextension;

privateStringcontent;

privateLonglastUpdateTimestamp;

}

fileId： 文件的唯一id，由配置中心服務端在新增配置文件存儲的時候自動生成，全局唯一

name： 就是文件的名字，沒有什么要求，見名知意就行

extension： 文件后綴名，指的是該配置是什么類型的文件，比如是properties、yml等

content： 就是配置文件的內容，不同的后綴名有不同的格式要求

lastUpdateTimestamp： 上一次文件更新的時間戳。當文件存儲或者更新的時候，需要更新時間戳，這個字段是用來判斷文件是否有改動

2、文件存儲層ConfigFileStorage

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

publicinterfaceConfigFileStorage{

voidsave(ConfigFileconfigFile);

voidupdate(ConfigFileconfigFile);

voiddelete(StringfileId);

ConfigFileselectByFileId(StringfileId);

ListselectAll();

}

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

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

當然，如果想把配置信息存儲到數(shù)據(jù)庫，只要新增一個存儲到數(shù)據(jù)的實現(xiàn)就行。

3、ConfigController

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

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

4、ConfigManager

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

這樣配置中心的配的存取的功能就實現(xiàn)了。

所以，服務端還是比較簡單的。其實就是跟平時寫的業(yè)務系統(tǒng)的crud沒什么區(qū)別，就是將數(shù)據(jù)庫存儲替換成了磁盤文件的存儲。

至于前面說的配置文件變更通知的功能，我是基于客戶端來實現(xiàn)的。

三、客戶端的實現(xiàn)

客戶端工程代碼如下

1、ConfigFileChangedListener

ConfigFileChangedListener

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

2、ConfigService

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

使用示例：

//創(chuàng)建一個ConfigService，傳入配置中心服務端的地址
ConfigServiceconfigService=newConfigService("localhost:8888");

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

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

這里說一下配置變更通知的實現(xiàn)原理。

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

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

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

但是這里我選擇了第二種方式，因為實現(xiàn)起來簡單。。

變動通知代碼實現(xiàn)

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

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

SpringCloud配置中心的原理

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

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

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

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

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

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

PropertySourceLocator

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

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

扔到有道翻譯如下：

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

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

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

所以從這個注釋就可以發(fā)現(xiàn)，原來PropertySourceLocator就是起到在SpringCloud環(huán)境下從配置中心獲取配置的作用。

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

2、如何實現(xiàn)注入到Bean中的屬性動態(tài)刷新？

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

那么在SpringCloud環(huán)境下，是如何實現(xiàn)注入到Bean中的屬性動態(tài)刷新的呢？

舉個例子

UserService

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

這種變化是如何實現(xiàn)的呢？

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

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

RefreshEventListener

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

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

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

對于在類上加了@RefreshScope注解的Bean，Spring在生成這個Bean的時候，會進行動態(tài)代理。

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

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

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

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

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

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

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

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

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

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

3、源碼執(zhí)行流程圖

由于上面并沒有涉及整體執(zhí)行流程的源碼分析，所以我特地結合源碼畫了兩張源碼的執(zhí)行流程圖，有興趣的小伙伴可以對照著圖翻一翻具體的源碼。

3.1啟動時加載配置流程

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

3.2配置刷新源碼流程

這個圖新增了對于加了@ConfigurationProperties數(shù)據(jù)綁定的對象原理的分析。

整合SpringCloud和測試

一、整合SpringCloud

1、ConfigCenterProperties

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

2、ConfigCenterPropertySourceLocator

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

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

3、ConfigContextRefresher

這個是用來注冊文件變動的監(jiān)聽器，來刷新文件的信息的。

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

核心的邏輯就是當項目啟動的時候，對所使用的配置文件進行注冊一個監(jiān)聽器，監(jiān)聽器的實現(xiàn)就是當發(fā)生配置改動的時候，就發(fā)布一個RefreshEvent事件。

4、兩個配置類

4.1 ConfigCenterBootstrapConfiguration

配置了ConfigCenterPropertySourceLocator、ConfigCenterProperties、ConfigService

4.2 ConfigCenterAutoConfiguration

配置了ConfigContextRefresher、ConfigCenterProperties、ConfigService

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

這里有個需要注意，前面說過，SpringCloud會創(chuàng)建新的容器來加載配置，而這個容器只會加載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是剛才創(chuàng)建的：79765c73-c1ef-4ea2-ba77-5d27a64c4685

測試Controller

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

啟動項目，調用接口

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

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

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

現(xiàn)在修改一下配置中心的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之后才能感知到配置有變化，達不到真正時實的效果，并且由于這里是由客戶端根據(jù)來判斷，會導致無效的請求過多，因為可能配置壓根沒有變化，但是還是每隔5s獲取一次配置信息，白白浪費資源

解決這個問題可以換成上面提到的push方式來做，或者將輪詢方式改成長輪詢的方式實現(xiàn)也是可以的。

2、高可用問題

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

3、通信協(xié)議和序列化協(xié)議

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

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

4、多租戶隔離

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

5、鑒權

鑒權是一個系統(tǒng)比較常見的東西，這里就不做過多贅述

6、控制頁面

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

最后，本文代碼地址：

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

審核編輯：湯梓紅