來源：三友的java日記

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

本文大綱

配置中心的概述

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

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

配置中心的核心功能

一個(gè)配置中心的核心功能其實(shí)主要包括兩個(gè)：

配置的存取

配置變更的通知

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

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

手?jǐn)]一個(gè)簡(jiǎn)易的配置中心

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

一、文件工程整體分析

文件工程整體分為客戶端與服務(wù)端

服務(wù)端：?jiǎn)为?dú)部署的一個(gè)web應(yīng)用，端口是8888，提供了對(duì)于配置增刪改查的http接口

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

二、服務(wù)端實(shí)現(xiàn)詳解

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

在配置中心存儲(chǔ)配置的時(shí)候，需要指明以下信息

publicclassConfigFile{

privateStringfileId;

privateStringname;

privateStringextension;

privateStringcontent;

privateLonglastUpdateTimestamp;

}

fileId： 文件的唯一id，由配置中心服務(wù)端在新增配置文件存儲(chǔ)的時(shí)候自動(dòng)生成，全局唯一

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

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

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

lastUpdateTimestamp： 上一次文件更新的時(shí)間戳。當(dāng)文件存儲(chǔ)或者更新的時(shí)候，需要更新時(shí)間戳，這個(gè)字段是用來判斷文件是否有改動(dòng)

2、文件存儲(chǔ)層ConfigFileStorage

對(duì)于文件存儲(chǔ)層，我提供了一個(gè)ConfigFileStorage接口，

publicinterfaceConfigFileStorage{

voidsave(ConfigFileconfigFile);

voidupdate(ConfigFileconfigFile);

voiddelete(StringfileId);

ConfigFileselectByFileId(StringfileId);

ListselectAll();

}

這個(gè)接口提供了對(duì)于配置存儲(chǔ)的crud操作，目前我已經(jīng)實(shí)現(xiàn)了基于內(nèi)存和磁盤文件的存儲(chǔ)的代碼

可以在項(xiàng)目啟動(dòng)的時(shí)候，在配置文件指定是基于磁盤文件存儲(chǔ)還是基于內(nèi)存存儲(chǔ)，默認(rèn)是基于磁盤文件存儲(chǔ)。

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

3、ConfigController

ConfigController提供了對(duì)于配置文件的crud的http接口

ConfigController是通過調(diào)用ConfigManager來完成配置文件的crud

4、ConfigManager

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

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

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

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

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

客戶端工程代碼如下

1、ConfigFileChangedListener

ConfigFileChangedListener

配置變動(dòng)的監(jiān)聽器，當(dāng)客戶端對(duì)某個(gè)配置監(jiān)聽的時(shí)候，如果這個(gè)配置的內(nèi)容有變化的話，客戶端就會(huì)回調(diào)這個(gè)監(jiān)聽器，傳入最新的配置

2、ConfigService

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

使用示例：

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

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

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

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

首先對(duì)于客戶端來說，要想知道哪個(gè)配置文件進(jìn)行了改動(dòng)，有兩種方式

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

第二種方式就是基于pull模式來實(shí)現(xiàn)?？蛻舳硕〞r(shí)主動(dòng)去服務(wù)端拉取配置文件，判斷文件內(nèi)容是否有變動(dòng)，一旦有變動(dòng)就進(jìn)行監(jiān)聽器的回調(diào)。這種實(shí)現(xiàn)相比push來說簡(jiǎn)單不少，因?yàn)榉?wù)端不需要關(guān)心客戶端的信息，所有的操作都由客戶端來完成。但是這個(gè)定時(shí)的時(shí)間間隔不好控制，太長(zhǎng)可能會(huì)導(dǎo)致時(shí)實(shí)性差，太短會(huì)導(dǎo)致可能無效請(qǐng)求過多，因?yàn)榕渲脡焊赡軟]有變化。

但是這里我選擇了第二種方式，因?yàn)閷?shí)現(xiàn)起來簡(jiǎn)單。。

變動(dòng)通知代碼實(shí)現(xiàn)

到這，一個(gè)簡(jiǎn)單的配置中心的服務(wù)端的和客戶端就完成了，這里畫張圖來總結(jié)一下配置中心的核心原理。

接下來就把這個(gè)簡(jiǎn)易的配置中心整合到SpringCloud中。

SpringCloud配置中心的原理

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

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

這個(gè)容器在啟動(dòng)的時(shí)候會(huì)干兩件事：

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

加載所有spring.factories文件中的鍵為org.springframework.cloud.bootstrap.BootstrapConfiguration對(duì)應(yīng)的配置類，將這些配置類注入到這個(gè)容器中，注意這里是不會(huì)加載@EnbaleAutoConfiguration自動(dòng)裝配的類

當(dāng)這兩件事都做好之后，會(huì)從這個(gè)容器中獲取到所有的PropertySourceLocator這個(gè)接口的實(shí)現(xiàn)類對(duì)象，依次調(diào)用locate方法。

PropertySourceLocator

這個(gè)類很重要，先來看看注釋

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)境定位(可能是遠(yuǎn)程)屬性源的策略。實(shí)現(xiàn)不應(yīng)該失敗，除非它們打算阻止應(yīng)用程序啟動(dòng)。

說的簡(jiǎn)單點(diǎn)就是用來定位到（也就是獲取的意思）項(xiàng)目啟動(dòng)所需要的屬性信息。同時(shí)要注意到括號(hào)內(nèi)的 可能是遠(yuǎn)程 告訴我們一個(gè)很重要的信息，那就是獲取的配置信息不僅僅可以存在本地，而且還可以存在遠(yuǎn)程。

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

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

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

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

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

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

舉個(gè)例子

UserService

當(dāng)在類上加一個(gè)@RefreshScope注解之后，那么當(dāng)配置中心sanyou.username的屬性有變化的時(shí)候，那么此時(shí)注入的username也會(huì)跟著變化。

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

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

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

RefreshEventListener

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

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

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

對(duì)于在類上加了@RefreshScope注解的Bean，Spring在生成這個(gè)Bean的時(shí)候，會(huì)進(jìn)行動(dòng)態(tài)代理。

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

生成一個(gè)UserService對(duì)象，將從配置中心拉到的配置sanyou.username注入給UserService對(duì)象

由于加了@RefreshScope，會(huì)給上一步驟生成的UserService對(duì)象進(jìn)行代理，生成一個(gè)代理對(duì)象

最后真正暴露出去供我們使用的其實(shí)是就是這個(gè)代理對(duì)象，如圖所示

由于暴露出去的是一個(gè)代理對(duì)象，所以當(dāng)調(diào)用getUsername方法的時(shí)候，其實(shí)是調(diào)用UserService的代理對(duì)象的getUsername方法，從而就會(huì)找到UserService，調(diào)用UserService的getUsername獲取到username的屬性值。

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

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

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

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

到這應(yīng)該就知道為什么加了@RefreshScope的對(duì)象能夠?qū)崿F(xiàn)配置的自動(dòng)刷新了，其實(shí)依靠的是動(dòng)態(tài)代理完成的。

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

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

3.1啟動(dòng)時(shí)加載配置流程

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

3.2配置刷新源碼流程

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

整合SpringCloud和測(cè)試

一、整合SpringCloud

1、ConfigCenterProperties

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

2、ConfigCenterPropertySourceLocator

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

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

3、ConfigContextRefresher

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

因?yàn)樯厦嫣岬?，?dāng)配置發(fā)生變化的時(shí)候，需要發(fā)布一個(gè)RefreshEvent事件來觸發(fā)刷新配置的功能。

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

4、兩個(gè)配置類

4.1 ConfigCenterBootstrapConfiguration

配置了ConfigCenterPropertySourceLocator、ConfigCenterProperties、ConfigService

4.2 ConfigCenterAutoConfiguration

配置了ConfigContextRefresher、ConfigCenterProperties、ConfigService

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

這里有個(gè)需要注意，前面說過，SpringCloud會(huì)創(chuàng)建新的容器來加載配置，而這個(gè)容器只會(huì)加載spring.factories文件中鍵為@BootstrapConfiguration注解的配置類，所以需要將ConfigCenterBootstrapConfiguration跟BootstrapConfiguration配對(duì)，因?yàn)镃onfigCenterBootstrapConfiguration配置了ConfigCenterPropertySourceLocator。

好了，到這里真的就完成了對(duì)SpringCloud整合了。

二、測(cè)試

1、新增一個(gè)配置文件

啟動(dòng)配置中心的server端，然后打開ApiPost，新增一個(gè)配置文件

新增文件類型為properties一個(gè)配置，內(nèi)容為sanyou.username=sanyou鍵值對(duì)，當(dāng)然可以寫很多鍵值對(duì)，我這里就寫了一個(gè)，新增成功之后，返回了文件的id：79765c73-c1ef-4ea2-ba77-5d27a64c4685

2、測(cè)試客戶端

這里我為了方便，就把測(cè)試代碼跟客戶端寫在同一個(gè)服務(wù)了，正常情況肯定是把跟SpringCloud代碼打成一個(gè)依賴引到項(xiàng)目中。

在bootstrap.yml文件中配置配置中心的相關(guān)信息

配置中心服務(wù)端的地址是：localhost:8888

使用的配置文件的id是剛才創(chuàng)建的：79765c73-c1ef-4ea2-ba77-5d27a64c4685

測(cè)試Controller

提供一個(gè)接口，注入上面提到的UserService

啟動(dòng)項(xiàng)目，調(diào)用接口

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

此時(shí)這次調(diào)用的返回值就是：sanyou

接下來測(cè)試一下自動(dòng)刷新屬性的功能

現(xiàn)在修改一下配置中心的sanyou.username為sanyou666

靜靜等待5秒鐘。。

此時(shí)控制臺(tái)打印出 Refresh keys changed: [sanyou.username] ，也就是sanyou.username屬性變了

此時(shí)再次獲取username

可以看出，UserService代理對(duì)象沒變，但是UserService對(duì)象已經(jīng)變成了com.sanyou.configcenter.test.UserService@4237b3cd

此時(shí)獲取到的username就已經(jīng)變成了sanyou666

所以，到這里就成功將我們自己寫的那個(gè)簡(jiǎn)易版的配置中心整合到了SpringCloud中了。

不足和改進(jìn)

雖然我們這里的配置中心有了配置中心基本的功能，但是其實(shí)還有很多的不足和可以改進(jìn)的地方。

1、配置變更推送問題

問題前面也說過，在判斷配置是否變更的時(shí)候，這里是每隔5s從服務(wù)端獲取一次，這里就會(huì)可能5s之后才能感知到配置有變化，達(dá)不到真正時(shí)實(shí)的效果，并且由于這里是由客戶端根據(jù)來判斷，會(huì)導(dǎo)致無效的請(qǐng)求過多，因?yàn)榭赡芘渲脡焊鶝]有變化，但是還是每隔5s獲取一次配置信息，白白浪費(fèi)資源

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

2、高可用問題

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

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

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

至于序列化協(xié)議，這里選擇了json協(xié)議，因?yàn)楹芎?jiǎn)單、常見、使用范圍廣、跨語言，當(dāng)然也可以選擇其它的，比如hessian序列化協(xié)議等等。

4、多租戶隔離

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

5、鑒權(quán)

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

6、控制頁面

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

最后，本文代碼地址：

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

審核編輯：湯梓紅