高老莊

先談下這個解決方案的背景:
    假設一個公司的產品遵循的是先有基礎平臺,然后在此平臺上構建不同的產品,最后每一個產品被實施到特定的項目,那么，他們就構成了一種層次化的結構.每一個層次,需要覆蓋一些上一層次的配置或者創建新的配置,如何分割層次間的影響從而保證層次間的獨立性，是一個挑戰.
    任意層次,可能有多個模塊或者組件構成，不同的組件間，配置的類型可能一樣，但是配置的數據不一樣,那么,如果在配置某個模塊時，不比考慮其他模塊的配置情況，那么這個模塊就擁有開發時的獨立性,當組件被集成到同一層次部署運行時，配置的合并和重組是一個問題,并且，組件間可能存在依賴關系,這種依賴關系同時產生了依賴組件間配置加載的優先級問題.
    成熟的軟件，一般不會直接將第三方的軟件集成，而是將其封裝后在納入進來,第三方組件的配置往往不具備配置的層次化或者模塊獨立性.在設計第三方組件的集成策略時，需要考慮使其擁有上述兩種能力.
    解決上述問題，方式有很多種,我們談論比較容易實現的一種.
    這種解決方案的基本思路如下:
    首先，設計一個特定的擴展名稱的配置文件(模塊配置索引文件,MCIF,xml格式)，此配置文件面向的是組件級別，即每個組件定義自己的MCIF.MCIF中定義若干配置類別,即名稱空間,每一個名稱空間負責完成一類配置，一般,一個名稱空間對應一個配置獲取接口.這個名稱空間中僅僅配置所關注的配置的文件的相對位置(相對此MCIF),這樣，最大化的減少了不同配置文件格式對MCIF的影響.
    每一個MCIF的根元素擁有一個parent屬性,指向了上一層次,同一層次的MCIF的parent屬性都相同.通過parent屬性，配置的層次化就不是問題了.
    MCIF有兩個特殊的名稱空間:
    1.register 定義了所支持的名稱空間及其對應的配置解析器,這樣,此配置框架就可以允許對名稱空間進行擴展.
    2.depends 定義了同一層次的模塊間的依賴關系,這個是可選的，如果沒有實現或者配置，同一層次的module即為平行的.
    
    當系統啟動時,掃描所有的MCIF,并根據parent屬性解析出一個層次關系,對每一個層次下module,參考相應的depends設置定義出一個依賴關系.
    當請求某特定的配置時,根據上述的兩個關系完成配置的組合，并返回給使用者.
    
    公司最近的重構中，基于這個思想開發的配置小框架，很好完成了多層次，多組件的配置覆蓋問題,配置相對以前更清晰、簡單，配置過程中的關注點大大減少.