配置分類
環境配置:系統環境引數,比較離散,使用key-value格式的properties檔案,例如dubbo中的timeout,connect。。。
描述配置:通常資訊比較多,甚至有層次關係,使用xml,樹結構表現更好,更直觀,
擴充套件配置:如果應用沒有提供自定的引數配置,可以自定義擴充套件,例如,spring自定schema
配置格式
環境配置:applicationName。properties
描述配置:applictaion。xml,application。yml
配置載入
環境配置:對於環境配置,一般系統啟動前就需要載入,一般規定在classpath目錄下定義一個ApplicationName。properties的檔案,該檔案具有較高的優先順序,系統啟動時,自動載入,不需要認為干預。我們平臺的很多專案也使用類似策略,如:dubbo。properties,comsat。xml 等。但是由於專案開發結構中,classpath路徑一般由幾個目錄結構組成,這樣就會導致在classpath下由多個相同的配置檔案,可能導致誤載入,以及在 ClassLoader 隔離時,可能找不到配置,並且,當用戶希望將配置放到統一的目錄時,不太方便。
描述配置:而對於描述配置,因為要參與業務邏輯,通常會嵌到應用的生命週期管理中。目前業內使用較多的是spring的配置檔案,讀者可以自行參考spring自定義schema。但是這種配置方式過度依賴於spring。
可程式設計配置
當一個框架要整合另一個框架的時候,同時也要將該框架中的配置整合到那個框架當中,用於適配配置。所以任何框架的配置,無論以何種方式進行載入,都要提供直接用編碼完成配置的方式。如下是dubbo消費者的程式設計式配置:
public static void main(String[] args) throws InterruptedException { ReferenceConfig
配置預設值
為了提高開發效率以及準確性,系統應該遵循約定大於配置的規約,為系統提供一些預設配置。但是配置預設配置的時候,必須將預設配置,配置在最外層。程式底層如果發現配置不正確,就應該直接報錯,容錯在最外層做。如果在程式底層使用時,發現配置值不合理,就填一個預設值,很容易掩蓋表面問題,而引發更深層次的問題。並且配置的中間傳遞層,很可能並不知道底層使用了一個預設值,一些中間的檢測條件就可能失效。
配置一致性
配置風格應該遵循一致性,比如1表示true,0表示false
不管選哪種方式,所有配置項,都應保持同一風格。例如超時時間,重試時間,定時器間隔時間。如果一個單位是秒,另一個單位是毫秒(C3P0的配置項就是這樣),配置人員會瘋掉。
配置覆蓋
多人同時開發中,要同時注意開發人員,測試人員,配管人員,系統管理員都有可能對同一個配置進行配置,例如dubbo中,有些配置既可以在提供者端匹配,又可以在消費者端配置,如果不同的開發者分別在兩端配置了不同的引數,可能就會導致一方無法達到期望的目標,此類配置咋愛賭博搏中還有loadbalance,retries,actives(消費者端最大併發呼叫數)
配置繼承
配置也存在繼承關係,在xml中的樹形結構關係中很明顯,例如dubbo中
dubbo配置繼承關係圖
配置向後相容
向前相容很好辦,你只要保證配置只增不減,就基本上能保證向前相容。但是也要注意到向後相容,