前言
應用程序在運行的時候往往需要依賴一些配置信息進行邏輯運算，而且這些配置基本上伴隨着應用程序的整個生命週期。
一般來說配置是獨立於程序代碼的的只讀變量。應用程序去讀取配置來改變自己的行爲，但是其不能改變配置，而是交由其他入口完成修改這一動作。
故配置需要進行管理，同一個應用在不同的部署環境（開發、測試、預生產、生產）經常需要不同的配置，所以需要有便捷、完善的配置管理流程去進行管理。
代碼配置管理的演變
開端
最開始的配置是如何編寫及放置的呢？
當然是代碼寫到哪裏，配置就加到哪裏，這是最早期和順手的做法，如下圖。
（圖中的提示語其實就是一個配置項）
這種做法最大的弊端就是：1、不能複用，一次修改，處處修改；2、不能按照不同環境所需進行調整。所以，此處應當進行抽離。
分工
邏輯代碼一類，配置項一類，把配置內容進行抽離，獨立放置到一個文件中，就是我所說的分工。既然配置項獨立出一個文件了，那麼後面的按環境加載就好辦了。
一般來說，會對不同環境的配置文件使用不同的前綴進行命名，然後相應環境機器上也會有相關的一個環境變量供程序讀取，讀取後依靠這個環境變量進行按需加載配置文件就好了。
優點：
1、與項目關聯緊密；
缺點：
1、更新及發佈麻煩，需要修改代碼；
2、缺失權限管理，安全性低；
3、不同應用項目配置不能共用；
4、配置零散，分散在各個項目代碼中；
分權
按照前一個（分工）配置管理的做法，做大的問題是什麼呢？
那就是，安全性極低。
這種把所有環境的配置信息都直接記錄在項目代碼中的做法，意味着只要是該項目的開發人員或能獲取到代碼的人員，都能看到生產環境的配置信息。
而一般來說，配置信息都會包含有數據庫賬號，更甚者有支付配置、消息發送配置等信息。如果剛好這些連接配置又沒有白名單管理，或者白名單覆蓋了整個辦公網絡，那麼就有可能被人爲去進行一些惡意操作。
而分權做法則是，代碼裏面只保留開發環境下的配置文件，其他環境的配置文件則由專人（一般是更高一級人員，如：開發組長）負責修改。隨後更新時，把文件交由給相關運維同事進行更新，直接放置到相應環境的機器共享配置文件目錄上替換。
優點：
1、有一定的權限管理，權限轉移到更高一級的開發人員及運維人員手中；
缺點：
1、更新及發佈依舊麻煩；
2、可能存在溝通阻礙，畢竟配置更新方及確認方變爲了兩方人員；
3、不同應用項目配置不能共用；（原有缺陷）
4、配置零散，分散在各個項目代碼中；（原有缺陷）
分層（級）
引入配置中心對各應用項目的配置進行管理，對各個應用、環境、文件、配置項分層，逐層進行管理，同時對於操作人員也要區分不同的操作權限，分爲閱讀、操作、審覈、發佈等層級，進行權限管理。
優點：
1、配置統一管理；
2、查看、修改及發佈權限可管理；
3、配置文件可以在不同應用中進行復用，進一步可統一修改；
4、更新便捷，點擊發布；
其中在github上進行開源可供使用的apollo項目則是一個很優秀的配置管理中心應用，滿足了大多數情況下的配置管理需要，下面本文將對其一些配置層次劃分結構做一個解析。
Apollo概念拆解
簡介
Apollo（阿波羅）是攜程框架部門研發的分佈式配置中心，能夠集中化管理應用不同環境、不同集羣的配置，配置修改後能夠實時推送到應用端，並且具備規範的權限、流程治理等特性，適用於微服務配置管理場景。
概念層級
其實對於配置中心功能點並不多，主要是提供WEB-UI讀寫配置、主動連接API（長連接）、拉取配置API等核心API，組成客戶端接入配置中心及時獲取新配置的操作。其主要分級概念如下：
應用：最頂層，表示一個個應用程序。
環境：爲不同環境提供不同的配置讀寫，提供環境間的配置（命名空間）同步。
集羣：假如相同環境中有多個不同集羣，需要不同的配置內容，則支持直接新增集羣（apollo的環境新增需要部署和接入），同樣可以在集羣間同步配置。
命名空間：命名爲配置文件可能較爲直觀，有私有及公共兩種，公共命名空間可共享給應用去使用，在原處修改後，其他地方同步修改。當然也可以修改覆蓋部分項的值，以達到只使用部分配置項的目的。
以上便是apollo對於配置項設置管理的層次劃分，由此可見，該層次結構符合多數應用落地部署場景，且較爲靈活，能很好得幫助項目人員去對配置進行管理。
參考這個層次結構，和必要的API，其實能很容易地實現我們自身的配置中心平臺（當然，直接使用apollo再進行專屬改造也是可以的），幫助我們更好地管理應用配置信息。