開發配置規約

配置分類

環境配置:系統環境引數,比較離散,使用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 reference = new ReferenceConfig<>(); reference。setApplication(new ApplicationConfig(“dubbo-consummer”)); reference。setRegistry(new RegistryConfig(“zookeeper://127。0。0。1:2181”)); reference。setInterface(GreetingService。class); GreetingService greetingService = reference。get(); greetingService。sayHi(“zhangsan”); new CountDownLatch(1)。await();}

配置預設值

為了提高開發效率以及準確性,系統應該遵循約定大於配置的規約,為系統提供一些預設配置。但是配置預設配置的時候,必須將預設配置,配置在最外層。程式底層如果發現配置不正確,就應該直接報錯,容錯在最外層做。如果在程式底層使用時,發現配置值不合理,就填一個預設值,很容易掩蓋表面問題,而引發更深層次的問題。並且配置的中間傳遞層,很可能並不知道底層使用了一個預設值,一些中間的檢測條件就可能失效。

配置一致性

配置風格應該遵循一致性,比如1表示true,0表示false

不管選哪種方式,所有配置項,都應保持同一風格。例如超時時間,重試時間,定時器間隔時間。如果一個單位是秒,另一個單位是毫秒(C3P0的配置項就是這樣),配置人員會瘋掉。

配置覆蓋

多人同時開發中,要同時注意開發人員,測試人員,配管人員,系統管理員都有可能對同一個配置進行配置,例如dubbo中,有些配置既可以在提供者端匹配,又可以在消費者端配置,如果不同的開發者分別在兩端配置了不同的引數,可能就會導致一方無法達到期望的目標,此類配置咋愛賭博搏中還有loadbalance,retries,actives(消費者端最大併發呼叫數)

配置繼承

配置也存在繼承關係,在xml中的樹形結構關係中很明顯,例如dubbo中即繼承了中的配置,具體關係可以參照下圖所示:

開發配置規約

dubbo配置繼承關係圖

配置向後相容

向前相容很好辦,你只要保證配置只增不減,就基本上能保證向前相容。但是也要注意到向後相容,