軟件配置設計、訪問與管理
前言
最近在進行項目維護與新的feature開發過程中，涉及到爲新的部署環境增加配置問題。
服務本身涉及到使用不同的計算與存儲環境，所以配置需要在最簡化的代碼邏輯下兼容不同的環境。
同時不同的計算任務託管在服務上，服務需要協助管理任務的運行環境，即配合管理並準備任務使用的環境變量及專門的配置。
複雜的配置項信息增加部署服務的複雜度。
由此，產生了對軟件配置的設計與管理的一些想法。
結構化軟件配置中可擴展性設計
軟件的設計模式不僅應用在軟件代碼設計上，在軟件的配置上也同樣可以應用。軟件的配置項，是將實體信息從抽象的軟件層抽離出來，獨立進行管理的數據信息。所以其設計邏輯本身也穎遵循一定的設計模式，以便進行配置的修改增加與保持兼容。
很多結構化的配置設計，僅僅簡單的進行分層設計，這在大部分的軟件應用問題並不大，但是對於使用同一個配置訪問同一性質的不同服務，如slave節點、不同的消息隊列、不同的計算集羣、不同的存儲服務，在分佈式軟件中，將會愈來愈頻繁的接觸到。
這就要求，在對此類配置進行分層的時候，要充分考慮到可擴展性。
例如，對於多個slave節點的連接配置，在分層的時候，是直接在頂層填入IP項，或是以子網劃分，或是以slave節點劃分，都要根據服務（業務）發展方向來設計；又例如，使用不同的雲廠商服務，先按計算、存儲、消息隊列等服務劃分，再劃分不同雲廠商的服務，或是先基於雲廠商劃分，再分別配置各自使用的服務，都需要參考服務擴展方向而定。
誠然，按哪一種方式劃分，其不過是一份配置文件，如果軟件設計的好，對於讀配置的邏輯並不會有太多的影響，對於使用配置的邏輯層則幾乎沒有影響。但是對於部署的同學來說，上線前生成一份正確的配置，快速便捷的理解配置的內容，是非常必要的。就如同，不寫文檔，代碼混亂不可怕，不爲黑魔法寫清楚註釋，則軟件維護將非常辛苦。軟件工程，不是一個人做完即完的。
配置解析抽象化
軟件配置無論如何設計，都是爲了軟件可以準確的讀取，以便作爲提供服務的標準數據。
結構化與擴展性是爲了新增配置的時候運維同學可以便捷理解與順利部署。同時，也是爲了解析配置的邏輯維護性和擴展性更高。
所以完成配置設計之後，配置解析模塊就需要做充分的抽象化設計。
許多軟件都會對軟件配置解析模塊進行獨立的維護，並將解析的配置以全局變量的形式暴露出來供邏輯層訪問。最樸素的做法則是將配置加載到內存後，由邏輯層自由訪問，即由軟件邏輯根據實際使用情況去解析出配置數據。
這種設計的缺點在於，一旦配置結構發生變更，軟件維護將變得非常困難，需要有非常充分的測試（我們知道，很多時候測試工作都是不完整的，要做到完整的測試則將耗費非常多的人力物力）。如果對於配置先行抽象化的處理，並實體化每一個配置形成一個獨立的實體對象，則對於邏輯層，僅需要選擇與加載不同的配置實體，組成自己的邏輯實體，將從配置解析層面完成對軟件與配置的解耦。對於配置擴展與變更，將不會對軟件的邏輯層面造成過多的變更操作。這將大大增加軟件的可維護性。
環境變量 or 配置文件
關於配置信息的管理，一般有三種模式，第一是配置文件的形式，第二是環境變量的形式，第三是從其他服務（如配置中心）中讀取的形式來進行。第三種模式的管理方法，更多的是考慮到配置訪問安全的情況與配置統一管理等相關，在本篇不詳述。
對於從環境變量或者配置文件讀取，不同人使用的感受不一。
環境變量訪問的好處在於，在啓動腳本中預置了環境信息，部署靈活，尤其是對於需要訪問多個配置文件的應用，爲每一個配置文件分配環境變量是每一個獨立訪問配置的應用的默認設置（一般而言，配置文件的路徑放置在home目錄下，但是也可能將配置文件放置在特定目錄並以環境變量暴露給應用，應用也將優先從該路徑加載配置），使用環境變量可以避免增加多一個配置多一層維護邏輯，同時也是應用訪問配置的常規方法。
對於配置信息較爲簡單的應用，使用環境變量可以避免在實體留下持久化的信息（儘管環境變量的信息也可以被讀出來），而簡單的環境變量維護起來也更加簡單。
看起來，使用環境變量是有利於減少維護成本的。但是我們不能忽略，使用環境變量的前提是，第一軟件有約定好的使用環境變量的設計，第二配置信息比較簡單。也就是說，使用環境變量的約束本身就很大。
所以，對於第一種情況，由部署方決定，是否爲多個服務的不同配置信息創建統一的配置與訪問入口，並在啓動相應的應用之前暴露到環境變量中；或是由多個應用的統一管理服務來確定。對於第二種情況，則在設計過程中，要着重處理好訪問優先級，避免環境變量的篡改導致應用出錯。
總之，使用環境變量是一件低成本高風險的操作方法，需要謹慎。
