在微服務架構體系中，由于微服務眾多，服務之間又有互相調用關系，因此，一個通用的分布式配置管理是必不可少的。一般來說，配置管理需要解決配置集中管理、在系統運行期間可實現動態配置、配置修改后支持自動刷新等問題。
在大多數微服務體系中，都會有一個名為配置文件的功能模塊來提供統一的分布式配置管理。構建配置中心，統一對應用中各個微服務進行管理，對微服務體系的意義重大。
Consul為什么適合做配置管理
Consul作為輕量級的分布式K/V存儲系統，搭建方便，可用性高，并且支持多數據中心，提供Web UI進行K/V管理。此外Consul還可以結合Consul-Template或者在代碼中引入Consul Client的相關依賴創建Watcher來實時Watch K/V的變化，是配置管理的不二之選。
下圖為個推微服務體系基于Consul配置管理的整體設計。其中，CCenter就是在Consul的基礎上進行二次開發的配置中心。
微服務體系下配置的分類和組織形式
在實踐中，不同產品線的配置會放置在Consul的不同路徑下，實現不同產品線配置之間的隔離。
按照配置的用途，可將同一產品線下的配置分為三類：
1.API網關相關配置；
2.服務注冊與發現相關配置；
3.應用相關配置。
其中，每類配置會對應Consul上的不同目錄。
按照配置的變化特性，可將配置分為兩類：
1.環境相關的全局配置
如MySQL等外部依賴相關的配置和其他與環境相關的配置，這類配置在開發測試生產環境中存在差異，需要為不同環境配置不同的值。
2.應用本身的配置
一般為不經常性發生變化、可動態調整、開關的配置。這類配置比較穩定，在初始化后，只有在需要時才會改動，通常會設置默認值。這兩類配置在Consul上會放在不同的子目錄下。這樣QA、運維只需要關注環境差異部分即可。
基于以上對配置的分類，最終Consul上的Key的格式如下：
/ProductLine_Prefix/Usage_Prefix/Environmental_Correlation_Prefix/Config_Item_Path
其中，
ProductLine_Prefix：用來隔離不同產品線的配置；
Usage_Prefix：用來區分配置的用途；
Environmental_Correlation_Prefix：用來分隔與環境相關的配置；
Config_Item_Path：具體的配置項。
配置在Consul上的組織形式有以下兩種：
1.以配置文件的形式組織，Consul上的一個K/V，對應一個配置文件，如Nginx的配置文件。
2.以配置項的形式組織，將配置文件模板化，拆成一個個的配置項，每個配置項對應Consul上的一個K/V，多個配置項對應一個配置文件。大部分配置文件本身都是以K/V的形式組織的，均適合模板化，模板化后即可以按照配置項的特性，在Consul上分成不同的類別進行管理。
如何實現配置更新
Consul上的K/V，要如何生成可加載的應用，或可使用的配置呢？
1.用Node和Lua實現的微服務的配置更新，使用Consul-Template來實現；
2.用JAVA實現的微服務的配置更新，通過Consul-Template工具（需要重啟應用）和在代碼中引入Consul Client的依賴創建Watcher（熱更新）這兩種方式來實現。
以上關于consual做微服務的配置管理只是一種解決方案，有更好更具體的方案請大家留言，再次感謝!
