本文將從產品功能、使用體驗、實施過程和性能4個緯度進行對比，全部素材均來源於該開源項目的官網或GitHub項目頁。html
若是您對微服務配置中心的功能不是很瞭解，能夠看下如下的背景介紹，若比較熟悉能夠直接跳過。git
爲何須要配置中心
配置實時生效：github
傳統的靜態配置方式要想修改某個配置只能修改以後從新發布應用，要實現動態性，能夠選擇使用數據庫，經過定時輪詢訪問數據庫來感知配置的變化。輪詢頻率低感知配置變化的延時就長，輪詢頻率高，感知配置變化的延時就短，但比較損耗性能，須要在實時性和性能之間作折中。配置中心專門針對這個業務場景，兼顧實時性和一致性來管理動態配置。spring
配置管理流程：數據庫
配置的權限管控、灰度發佈、版本管理、格式檢驗和安全配置等一系列的配置管理相關的特性也是配置中心不可獲取的一部分。後端
開源配置中心基本介紹
目前市面上用的比較多的配置中心有：（按開源時間排序）緩存
Disconf安全
2014年7月百度開源的配置管理中心，一樣具有配置的管理能力，不過目前已經不維護了，最近的一次提交是兩年前了。網絡
Spring Cloud Config併發
2014年9月開源，Spring Cloud 生態組件，能夠和Spring Cloud體系無縫整合。
Apollo
2016年5月，攜程開源的配置管理中心，具有規範的權限、流程治理等特性。
Nacos
2018年6月，阿里開源的配置中心，也能夠作DNS和RPC的服務發現。
配置中心核心概念的對比
因爲Disconf再也不維護，下面對比一下Spring Cloud Config、Apollo和Nacos。 Spring Cloud Config、Apollo和Nacos在配置管理領域的概念基本相同，可是也存在一些不一樣的點，使用配置的過程當中會涉及到一些比較重要的概念。
應用
應用是客戶端系統的基本單位，Spring Cloud Config 將應用名稱和對應Git中的文件名稱關聯起來了，這樣能夠起到多個應用配置相互隔離的做用。Apollo的配置都是在某個應用下面的（除了公共配置），也起到了多個應用配置相互隔離的做用。Nacos的應用概念比較弱，只有一個用於區分配置的額外屬性，不過可使用 Group 來作應用字段，能夠起到隔離做用。
集羣
不一樣的環境能夠搭建不一樣的集羣，這樣能夠起到物理隔離的做用，Spring Cloud Config、Apollo、Nacos都支持多個集羣。
Label Profile & 環境 & 命名空間
Spring Cloud Config可使用Label和Profile來作邏輯隔離，Label指遠程倉庫的分支，Profile相似Maven Profile能夠區分環境，好比{application}-{profile}.properties。
Nacos的命名空間和Apollo的環境同樣，是一個邏輯概念，能夠做爲環境邏輯隔離。Apollo中的命名空間指配置的名稱，具體的配置項指配置文件中的一個Property。
配置管理功能的對比
做爲配置中心，配置的整個管理流程應該具有流程化能力。
灰度發佈
配置的灰度發佈是配置中心比較重要的功能，當配置的變動影響比較大的時候，須要先在部分應用實例中驗證配置的變動是否符合預期，而後再推送到全部應用實例。
Spring Cloud Config支持經過/bus/refresh端點的destination參數來指定要更新配置的機器，不過整個流程不夠自動化和體系化。
Apollo能夠直接在控制檯上點灰度發佈指定發佈機器的IP，接着再全量發佈，作得比較體系化。 Nacos目前發佈到0.9版本，還不支持灰度發佈。
權限管理
配置的變動和代碼變動都是對應用運行邏輯的改變，重要的配置變動經常會帶來核彈的效果，對於配置變動的權限管控和審計能力一樣是配置中心重要的功能。
Spring Cloud Config依賴Git的權限管理能力，開源的GitHub權限控制能夠分爲Admin、Write和Read權限，權限管理比較完善。
Apollo經過項目的維度來對配置進行權限管理，一個項目的owner能夠受權給其餘用戶配置的修改發佈權限。
Nacos目前看還不具有權限管理能力。
版本管理&回滾
當配置變動不符合預期的時候，須要根據配置的發佈版本進行回滾。Spring Cloud Config、Apollo和Nacos都具有配置的版本管理和回滾能力，能夠在控制檯上查看配置的變動狀況或進行回滾操做。Spring Cloud Config經過Git來作版本管理，更方便些。
配置格式校驗
應用的配置數據存儲在配置中心通常都會以一種配置格式存儲，好比Properties、Json、Yaml等，若是配置格式錯誤，會致使客戶端解析配置失敗引發生產故障，配置中心對配置的格式校驗可以有效防止人爲錯誤操做的發生，是配置中心核心功能中的剛需。 Spring Cloud Config使用Git，目前還不支持格式檢驗，格式的正確性依賴研發人員本身。 Apollo和Nacos都會對配置格式的正確性進行檢驗，能夠有效防止人爲錯誤。
監聽查詢
當排查問題或者進行統計的時候，須要知道一個配置被哪些應用實例使用到，以及一個實例使用到了哪些配置。 Spring Cloud Config使用Spring Cloud Bus推送配置變動，Spring Cloud Bus兼容 RabbitMQ、Kafka等，支持查詢訂閱Topic和Consumer的訂閱關係。 Apollo能夠經過灰度實例列表查看監聽配置的實例列表，但實例監聽的配置(Apollo稱爲命名空間)目前尚未展現出來。
Nacos能夠查看監聽配置的實例，也能夠查看實例監聽的配置狀況。
基本上，這三個產品都具有監聽查詢能力，在咱們本身的使用過程當中，Nacos使用起來相對簡單，易用性相對更好些。
多環境
在實際生產中，配置中心經常須要涉及多環境或者多集羣，業務在開發的時候能夠將開發環境和生產環境分開，或者根據不一樣的業務線存在多個生產環境。若是各個環境之間的相互影響比較小（開發環境影響到生產環境穩定性），配置中心能夠經過邏輯隔離的方式支持多環境。
Spring Cloud Config支持Profile的方式隔離多個環境，經過在Git上配置多個Profile的配置文件，客戶端啓動時指定Profile就能夠訪問對應的配置文件。
Apollo也支持多環境，在控制檯建立配置的時候就要指定配置所在的環境，客戶端在啓動的時候指定JVM參數ENV來訪問對應環境的配置文件。
Nacos經過命名空間來支持多環境，每一個命名空間的配置相互隔離，客戶端指定想要訪問的命名空間就能夠達到邏輯隔離的做用。
多集羣
當對穩定性要求比較高，不容許各個環境相互影響的時候，須要將多個環境經過多集羣的方式進行物理隔離。
Spring Cloud Config能夠經過搭建多套Config Server，Git使用同一個Git的多個倉庫，來實現物理隔離。
Apollo能夠搭建多套集羣，Apollo的控制檯和數據更新推送服務分開部署，控制檯部署一套就能夠管控多個集羣。
Nacos控制檯和後端配置服務是部署在一塊兒的，能夠經過不一樣的域名切換來支持多集羣。
配置實時推送的對比
當配置變動的時候，配置中心須要將配置實時推送到應用客戶端。
Nacos和Apollo配置推送都是基於HTTP長輪詢，客戶端和配置中心創建HTTP長聯接，當配置變動的的時候，配置中心把配置推送到客戶端。
Spring Cloud Config原生不支持配置的實時推送，須要依賴Git的WebHook、Spring Cloud Bus和客戶端/bus/refresh端點:
- 基於Git的WebHook，配置變動觸發server端refresh
- Server端接收到請求併發送給Spring Cloud Bus
- Spring Cloud Bus接到消息並通知給客戶端
- 客戶端接收到通知，請求Server端獲取最新配置
總體比較下來，Nacos和Apollo在配置實時推送鏈路上是比較簡單高效的，Spring Cloud Config的配置推送引入Spring Cloud Bus，鏈路較長，比較複雜。
部署結構 & 高可用的對比
Spring Cloud Config
Spring Cloud Config包含config-server、Git和Spring Cloud Bus三大組件：
- config-server提供給客戶端獲取配置;
- Git用於存儲和修改配置;
- Spring Cloud Bus通知客戶端配置變動;
本地測試模式下，Spring Cloud Bus和config-server須要部署一個節點，Git使用GitHub就能夠。在生產環境中，Spring Cloud Config，config-server須要部署至少兩個節點。Spring Cloud Bus若是使用RabbitMQ，普通集羣模式至少須要兩個節點。
Git服務若是使用GitHub就不用考慮高可用問題，若是考慮到安全性要自建Git私有倉庫，總體的成本比較高。Web服務能夠部署多節點支持高可用，因爲Git有數據的一致性問題，能夠經過如下的方式來支持高可用：
- Git+Keepalived冷備模式，當主Git掛了能夠立刻切到備Git;
- Git多節點部署，存儲使用網絡文件系統或者經過DRBD實現多個Git節點的數據同步;
Apollo
Apollo分爲MySQL，Config Service，Admin Service，Portal四個模塊：
- MySQL存儲Apollo元數據和用戶配置數據;
- Config Service提供配置的讀取、推送等功能，客戶端請求都是落到Config Service上;
- Admin Service提供配置的修改、發佈等功能，Portal操做的服務就是Admin Service;
- Portal提供給用戶配置管理界面;
本地測試Config Service，Admin Service，Portal三個模塊能夠合併一塊兒部署，MySQL單獨安裝並建立須要的表結構。在生產環境使用Apollo，Portal能夠兩個節點單獨部署，穩定性要求沒那麼高的話，Config Service和Admin Service能夠部署在一塊兒，數據庫支持主備容災。
Nacos
Nacos部署須要Nacos Service和MySQL：
- Nacos對外提供服務，支持配置管理和服務發現;
- MySQL提供Nacos的數據持久化存儲;
單機模式下，Nacos可使用嵌入式數據庫部署一個節點，就能啓動。若是對MySQL比較熟悉，想要了解總體數據流向，能夠安裝MySQL提供給Nacos數據持久化服務。生產環境使用Nacos，Nacos服務須要至少部署三個節點，再加上MySQL主備。
總體來看
Nacos的部署結構比較簡單，運維成本較低。Apollo部署組件較多，運維成本比Nacos高。Spring Cloud Config生產高可用的成本最高。
多語言支持的對比
一個公司的各個系統可能語言不盡相同，如今使用的比較多的好比C++，Java，PHP，Python，Nodejs，還有Go等。引入配置中心以後，配置中心要想讓多語言的系統都能享受到動態配置的能力，須要支持多語言生態。
多語言支持
Spring Cloud服務於Java生態，一開始只是針對Java微服務應用，對於非Java應用的微服務調用，可使用Sidecar提供了HTTP API，但動態配置方面還不能很好的支持。 Apollo已經支持了多種語言，而且提供了open API。其餘不支持的語言，Apollo的接入成本相對較低。
Nacos支持主流的語言，例如Java、Go、Python、Nodejs、PHP等，也提供了open API。
遷移支持
國內主流的互聯網公司還是以Java爲主，除了原生Java SDK，在對整個Java生態，好比Spring Boot和Spring Cloud的支持上，三個產品都是支持的。
Spring Cloud Config原生就支持Spring Boot和Spring Cloud，Nacos經過Spring Cloud for Alibaba支持Spring Boot和Spring Cloud生態，符合Spring生態中的標準實現方式，能夠無縫從Spring Cloud Conig遷移到Nacos。
Apollo支持Spring Boot和Spring Cloud項目，可是實現方式不一樣於標準，沒法作無縫遷移，從Spring Cloud遷移到Apollo，存在代碼改造和兼容性成本。
性能對比
性能也是配置中心繞不過的一環，在一樣的機器規格下，若是能支撐更大的業務量，勢必能替公司節省更多的資源成本，提升資源利用率。應用客戶端對配置中心的接口操做有讀、寫和變動通知，因爲變動通知須要大量的客戶端實例，很差模擬測試場景，下面僅對讀和寫操做作了測試。
硬件環境
Nacos和Apollo使用一樣的數據庫（32C128G），部署Server服務的機器使用的8C16G配置的容器，磁盤是100G SSD。
版本
Spring Cloud Config使用2.0.0.M9版本，Apollo使用1.2.0 release版本，Nacos使用0.5版本。
單機讀場景
客戶端測試程序經過部署多臺機器，每臺機器開啓多個線程從配置中心讀取不一樣的配置（3000個）。Nacos QPS能夠達到15000，Apollo分爲讀內存緩存和從數據庫中讀兩種方式，從數據庫中讀能達到7500，從內存讀緩存性能能夠達到9000QPS。Spring Cloud Config使用jGit讀寫Git，因爲有客戶端限制，單機讀能力被限制在7QPS。
3節點讀場景
將配置中心的壓測節點數都部署成3個節點。Nacos QPS能夠達到45000 QPS，Apollo讀內存緩存能夠達到27000 QPS。Nacos和Apollo因爲讀場景各個節點是獨立的，基本就是單機讀場景的3倍關係。Spring Cloud Config三個節點讀能力能夠到達21QPS。
單機寫場景
一樣的方式，多臺機器同時在配置中心修改不一樣的配置。Nacos QPS能夠達到1800，Apollo未使用默認的數據庫鏈接池（10）QPS只能達到800 QPS（CPU未壓滿），調整鏈接池至100能夠達到1100 QPS（CPU壓滿）。Git在提交同一個項目的時候會加鎖，單機Git寫能在5QPS左右，Spring Cloud Config在使用的時候以一個項目做爲數據源，寫能力受到Git限制。
3節點寫場景
一樣的方式，將配置中心的壓測節點數都部署成3個節點。Nacos QPS能夠達到6000，Apollo能夠達到3300 QPS（CPU壓滿），此時MySQL數據庫由於配置較高，未成爲性能瓶頸。Spring Cloud Config三個節點時候，Git也是一個節點，寫QPS爲5。
總體上來看，Nacos的讀寫性能最高，Apollo次之，Spring Cloud Config的依賴Git場景不適合開放的大規模自動化運維API。
功能特性對比總結
這裏列一個表格總結一下三個產品的功能特色。
總的來講，Apollo和Nacos相對於Spring Cloud Config的生態支持更廣，在配置管理流程上作的更好。Apollo相對於Nacos在配置管理作的更加全面，不過使用起來也要麻煩一些。Nacos使用起來相對比較簡潔，在對性能要求比較高的大規模場景更適合。
此外，Nacos除了提供配置中心的功能，還提供了動態服務發現、服務共享與管理的功能，下降了服務化改造過程當中的難度。
以上，咱們從產品功能、使用體驗、實施過程和性能 4 個緯度對Spring Cloud Config、Apollo和Nacos進行對比。但對於一個開源項目的選型，除了以上這4個方面，項目上的人力投入（迭代進度、文檔的完整性）、社區的活躍度（issue的數量和解決速度、Contributor數量、社羣的交流頻次等）、社區的規範程度（免責說明、安全性說明等），這些可能纔是用戶更關注的內容。
參考文檔
https://springcloud.cc/spring-cloud-config.html
https://github.com/ctripcorp/apollo
https://nacos.io/