高老莊

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