前言

在前兩次的 cicada 版本中其實還不支援讀取配置檔案，比如對埠、路由的配置。

因此我按照自己的想法建立了一個 issue ，也收集到了一些很不錯的建議。

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

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

目標

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

我認為有以下幾點:

• 可以自定義配置，並且支援不同的環境（開發、測試、生產）。
• 使用靈活。對使用者來說不要有太多的束縛。

理論上來說配置這個東西應當完全獨立出來，由一個配置中心來負責管理並且這樣可以與應用解耦。

不過這樣的實現和當前 cicada 的定義有些衝突，我想盡量小的依賴第三方元件並可以完全獨立執行。

因此基於這樣的情況便有了以下的實現。

使用

在看實現之前先看看基於目前的配置管理如何在業務中使用起來。

結合現在大家使用 SpringBoot 的習慣，cicada 預設會讀取 classpath 下的 application.properties 配置檔案。並且會預設讀取其中的應用埠以及初始路由地址。

同時也新增了一個 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) ;
    }
}
 

這樣在不傳預設地址的時候 cicada 會從 application.properties 中讀取。

考慮到後面可維護的情況，cicada 也支援配置各種不同的配置檔案。

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

public class KafkaConfiguration extends AbstractCicadaConfiguration {

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


}

public class RedisConfiguration extends AbstractCicadaConfiguration {


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

}
 

按照這樣的配置也會預設從 classpath 讀取這兩個配置檔案。

當然這裡有個前提：程式碼裡配置的檔名必須得和配置檔名稱相同。

那如何在業務中讀取這兩個配置檔案的內容呢？

這也簡單，程式碼一看就懂：

• 首先需要通過 ConfigurationHolder 獲取各自不同配置的管理物件（需要顯式指定類型別）。
• 通過 get() 方法直接獲取配置。
• 同時也支援獲取 application.properties 裡的配置。

同時為了支援在不同環境的使用，當配置了啟動引數將會優先讀取。

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

這樣算是基本實現了上述的配置要求。

實現

要實現以上的功能有幾個核心點：

1. 載入所有配置檔案。
2. 將不同的配置檔案用不同的物件進行管理。
3. 提供簡易的介面使用。

由於 cicada 需要支援多個配置檔案，所有需要定義一個抽象類供所有的配置管理實現。

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

• 檔名稱：用於初始化時通過名稱載入配置檔案。
• Properties 其實就是一個 Map 結構的快取，用於存放所有的配置。當然對外提供的查詢是基於它的。

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

查詢出來之後自然是要進行遍歷同時反射建立物件。

由於之前已經呼叫了

super.setPropertiesName("redis.properties");

來賦值配置檔名稱，所以還需要在遍歷過程中將 Properties 進行賦值。

同時在這裡也體現出優先讀取的是 VM 啟動引數中的配置檔案。

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

需要額外提一點的是：在查詢所有使用者自定義的配置管理類時需要手動將 cicada 內建的ApplicationConfiguration 加入其中。

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

儲存自定義配置管理

為了方便使用者在使用時候可以隨意的讀取各個配置檔案，所以還需要將反射建立的物件儲存到一個內部快取中，核心程式碼就是上上圖中的這段程式碼：

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

其中 ConfigurationHolder 的定義如下。

其實也是利用一個 Map 來存放這些物件。

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

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

重構

本次升級同時還重構了部分程式碼，比如啟動類。

現在看上去要清爽和直接的多：

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

大家如果檢視日誌的話會發現應用啟動之後會列印本次的耗時，自然就是在啟動時候記錄一個時間，初始化完畢之後記錄一個即可。

在之前的實現中由於都是在一個方法內，所以直接使用就行了。

但現在優化之後跨越了不同的方法和類，難道要把時間作為引數在各個方法之前傳遞嘛？

那未免太不優雅了。

所以 ThreadLocal 就有了發揮餘地。

在初始化的方法中我將當前時間寫入：

ThreadLocalHolder.setLocalTime(System.currentTimeMillis());

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

這樣使用起來就完全不需要管什麼引數傳遞了。

同時 ThreadLocalHolder 的定義：

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

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

總結

這就是本次 v1.0.2 中的升級內容，包含了配置支援以及程式碼重構。其中有些內容我覺得對接觸少的同學來說還是挺有幫助的。

關於上兩次的版本介紹請檢視這裡：

還沒點關注的朋友可以點波關注：

也歡迎大家參與一起維護！。

同時後續關於 cicada 的更新會放慢一些。會介紹一些平時實戰相關的內容，比如 Kafka 之類的，請持續關注。

你的點贊與轉發是最大的支援。