前言
在前兩次的 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這樣算是基本實現了上述的配置要求。
實現
要實現以上的功能有幾個核心點：
- 加載所有配置文件。
- 將不同的配置文件用不同的對象進行管理。
- 提供簡易的接口使用。
由於 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 中的升級內容，包含了配置支持以及代碼重構。其中有些內容我覺得對接觸少的同學來說還是挺有幫助的。
關於上兩次的版本介紹請查看這裏：
還沒點關注的朋友可以點波關注：
https://github.com/TogetherOS/cicada
也歡迎大家參與一起維護！。
同時後續關於 cicada 的更新會放慢一些。會介紹一些平時實戰相關的內容，比如 Kafka 之類的，請持續關注。
你的點贊與轉發是最大的支持。