本文轉自微信號EAWorld。掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！本文轉自微信號EAWorld。
前些年沒提微服務架構的時候，大家也都會做配置管理相關的事情，比如我接觸過的很多項目都做有配置，做得有好有壞。大多是手工作坊，修改配置、重啓服務… … 好像也能湊合。其實不論有沒有微服務，把配置管理好的手段和方法都差不多，只是微服務架構重分佈式的特點凸顯了這個問題的重要性，再不管好配置，還想繼續湊合就行不通了。本文目的是跟大家一起梳理配置管理的一些思路和方法，一起打好微服務架構的基礎。
目錄：
一、什麼是配置
二、配置與程序的關係
三、配置管理的四個維度
四、靜態配置管理
五、動態配置管理
六、總結回顧
一、什麼是配置
配置是獨立於程序的變量①，配置通常有各種形態，有配置文件、數據庫表、系統環境變量、進程啓動參數等。
一般我們會把配置按程序啓動爲分界線，分爲兩類：
運行前的配置
運行前的配置，通常是指與環境相關的一些配置，比如數據源、郵件服務器地址，不同的環境有不同的值。還有一類比如安全控制類的，例如weblogic服務啓動時，會要求輸入啓動賬號密碼等。把程序與環境相關的參數設置好之後，纔可以在對應的環境上正常啓動運行。
運行時的配置
運行時的配置，通常就是一些可以動態調整的參數，程序會根據不同的參數值產生不同的行爲，計算結果可能不一樣。一般運行時的配置調整，最好是能夠做到動態的熱更新，不需要重啓動服務才能生效。大致分兩種：
技術運維相關的參數，如線程池大小、隊列長度，調整爲不同的值會有不一樣的性能表現。
業務相關的參數，比如貸款系統貸款額度調整，貸款利率調整。
二、配置與程序的關係
配置管理的前提是程序與配置要分離，如果是寫死代碼的話，配置管理也就無從談起了。
其次就是一套程序支持多套配置，這是針對靜態配置來說的，一套程序，不同的配置值，適應不同的環境。
運行時，程序是穩定的，配置是可變的 ，還需要將配置持久化保存，不要放到虛機和容器的內部存儲中，避免虛機、容器重啓動後配置丟失，還原成鏡像的最初狀態。
參見上圖，介質+配置=部署包這個公式主要是針對靜態配置說的。介質就是程序，配置就是適合環境的配置值，兩者組合成的部署包就成了某個適合具體環境安裝部署的部署包，有了這個環境部署包，我們就可以非常方便的把部署包安裝到對應的環境中。
三、配置管理的四個維度
配置是需要治理的，配置管理的過程中，我們需要考慮下面這四個維度。
多環境管理，維護好環境與配置的關係，即不同環境不同配置（靜態配置相關）
影響範圍控制，運行時配置變更後，會影響單點還是集羣，是隻影響一個應用，還是會影響多個不同的應用（動態配置相關）
配置管理過程需要有權限控制，嚴格的話配置變化還需要有流程審覈才能發佈。
配置變更操作需要審計，要知道什麼人、什麼時間修改了哪些配置。每次修改發佈都要留痕，也就是有多版本，一旦修改出了問題，可以進行回退操作，恢復到修改之前的狀態。
四、靜態配置管理
先來看一個反例，一些企業比如金融行業，非常重視上線過程的流程和操作合規性的，但現狀是沒有技術手段支撐，全是手工操作，開發人員和運維人員都很痛苦，整個上線週期很長，非常容易出問題。
見上圖，功能開發結束後，開發人員爲了上線，先要準備一堆文檔，比如操作手冊，要求寫成運維人員不需要思考，完全機械化的按步驟複製、粘貼就能完成操作的狀態。比如在什麼目錄下某個文件裏面，配置數據源，然後在負載均衡什麼目錄下配置Ip端口等等。
先寫個半個月文檔，然後評審，接下來再演練，反覆進行好多次，最後才能上線。開發工作量和上線過程的工作量幾乎到了1:1 效率非常低下。
那麼推薦的做法是要流程和技術並重，通過自動化的手段，將介質和配置組合，打出適合某環境安裝的部署包，更方便的部署到開發環境。
見上圖，集成過程中設置好配置值，編譯後可以直接注入配置作出部署包，如果有自動化部署服務能力的話，就能夠自動的吧部署包發佈到對應的環境中了。即便是沒有自動化部署，一個已經配置好的應用部署包，手工操作起來也是很簡單的事情，解壓到合適的位置就好了。下面推薦兩個靜態配置管理的方案供大家參考：
方案一：Spring Profiles
Spring Profiles②是Spring推出的功能，提供了應用程序在不同環境中使用不同配置的能力。
比如在spring boot應用中的用法。如果使用properties文件存儲配置時，可以爲每個環境分別設置一個配置文件。
如果項目中使用了yml格式的配置文件的話，不同環境的profile需要在同一個配置文件裏面定義，示例如下：
定義好後不同profiles的配置後，在Spring boot應用啓動時，可以通過參數指定激活某個profile，然後Spring boot程序就會加載對應profile下的配置值，啓動參數激活方式示例如下：
方案二：AutoConfig + SCM
AutoConfig③： 阿里系的一個開源工具，提供了在build時刻基於文件進行配置注入的能力。類似於Maven Filtering，但其使用方式與開發應用所採用的技術框架無關，具備良好的通用性。（AutoConfig源碼庫地址：https://github.com/webx/citrustool/tree/master/antx/autoconfig）
參見上圖，AutoConfig 配置注入主要分三個步驟。有了模板和配置元數據的定義再加上配置值，就可以通過命令把配置值注入到目標文件裏面。工具非常強大，針對的是目標文件，不依賴編譯框架。在編譯中或者編譯後都可以執行，還可以注入壓縮包內的配置文件。
配置模板抽取：
application.yml 源配置文件示例
application.template 是根據application.yml抽取出來的配置模板。其中${}內的字符就是配置項名稱。示例如下：
配置元數據定義
auto-conf.xml 即配置元數據定義文件，文件中主要包配置項的定義和注入腳本定義兩部分內容。示例如下：
配置文件注入
通過命令行注入配置文件示例如下：
SCM④： 普元自建的一個配置管理服務，支持對應用在交付過程中的不同階段和環境的配置進行統一管理。我們反覆再強調，配置管理是軟件交付過程中的非常重要的環節。
如果說沒有軟件配置管理的話，項目將是個什麼樣子？開發人員沒定義或者亂定義，測試人員不會裝不會配，上線的運維人員更是一頭霧水。這種狀態下，想要成功上線，就只能回到嚴格控制流程，逼開發寫文檔，逼測試演練，逼運維轉型機器人。大家都幹着枯燥無味的事情。
那麼SCM的作用就是要支撐軟件配置的協作化管理 ，通過SCM提供的能力，可以讓開發人員在設計過程中，規範的定義配置項，並設置好默認值。測試人員負責設置測試環境需要使用的配置值，運維人員負責生產環境的配置值，做好這些後，持續集成和交付服務可以快捷的編譯出部署包並安裝到目標環境裏。SCM在配置版本、環境、角色、權限、流程等配置管理的多個維度均提供了相應的能力支撐。
上圖是是我們的DevOps產品中的一個CI、CD示意圖。開發、測試、運維人員，通過門戶UI去設置不同環境的不同配置值，然後發起編譯、打包、部署操作，後臺就由各服務自動的進行源碼編譯、配置注入、自動部署等操作。
開發人員不用寫那些一堆上線操作手冊了，只需要定義配置項，設置默認值。測試人員、運維人員也都設置自己維護環境的對應配置，評審都是在線進行，審覈通過，點個按鈕就自動部署。總之能讓機器代勞的工作，儘量少讓人手工幹。
SCM服務的主要概念模型如下圖：
一個業務系統可以由多個組件（微服務）
組件是部署的最小單元
一個組件可以定義多個配置項
一個配置項對應不用環境可以有不同值（每次環境配置提交均全量留痕，打部署包時可按需選擇）
在我們DevOps產品門戶中已有環境配置管理的應用，組件部署設計中配置項設置相關的頁面截圖如下：
靜態配置管理的兩個方案對比如下：
Spring Profile方案：
說明：Spring體系能力，能夠與Maven、Jenkins集成。適合一般項目中使用。
優勢：配置簡單，使用方便
劣勢：環境配置存放到代碼庫中，權限不好控，安全性一般；技術框架有限制（Spring），靈活程度略低（依賴Maven編譯）
SCM + AutoConfig方案：
說明：更體系化的配置管理整體方案，更適合企業整體規劃。
優勢：完善的配置權限管理；不限制技術框架；針對的是目標文件，更靈活。
劣勢：需要開發維護SCM服務
五、動態配置管理
首先看圖回顧一下前面提到了動態配置的一些要點：
動態配置通常包含，業務運營配置，和技術運維配置。動態配置管理，通常就需要考慮右邊這三個維度，影響範圍、權限控制、審計很多版本，最後還有一個隱含的要求就是要支持熱更新。
那麼傳統動態配置管理的方案和微服務架構下的管理方式思路基本一致。主要是這三個方面：
狀態統一管理
中心配置倉庫
配置推送和拉取
傳統模式和微服務架構的區別就是，以前分佈式程度低，很多情況都是手工維護。比如應用狀態管理、集羣配置都是手工維護的。很少有做配置修改審計和回滾的。微服務架構下，我們需要更加靈活，快速變化。那麼應用需要自動註冊發現，應用很分散，審計的需求加強了，異常回退的需求也來了。那麼久需要適應微服務架構下的配置管理方案，示意圖如下：
我們的微服務平臺配置中心是選用了攜程開源的Apollo①，也是功能非常強大，需要的能力基本都是現成的。Apollo配置中心能夠方便的與註冊中心集成。我們的微服務平臺是基於Spring Cloud，而Apollo也是能夠跟Spring Cloud這套環境很好融合。Apollo的主要概念模型如下：
App：應用
Cluster：集羣
Namespace：名稱控件（可以類比爲文件）
Item：Namespace下的配置項，每個Item是一個key, value組合
Release：Namespace發佈的配置，每個發佈包含發佈時該Namespace的所有配置
Commit：Namespace下的配置更改記錄
基於Apollo配置中心，我們的微服務平臺管理門戶中可以方便的管理各微服務應用中的配置，通過管理門戶統一控制配置權限，每個配置項修改分爲保存、發佈兩個動作，發佈過程可以支持流程審覈。配置項值變更多版本記錄，可以回滾到某個歷史版本。見下圖：
六、總結回顧
最後，我們用一張圖⑥來總結回顧一下：
本文講的配置管理，主要就以運行前的靜態配置和運行時的動態配置入手展開的。配置管理的前提，就是程序和配置要分離。靜態配置考慮多環境，要管理配置和環境的關係，動態配置要考慮變更影響範圍。兩者都需要考慮的是權限、審計、多版本等內容。
那我們要做好配置管理，需要在不同的階段，配合一些手段來逐步實現。首先是定規範要求程序和配置分離，然後統一打法選合適的技術框架，讓配置定義、加載、熱更新等方式儘量統一，最後平臺化做規範化的集中配置管理。
參考資料：
① 開源配置中心Apollo的設計與實現
http://www.infoq.com/cn/articles/open-source-configuration-center-apollo
② Spring boot profiles
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-profiles.html
③ AutoConfig工具使用指南
http://blog.csdn.net/fighterandknight/article/details/70245905
④ DevOps之軟件配置協作化管理
⑤ 基於微服務的企業應用架構設計範式
推薦閱讀：
微服務編排之道
微服務的4個設計原則和19個解決方案
微服務的持續集成，四步“構建”一個代碼世界
關於作者：
郝炎峯，現任普元 SOA&雲計算產品部 產品架構師。主要負責普元流程產品的核心架構設計與產品版本發展規劃，先後參與了國家電網BPM、BAM平臺、浦發銀行新一代流程平臺等大型平臺項目建設與實施 。
關於EAWorld
微服務，DevOps，元數據，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公衆號。
掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
微信號：EAWorld，長按二維碼關注。
