目前公司内部微服務架構基礎設施建設中，技術選型以Spring Cloud技術為主，也被大家俗稱作“全家桶”。
★因其具備微服務架構體系中所需的各個服務元件，比如服務注冊發現(如Spring Cloud Eureka、Zookeeper、Consul)、API網關路由服務(Spring Cloud Zuul)，用戶端負載均衡(Spring Cloud Ribbon，Zuul預設內建了Ribbon)、服務容錯保護(Spring Cloud Hystrix)，消息總線 (Spring Cloud Bus)、分布式配置中心(Spring Cloud Config)、消息驅動的微服務(Spring Cloud Stream)、分布式鍊路跟蹤服務(Spring Cloud Sleuth)。
”
本篇主要圍繞其中一個元件 分布式配置中心
Spring Cloud Config配置中心介紹&架構
在微服務架構體系中配置中心是比較重要的元件之一，Spring Cloud官方自身提供了Spring Cloud Config分布式配置中心，由它來提供集中化的外部配置支援，它分為用戶端和服務端兩個部分。
其中服務端稱作配置中心，是一個獨立的微服務應用，用來連接配接倉庫(如Git、Svn)并未用戶端提供擷取配置的接口；而用戶端是各微服務應用，通過指定配置中心位址從遠端擷取配置内容，啟動時加載配置資訊到應用上下文中。
因Spring Cloud Config實作的配置中心預設采用了Git來存儲配置資訊，是以版本控制管理也是基于Git倉庫本身的特性來支援的 。
對該元件調研後，主要采用基于消息總線的架構方式，架構圖如下所示：
基于消息總線的配置中心架構中需要依賴外部的MQ元件，如Rabbit、Kafka 實作遠端環境事件變更通知，用戶端實時配置變更可以基于Git Hook功能實作。
同時架構圖中看到最右側，有一個Self scheduleing refresher
Self scheduleing refresher 是一個定時任務，預設5分鐘執行一次，執行時會判斷本地的Git倉庫版本與遠端Git倉庫版本如果不一緻，則會從配置中心擷取最新配置進行加載，保障了配置最終一緻性。
”
經過實際使用你會發現Spring Cloud Config這個配置中心并不是非常好用，如果是小規模的項目可以使用問題不大，但它并不适用于中大型的企業級的配置管理。
是以，我對業界開源的配置中心做個對比後最終選擇了攜程開源的Apollo配置中心解決了微服務架構配置管理和其他項目中配置管理痛點。
下面就針對Spring Cloud Config和Apollo配置中心做個更加直覺的比對：
Apollo VS Spring Cloud Config
通過以上對比圖發現Spring Cloud Config缺陷還是挺大的，比如最後一條高可用，Apollo配置中心用戶端應用加載配置後本地會生成緩存檔案，即使配置中心所有的服務都挂掉，隻是配置無法更新，但是不影響你的服務啟動。
而這Spring Cloud Config是無法做到的，有人會說我們可以在應用classpath下添加應用配置檔案作為「兜底使用」，這樣做首先配置不會自動同步，而且也不是Spring Cloud Config自身的功能。
另外還有一個原因是因為現階段項目中也使用了一些自研的配置中心，但都差強人意，有的配置中心僅支援xml格式的，無法支援KV形式；還有的配置中心是基于JMX開發的，但隻支援屬性配置推送。
是以經過對Apollo配置中心的調研和使用發現這款産品不僅适用于微服務配置管理場景，同時也支援多種配置格式，如xml、json、yml，還支援多語言用戶端的接入，在配置服務治理方面也是很完善的，在攜程内部已經支撐10萬+的執行個體運作，成熟又穩定！
開源配置中心對比
下面這個圖詳細的開源配置中心對比圖：
在上述幾個開源配置中心裡，Apollo社群是非常活躍的，不斷更新疊代。
在Apollo出現之前百度開源的disconf配置中心使用的更多些，disconf最新代碼更新時間還是2年前的，且與Apollo的對比社群活躍度有所下降。
Apollo配置中心介紹&架構
Apollo（阿波羅）是攜程架構部門研發的分布式配置中心，能夠集中化管理應用不同環境、不同叢集的配置，配置修改後能夠實時推送到應用端，并且具備規範的權限、流程治理等特性，适用于微服務配置管理場景。
服務端基于Spring Boot和Spring Cloud開發，不依賴外部容器，便于部署。
Java用戶端不依賴任何架構，能夠運作于所有Java運作時環境，同時對Spring/Spring Boot環境也有額外支援。
原生支援Java和.Net用戶端，同時也支援其他語言用戶端，目前已支援Go、PHP、Python、NodeJS、C++。
主要功能特性：
- 統一管理不同環境、不同叢集的配置
- 配置修改實時生效（熱釋出）
- 版本釋出管理
- 灰階釋出
- 權限管理、釋出稽核、操作審計
- 用戶端配置資訊監控
- 提供Java和.Net原生用戶端
- 提供開放平台API
- 部署簡單，依賴少
Apollo總體架構設計：
各元件作用說明：
Apollo HA高可用設計：
Apollo用戶端架構：
用戶端架構原理：
1.推拉結合方式
- 用戶端與配置中心保持一個長連接配接，配置實時推送
- 定時拉配置(預設5分鐘)
2.本地緩存
- 配置緩存在記憶體
- 本地緩存一份配置檔案
3.應用程式
- 通過Apollo用戶端擷取最新配置
- 訂閱配置更新通知
Apollo核心概念：
application (應用)
每個應用都需要有唯一的身份辨別 -- appId
environment (環境)
Apollo用戶端通過不同環境擷取對應配置
cluster (叢集)
一個應用下不同執行個體的分組，不同的cluster，可以有不同的配置。
比如北京機房和天津機房可以有不一樣的kafka或zk位址配置。
namespace (命名空間)
一個應用下不同配置的分組，不同的namespace的類似于不同的檔案。
如：資料庫配置，RPC配置等。支援繼承公共元件的配置。
配置分類
- 私有類型（private）：隻能被所屬應用擷取
-
公共類型（public）：必須全局唯一。使用場景：部門/小組級别共享配置，中間件用戶端配置。
關聯類型（繼承類型）：私有繼承公有配置并覆寫；定制公共元件配置場景。
配置項(Item)
預設和公共配置使用properties格式；私有配置支援properties/json/xml/yaml/yml格式。
定位方式：app+cluster+namespace+item_key
權限管理
- 系統管理者擁有所有的權限
- 建立者可以代為建立項目，責任人預設是項目管理者，一般建立者=責任人
- 項目管理者可建立叢集，Namespace，管理項目和Namespace權限
- 編輯權限隻能編輯不能釋出
- 釋出權限隻能釋出不能編輯
- 普通使用者可以搜尋檢視所有項目配置，但沒有相關操作權限
Apollo配置中使用及擴充
使用Apollo配置中心後，做了進一步的功能開發擴充，接入公司的SSO和郵件通知接入。
基于Spring Cloud Config微服務架構體系中，如果之前使用了Spring Cloud Config配置中心，也可以通過下列方式平滑的遷移到Apollo配置中心。
Spring Cloud微服務項目在pom.xml中引入如下依賴：
<dependency>
<groupId>com.letv.micro.apollo</groupId>
<artifactId>micro-apollo-spring-boot-starter</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency> 該源碼參考Github：
★
https://github.com/david1228/micro-apollo-spring-boot-starter
”
需要自行編譯打成jar包使用。
這個jar包對Spring Cloud配置重新整理機制內建Apollo用戶端做了進一步封裝，實作的主要功能如下：
1、在Apollo配置中心釋出配置後，微服務應用用戶端監聽配置變更，包括預設的配置和公共的配置，通過ContextRefresher中的refresh()方法完成應用環境上下文的配置重新整理。
2、支援對日志級别和日志路徑檔案的動态配置變更。[Apollo Client無法很好的支援日志級别和日志路徑檔案的變更，因日志的LoggingApplicationListener加載優先級高，Apollo配置加載滞後。
上述jar包已上傳公司的Maven私服。具體配置使用示例可以參考「4.Apollo配置中心使用示例」
引入micro-apollo-spring-boot-starter之後，可以将spring-cloud-stater-config依賴從pom.xml中去掉了。
Apollo配置中心公共配置命名規範:
公共配置建議統一放到新建立的項目中，該項目中存放Spring Cloud相關的公共元件的配置，比如Eureka、Zipkin、Stream等配置，比如Eureka位址可能是多個微服務應用共用的，便于在該項目中統一對配置進行管理。
建立項目時，選擇的部門如為「微服務公共平台(dpms)」
各微服務應用項目建立後可以添加Namespace，選擇關聯公共配置。
公共配置命名規則：{部門字首}.application 或者 {部門字首}.application-{具體的細配置設定置}
當Apollo配置釋出後，若需讓Spring Cloud配置實作動态加載，公共配置命名必須以application關鍵字開頭，在上述依賴的jar包中會對這類命名的Namespace做配置變更監聽。
例如：
- dpms.application-eureka 存放eureka相關配置
- 或 dpms.application-zipkin 存放zipkin相關配置
- 或 dpms.application 存放Spring Cloud所有的公共相關配置
- 其他微服務應用關聯公共配置後，預設使用的公共配置項。
- 你也可以對公共配置所有參數做覆寫，覆寫後優先擷取本項目中的配置，這個特性在Apolo的公共配置界面能夠直覺的展示出來。
以上就是對為什麼要選擇Apollo配置中心的一些介紹，相信你的項目中可能也遇到了類似的配置管理問題或痛點，強烈建議使用Apollo配置中心作為你的配置管理基礎服務使用。
關于Apollo更詳盡的文檔請參考Github：
★
https://github.com/ctripcorp/apollo
原作者：東升的思考