摘要：同時也新增了一個。將不同的配置文件用不同的對象進(jìn)行管理。由于需要支持多個配置文件，所有需要定義一個抽象類供所有的配置管理實現(xiàn)。其實就是一個結(jié)構(gòu)的緩存，用于存放所有的配置。總結(jié)這就是本次中的升級內(nèi)容，包含了配置支持以及代碼重構(gòu)。

在前兩次的 cicada 版本中其實還不支持讀取配置文件，比如對端口、路由的配置。

因此我按照自己的想法創(chuàng)建了一個 issue ，也收集到了一些很不錯的建議。

最終其實還是按照我之前的想法來做了這個配置管理。

同時將 cicada 升級到了 v1.0.2。

在做之前是要把需求想好，到底怎樣的一個配置管理是對開發(fā)人員來說比較友好的？

我認(rèn)為有以下幾點:

可以自定義配置，并且支持不同的環(huán)境（開發(fā)、測試、生產(chǎn)）。

使用靈活。對使用者來說不要有太多的束縛。

理論上來說配置這個東西應(yīng)當(dāng)完全獨立出來，由一個配置中心來負(fù)責(zé)管理并且這樣可以與應(yīng)用解耦。

不過這樣的實現(xiàn)和當(dāng)前 cicada 的定義有些沖突，我想盡量小的依賴第三方組件并可以完全獨立運(yùn)行。

因此基于這樣的情況便有了以下的實現(xiàn)。

在看實現(xiàn)之前先看看基于目前的配置管理如何在業(yè)務(wù)中使用起來。

結(jié)合現(xiàn)在大家使用 SpringBoot 的習(xí)慣，cicada 默認(rèn)會讀取 classpath 下的 application.properties 配置文件。并且會默認(rèn)讀取其中的應(yīng)用端口以及初始路由地址。

同時也新增了一個 api。

public class MainStart {

    public static void main(String[] args) throws Exception {
        CicadaServer.start(MainStart.class,"/cicada-example") ;
    }
}

public class MainStart {

    public static void main(String[] args) throws Exception {
        CicadaServer.start(MainStart.class) ;
    }
}

這樣在不傳默認(rèn)地址的時候 cicada 會從 application.properties 中讀取。

考慮到后面可維護(hù)的情況，cicada 也支持配置各種不同的配置文件。

使用也比較簡單，只需要繼承 cicada 提供的一個抽象類即可。

public class KafkaConfiguration extends AbstractCicadaConfiguration {

    public KafkaConfiguration() {
        super.setPropertiesName("kafka.properties");
    }


}

public class RedisConfiguration extends AbstractCicadaConfiguration {


    public RedisConfiguration() {
        super.setPropertiesName("redis.properties");
    }

}

按照這樣的配置也會默認(rèn)從 classpath 讀取這兩個配置文件。

當(dāng)然這里有個前提：代碼里配置的文件名必須得和配置文件名稱相同。

那如何在業(yè)務(wù)中讀取這兩個配置文件的內(nèi)容呢？

這也簡單，代碼一看就懂：

首先需要通過 ConfigurationHolder 獲取各自不同配置的管理對象（需要顯式指定類類型）。

通過 get() 方法直接獲取配置。

同時也支持獲取 application.properties 里的配置。

同時為了支持在不同環(huán)境的使用，當(dāng)配置了啟動參數(shù)將會優(yōu)先讀取。

-Dapplication.properties=/xx/application.properties
-Dkafka.properties=/xx/kakfa.properties
-Dredis.properties=/xx/redis.properties

這樣算是基本實現(xiàn)了上述的配置要求。

要實現(xiàn)以上的功能有幾個核心點：

加載所有配置文件。

將不同的配置文件用不同的對象進(jìn)行管理。

提供簡易的接口使用。

由于 cicada 需要支持多個配置文件，所有需要定義一個抽象類供所有的配置管理實現(xiàn)。

定義比較簡單，其中有兩個重要的成員變量：

文件名稱：用于初始化時通過名稱加載配置文件。

Properties 其實就是一個 Map 結(jié)構(gòu)的緩存，用于存放所有的配置。當(dāng)然對外提供的查詢是基于它的。

接著就是在初始化時需要找出所有繼承了 AbstractCicadaConfiguration 的類。

查詢出來之后自然是要進(jìn)行遍歷同時反射創(chuàng)建對象。

由于之前已經(jīng)調(diào)用了

super.setPropertiesName("redis.properties");

來賦值配置文件名稱，所以還需要在遍歷過程中將 Properties 進(jìn)行賦值。

同時在這里也體現(xiàn)出優(yōu)先讀取的是 VM 啟動參數(shù)中的配置文件。

String systemProperty = System.getProperty(conf.getPropertiesName());

需要額外提一點的是：在查找所有用戶自定義的配置管理類時需要手動將 cicada 內(nèi)置的
ApplicationConfiguration 加入其中。

因為使用應(yīng)用的包名通過反射是查詢不出該類的。

為了方便用戶在使用時候可以隨意的讀取各個配置文件，所以還需要將反射創(chuàng)建的對象保存到一個內(nèi)部緩存中，核心代碼就是上上圖中的這段代碼：

// add configuration cache
ConfigurationHolder.addConfiguration(aClass.getName(), conf);

其中 ConfigurationHolder 的定義如下。

其實也是利用一個 Map 來存放這些對象。

這樣在使用時候只需要取出即可。

KafkaConfiguration configuration = (KafkaConfiguration) getConfiguration(KafkaConfiguration.class);
String brokerList = configuration.get("kafka.broker.list");

本次升級同時還重構(gòu)了部分代碼，比如啟動類。

現(xiàn)在看上去要清爽和直接的多：

其中也有一點需要注意的地方。

大家如果查看日志的話會發(fā)現(xiàn)應(yīng)用啟動之后會打印本次的耗時，自然就是在啟動時候記錄一個時間，初始化完畢之后記錄一個即可。

在之前的實現(xiàn)中由于都是在一個方法內(nèi)，所以直接使用就行了。

但現(xiàn)在優(yōu)化之后跨越了不同的方法和類，難道要把時間作為參數(shù)在各個方法之前傳遞嘛？

那未免太不優(yōu)雅了。

所以 ThreadLocal 就有了發(fā)揮余地。

在初始化的方法中我將當(dāng)前時間寫入：

ThreadLocalHolder.setLocalTime(System.currentTimeMillis());

在最后記錄日志的地方直接取出比較即可：

這樣使用起來就完全不需要管什么參數(shù)傳遞了。

同時 ThreadLocalHolder 的定義：

這里還是有一點需要注意，在這種長生命周期的容器中一定得要記得及時清除。

我這里的時間在查詢一次之后就不用了，所以完全放心的在 getLocalTime() 方法中刪掉。

這就是本次 v1.0.2 中的升級內(nèi)容，包含了配置支持以及代碼重構(gòu)。其中有些內(nèi)容我覺得對接觸少的同學(xué)來說還是挺有幫助的。

關(guān)于上兩次的版本介紹請查看這里：

「造個輪子」——cicada(輕量級 WEB 框架)

「造個輪子」——cicada 源碼分析

還沒點關(guān)注的朋友可以點波關(guān)注：

https://github.com/TogetherOS/cicada

也歡迎大家參與一起維護(hù)！。

同時后續(xù)關(guān)于 cicada 的更新會放慢一些。會介紹一些平時實戰(zhàn)相關(guān)的內(nèi)容，比如 Kafka 之類的，請持續(xù)關(guān)注。

你的點贊與轉(zhuǎn)發(fā)是最大的支持。