目前公司內部微服務架構基礎設施建設中，技術選型以Spring Cloud技術為主，也被大家俗稱作“全家桶”。

    ★    因其具備微服務架構體系中所需的各個服務組件，比如服務注冊發(fā)現(xiàn)(如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實現(xiàn)的配置中心默認采用了Git來存儲配置信息，所以版本控制管理也是基于Git倉庫本身的特性來支持的 。

對該組件調研后，主要采用基于消息總線的架構方式，架構圖如下所示：

基于消息總線的配置中心架構中需要依賴外部的MQ組件，如Rabbit、Kafka 實現(xiàn)遠程環(huán)境事件變更通知，客戶端實時配置變更可以基于Git Hook功能實現(xiàn)。

同時架構圖中看到最右側，有一個Self scheduleing refresher 這個是我在實踐中自己新增的一個擴展功能，目的是當依賴的消息組件出現(xiàn)問題時，此時如果Git倉庫配置發(fā)生了變更，會導致部分或所有客戶端可能無法獲取到最新配置，這樣就造成了客戶端應用配置數(shù)據無法達到最終一致性，進而引起線上問題。

    ★    Self scheduleing refresher 是一個定時任務，默認5分鐘執(zhí)行一次，執(zhí)行時會判斷本地的Git倉庫版本與遠程Git倉庫版本如果不一致，則會從配置中心獲取最新配置進行加載，保障了配置最終一致性。”

經過實際使用你會發(fā)現(xiàn)Spring Cloud Config這個配置中心并不是非常好用，如果是小規(guī)模的項目可以使用問題不大，但它并不適用于中大型的企業(yè)級的配置管理。

因此，我對業(yè)界開源的配置中心做個對比后最終選擇了攜程開源的Apollo配置中心解決了微服務架構配置管理和其他項目中配置管理痛點。

下面就針對Spring Cloud Config和Apollo配置中心做個更加直觀的比對：

Apollo VS Spring Cloud Config

通過以上對比圖發(fā)現(xiàn)Spring Cloud Config缺陷還是挺大的，比如最后一條高可用，Apollo配置中心客戶端應用加載配置后本地會生成緩存文件，即使配置中心所有的服務都掛掉，只是配置無法更新，但是不影響你的服務啟動。

而這Spring Cloud Config是無法做到的，有人會說我們可以在應用classpath下添加應用配置文件作為「兜底使用」，這樣做首先配置不會自動同步，而且也不是Spring Cloud Config自身的功能。

另外還有一個原因是因為現(xiàn)階段項目中也使用了一些自研的配置中心，但都差強人意，有的配置中心僅支持xml格式的，無法支持KV形式；還有的配置中心是基于JMX開發(fā)的，但只支持屬性配置推送。

所以經過對Apollo配置中心的調研和使用發(fā)現(xiàn)這款產品不僅適用于微服務配置管理場景，同時也支持多種配置格式，如xml、json、yml，還支持多語言客戶端的接入，在配置服務治理方面也是很完善的，在攜程內部已經支撐10萬+的實例運行，成熟又穩(wěn)定！

開源配置中心對比

下面這個圖詳細的開源配置中心對比圖：

在上述幾個開源配置中心里，Apollo社區(qū)是非常活躍的，不斷更新迭代。

在Apollo出現(xiàn)之前百度開源的disconf配置中心使用的更多些，disconf最新代碼更新時間還是2年前的，且與Apollo的對比社區(qū)活躍度有所下降。

Apollo配置中心介紹&架構

Apollo（阿波羅）是攜程框架部門研發(fā)的分布式配置中心，能夠集中化管理應用不同環(huán)境、不同集群的配置，配置修改后能夠實時推送到應用端，并且具備規(guī)范的權限、流程治理等特性，適用于微服務配置管理場景。

服務端基于Spring Boot和Spring Cloud開發(fā)，不依賴外部容器，便于部署。

Java客戶端不依賴任何框架，能夠運行于所有Java運行時環(huán)境，同時對Spring/Spring Boot環(huán)境也有額外支持。

原生支持Java和.Net客戶端，同時也支持其他語言客戶端，目前已支持Go、PHP、Python、NodeJS、C++。

主要功能特性：

•  統(tǒng)一管理不同環(huán)境、不同集群的配置
•  配置修改實時生效（熱發(fā)布）
•  版本發(fā)布管理
•  灰度發(fā)布
•  權限管理、發(fā)布審核、操作審計
•  客戶端配置信息監(jiān)控
•  提供Java和.Net原生客戶端
•  提供開放平臺API
•  部署簡單，依賴少

Apollo總體架構設計：

各組件作用說明：

Apollo HA高可用設計：

Apollo客戶端架構：

客戶端架構原理：

1.推拉結合方式

•  客戶端與配置中心保持一個長連接，配置實時推送
•  定時拉配置(默認5分鐘)

2.本地緩存

•  配置緩存在內存
•  本地緩存一份配置文件

3.應用程序

•  通過Apollo客戶端獲取最新配置
•  訂閱配置更新通知

Apollo核心概念：

application (應用)

每個應用都需要有唯一的身份標識 -- appId

environment (環(huán)境)

Apollo客戶端通過不同環(huán)境獲取對應配置

cluster (集群)

一個應用下不同實例的分組，不同的cluster，可以有不同的配置。

比如北京機房和天津機房可以有不一樣的kafka或zk地址配置。

namespace (命名空間)

一個應用下不同配置的分組，不同的namespace的類似于不同的文件。

如：數(shù)據庫配置，RPC配置等。支持繼承公共組件的配置。

配置分類

•  私有類型（private）：只能被所屬應用獲取
•  公共類型（public）：必須全局唯一。使用場景：部門/小組級別共享配置，中間件客戶端配置。
•  關聯(lián)類型（繼承類型）：私有繼承公有配置并覆蓋；定制公共組件配置場景。

配置項(Item)

默認和公共配置使用properties格式；私有配置支持properties/json/xml/yaml/yml格式。

定位方式：app+cluster+namespace+item_key

權限管理

•  系統(tǒng)管理員擁有所有的權限
•  創(chuàng)建者可以代為創(chuàng)建項目，責任人默認是項目管理員，一般創(chuàng)建者=責任人
•  項目管理員可創(chuàng)建集群，Namespace，管理項目和Namespace權限
•  編輯權限只能編輯不能發(fā)布
•   布權限只能發(fā)布不能編輯
•  普通用戶可以搜索查看所有項目配置，但沒有相關操作權限

Apollo配置中使用及擴展

使用Apollo配置中心后，做了進一步的功能開發(fā)擴展，接入公司的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客戶端做了進一步封裝，實現(xiàn)的主要功能如下：

1、在Apollo配置中心發(fā)布配置后，微服務應用客戶端監(jiān)聽配置變更，包括默認的配置和公共的配置，通過ContextRefresher中的refresh()方法完成應用環(huán)境上下文的配置刷新。

2、支持對日志級別和日志路徑文件的動態(tài)配置變更。[Apollo Client無法很好的支持日志級別和日志路徑文件的變更，因日志的LoggingApplicationListener加載優(yōu)先級高，Apollo配置加載滯后。

上述jar包已上傳公司的Maven私服。具體配置使用示例可以參考「4.Apollo配置中心使用示例」

引入micro-apollo-spring-boot-starter之后，可以將spring-cloud-stater-config依賴從pom.xml中去掉了。

Apollo配置中心公共配置命名規(guī)范:

公共配置建議統(tǒng)一放到新創(chuàng)建的項目中，該項目中存放Spring Cloud相關的公共組件的配置，比如Eureka、Zipkin、Stream等配置，比如Eureka地址可能是多個微服務應用共用的，便于在該項目中統(tǒng)一對配置進行管理。

創(chuàng)建項目時，選擇的部門如為「微服務公共平臺(dpms)」

各微服務應用項目創(chuàng)建后可以添加Namespace，選擇關聯(lián)公共配置。

公共配置命名規(guī)則：{部門前綴}.application  或者 {部門前綴}.application-{具體的細分配置}

當Apollo配置發(fā)布后，若需讓Spring Cloud配置實現(xiàn)動態(tài)加載，公共配置命名必須以application關鍵字開頭，在上述依賴的jar包中會對這類命名的Namespace做配置變更監(jiān)聽。

例如：

•  dpms.application-eureka 存放eureka相關配置
•  或 dpms.application-zipkin 存放zipkin相關配置
•  或 dpms.application  存放Spring Cloud所有的公共相關配置
•  其他微服務應用關聯(lián)公共配置后，默認使用的公共配置項。
•  你也可以對公共配置所有參數(shù)做覆蓋，覆蓋后優(yōu)先獲取本項目中的配置，這個特性在Apolo的公共配置界面能夠直觀的展示出來。

以上就是對為什么要選擇Apollo配置中心的一些介紹，相信你的項目中可能也遇到了類似的配置管理問題或痛點，強烈建議使用Apollo配置中心作為你的配置管理基礎服務使用。

關于Apollo更詳盡的文檔請參考Github：

    ★    https://github.com/ctripcorp/apollo