深度對比三種主流微服務配置中心
【編者的話】在撰寫這篇技術選型的文章之前，是比較猶豫的。因為，以其中一個開源專案開發者的身份，去寫一篇三個開源專案的對比，即便很剋制的去客觀的比較，也很難有信服力。這就像，既是參賽選手，又想做裁判，觀眾肯定是不買賬的。
但最後，仍然決定去寫一篇配置中心的技術選型參考文，是因為：
- 工作所需，要做一款好用的開源產品，去試用提供相似功能的開源產品是必要的環節，以找出優勢，彌補不足；
- 使用者所需，對於提供相似功能的產品進行選型對比，是引入某個開源專案必須要做的事，如果有一份參考，那麼勢必能提供一些幫助；（建議：即便有一份可參考的材料，技術選型的工作仍需要親力親為，實際的業務場景和資源配置才是技術選型最重要的依據）；
- 微服務配置中心是一個微服務元件，而不是一個大的框架，選型成本較小，客觀對比時不易走偏；
本文將從產品功能、使用體驗、實施過程和效能4個緯度進行對比，所有素材均來源於該開源專案的官網或GitHub專案頁。
如果您對微服務配置中心的功能不是很瞭解，可以看下以下的背景介紹，若比較熟悉可以直接跳過。
為什麼需要配置中心
配置實時生效：
傳統的靜態配置方式要想修改某個配置只能修改之後重新發布應用，要實現動態性，可以選擇使用資料庫，通過定時輪詢訪問資料庫來感知配置的變化。輪詢頻率低感知配置變化的延時就長，輪詢頻率高，感知配置變化的延時就短，但比較損耗效能，需要在實時性和效能之間做折中。配置中心專門針對這個業務場景，兼顧實時性和一致性來管理動態配置。
配置管理流程：
配置的許可權管控、灰度釋出、版本管理、格式檢驗和安全配置等一系列的配置管理相關的特性也是配置中心不可獲取的一部分。
開源配置中心基本介紹
目前市面上用的比較多的配置中心有（按開源時間排序）：
- 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數量、社群的交流頻次等）、社群的規範程度（免責說明、安全性說明等），這些可能才是使用者更關注的內容。
參考文件：
作者：風卿，Nacos 社群 committer