公司為啥用ETCD作為配置中心呢

配置中心基礎

為什么要用配置中心？

配置中心支持功能

常用配置中心

寫在前面

Apollo

Disconf

Spring Cloud Config

Nacos

配置中心對比和選型

配置中心對比

配置中心選型

本文講解4種常用的配置中心，對比其流程和原理，無論是面試還是技術選型，都非常有幫助。

學完注冊中心，再看配置中心這塊，感覺簡單很多，因為很多知識原理是相輔相成的，下面是文章目錄：

配置中心基礎

為什么要用配置中心？

配置實時生效 ：傳統的靜態配置方式要想修改某個配置只能修改之后重新發布應用，要實現動態性，可以選擇使用數據庫，通過定時輪詢訪問數據庫來感知配置的變化。輪詢頻率低感知配置變化的延時就長，輪詢頻率高，感知配置變化的延時就短，但比較損耗性能，需要在實時性和性能之間做折中。配置中心專門針對這個業務場景，兼顧實時性和一致性來管理動態配置 ；

配置管理流程 ：配置的權限管控、灰度發布、版本管理、格式檢驗和安全配置等一系列的配置管理相關的特性，也是配置中心不可獲取的一部分；

分布式場景 ：隨著采用分布式的開發模式，項目之間的相互引用隨著服務的不斷增多，相互之間的調用復雜度成指數升高，每次投產或者上線新的項目時苦不堪言，需要引用配置中心治理。

配置中心支持功能

灰度發布 ：配置的灰度發布是配置中心比較重要的功能，當配置的變更影響比較大的時候，需要先在部分應用實例中驗證配置的變更是否符合預期，然后再推送到所有應用實例。

權限管理 ：配置的變更和代碼變更都是對應用運行邏輯的改變，重要的配置變更常常會帶來核彈的效果，對于配置變更的權限管控和審計能力同樣是配置中心重要的功能。

版本管理&回滾 ：當配置變更不符合預期的時候，需要根據配置的發布版本進行回滾。

配置格式校驗 ：應用的配置數據存儲在配置中心一般都會以一種配置格式存儲，比如Properties、Json、Yaml等，如果配置格式錯誤，會導致客戶端解析配置失敗引起生產故障，配置中心對配置的格式校驗能夠有效防止人為錯誤操作的發生，是配置中心核心功能中的剛需。

監聽查詢 ：當排查問題或者進行統計的時候，需要知道一個配置被哪些應用實例使用到，以及一個實例使用到了哪些配置。

多環境 ：在實際生產中，配置中心常常需要涉及多環境或者多集群，業務在開發的時候可以將開發環境和生產環境分開，或者根據不同的業務線存在多個生產環境。如果各個環境之間的相互影響比較?。ㄩ_發環境影響到生產環境穩定性），配置中心可以通過邏輯隔離的方式支持多環境。

多集群 ：當對穩定性要求比較高，不允許各個環境相互影響的時候，需要將多個環境通過多集群的方式進行物理隔離。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

常用配置中心

寫在前面

如果只要能作為分布式存儲的服務都作為配置中心，那選擇途徑就太多了， 比如Zookeeper和ETCD，所以需要提前說明一下。

在文章 《注冊中心原理和選型：Zookeeper、Eureka、Nacos、Consul和ETCD》 已經提到過，Zookeeper和ETCD可以存儲數據，作為配置中心使用，比如我司的微服務網關，將配置發布到ETCD，供網關各模塊調用，具體可以參考文章 《微服務網關：從對比到選型，由理論到實踐》。

但是我們選擇配置中心時，為什么不優先考慮Zookeeper和ETCD，因為以下兩點原因：

沒有方便的UI管理工具，且缺乏權限、審核、灰度發布、審核機制等；

最重要的是，Zookeeper和ETCD通常定義為服務注冊中心，統一配置中心的事情交給專業的工具去解決。

大白話總結一下，就是專業的人干專業的事，他兩很多功能沒法支持 ?？赡苣銜?，那你們公司為啥用ETCD作為配置中心呢？因為我們自己寫了個后臺，支持權限、灰度發布、版本控制等功能。

所以給大家介紹的配置中心，主要是以下4種，分別為 Disconf、Spring Cloud Config、Apollo 和 Nacos 。

Apollo

GitHub

Apollo（阿波羅）是攜程框架部門研發的開源配置管理中心，具備規范的權限、流程治理等特性。

Apollo框架

Apollo的框架有點復雜，如果不考慮分布式微服務架構中的服務發現問題，Apollo的最簡架構如下圖所示：

這里面包含Apollo框架的4個核心模塊 ：

ConfigService ：提供配置獲取接口，提供配置推送接口，服務于Apollo客戶端。

AdminService ：提供配置管理接口，提供配置修改發布接口，服務于管理界面Portal。

Client ：為應用獲取配置，支持實時更新，通過MetaServer獲取ConfigService的服務列表，使用客戶端軟負載SLB方式調用ConfigService。

Portal ：配置管理界面，通過MetaServer獲取AdminService的服務列表，使用客戶端軟負載SLB方式調用AdminService。

調用流程 ：

ConfigService是一個獨立的微服務，服務于Client進行配置獲取。

Client和ConfigService保持長連接，通過一種拖拉結合(push & pull)的模式，實現配置實時更新的同時，保證配置更新不丟失。

AdminService是一個獨立的微服務，服務于Portal進行配置管理。Portal通過調用AdminService進行配置管理和發布。

ConfigService和AdminService共享ConfigDB，ConfigDB中存放項目在某個環境的配置信息。ConfigService/AdminService/ConfigDB三者在每個環境(DEV/FAT/UAT/PRO)中都要部署一份。

Protal有一個獨立的PortalDB，存放用戶權限、項目和配置的元數據信息。Protal只需部署一份，它可以管理多套環境。

加上分布式微服務架構中的服務發現，真正的Apollo框架如下：

如果你了解RPC和注冊中心，這幅圖其實不難理解：

Eureka用于注冊中心，AP原則，所以Config Service和Admin Service的機器列表注冊到Eureka中；

Client和Portal需要獲取注冊中心的機器列表，但是由于Eureka僅支持Java客戶端，所以搞個Meta Server，將Eureka的服務發現接口以HTTP接口的形式暴露出來；

由于Meta Server是集群部署，需要搞個NginxLB去找Meta Server機器。

所以搞NginxLB + Meta Server，其實就是為了找Eureka中的機器列表配置，Client和Portal拿到這些機器配置，就可以發起調用了，最后就回到我們前面的簡圖，是不是So Easy!

我講的已經夠清楚了，如果還是不懂，就看這篇文章 [微服務架構~攜程Apollo配置中心架構剖析》

Apollo特性

統一管理不同環境、不同集群的配置 ：

Apollo提供了一個統一界面集中式管理不同環境（environment）、不同集群（cluster）、不同命名空間（namespace）的配置。

同一份代碼部署在不同的集群，可以有不同的配置，比如zk的地址等。

通過命名空間（namespace）可以很方便的支持多個不同應用共享同一份配置，同時還允許應用對共享的配置進行覆蓋。

配置修改實時生效（熱發布） ：用戶在Apollo修改完配置并發布后，客戶端能實時（1秒）接收到最新的配置，并通知到應用程序。

版本發布管理 + 灰度發布

權限管理、發布審核、操作審計 ：應用和配置的管理都有完善的權限管理機制，對配置的管理還分為了編輯和發布兩個環節，從而減少人為的錯誤。所有的操作都有審計日志，可以方便的追蹤問題。

客戶端配置信息監控 ：可以在界面上方便地看到配置在被哪些實例使用。

提供Java和.Net原生客戶端 ：

提供了Java和.Net的原生客戶端，方便應用集成。

支持Spring Placeholder、Annotation和Spring Boot的ConfigurationProperties，方便應用使用。

提供了Http接口，非Java和.Net應用也可以方便的使用。

提供開放平臺API ：

Apollo自身提供了比較完善的統一配置管理界面，支持多環境、多數據中心配置管理、權限、流程治理等特性。

Apollo出于通用性考慮，對配置的修改不會做過多限制，只要符合基本的格式就能夠保存。

對于有些使用方，它們的配置可能會有比較復雜的格式，而且對輸入的值也需要進行校驗后方可保存，如檢查數據庫、用戶名和密碼是否匹配。對于這類應用，Apollo支持應用方通過開放接口在Apollo進行配置的修改和發布，并且具備完善的授權和權限控制。

最后通過后臺界面，直觀感受一下：

Disconf

GitHub

2014年7月百度開源的配置管理中心，同樣具備配置的管理能力，不過目前已經不維護，最近的一次提交是兩年前了。

Disconf框架

Disconf是一套完整的基于zookeeper的分布式配置統一解決方案，它通過disconf-web管理配置信息，然后將配置的key在Zookeeper上建立節點，disconf-client啟動后拉取自身需要的配置信息并監聽Zookeeper的節點。在web上更新配置信息會觸發zk節點狀態的變動，client可以實時感知到變化，然后從web上拉取最新配置信息。

這里想吐槽一下，Disconf官方文檔的圖畫真的丑啊，關鍵是很不清晰，就不能好好維護一下么？

Disconf特點

支持配置（配置項+配置文件）的分布式化管理：

配置發布統一化

配置發布、更新統一化（云端存儲、發布）：配置存儲在云端系統，用戶統一在平臺上進行發布、更新配置。

配置更新自動化：用戶在平臺更新配置，使用該配置的系統會自動發現該情況，并應用新配置。特殊地，如果用戶為此配置定義了回調函數類，則此函數類會被自動調用。

配置異構系統管理：

異構包部署統一化：這里的異構系統是指一個系統部署多個實例時，由于配置不同，從而需要多個部署包（jar或war）的情況（下同）。使用Disconf后，異構系統的部署只需要一個部署包，不同實例的配置會自動分配。特別地，在業界大量使用部署虛擬化（如JPAAS系統，SAE，BAE）的情況下，同一個系統使用同一個部署包的情景會越來越多，Disconf可以很自然地與他天然契合。異構主備自動切換：如果一個異構系統存在主備機，主機發生掛機時，備機可以自動獲取主機配置從而變成主機。

異構主備機Context共享工具：異構系統下，主備機切換時可能需要共享Context?？梢允褂肅ontext共享工具來共享主備的Context。

注解式編程，極簡的使用方式：我們追求的是極簡的、用戶編程體驗良好的編程方式。通過簡單的標注+極簡單的代碼撰寫，即可完成復雜的配置分布式化。

需要Spring編程環境。

可以托管任何類型的配置文件。

提供界面良好Web管理功能，可以非常方便的查看配置被哪些實例使用了。

Spring Cloud Config

GitHub

2014年9月開源，Spring Cloud 生態組件，可以和Spring Cloud體系無縫整合。

Spring Cloud Config 工作原理

應用架構圖：

工作流程：

在部署環境之前，需要將相應的配置信息推送到配置倉庫；

配置服務器啟動之后，將配置信息拉取并同步至本地倉庫；

配置服務器對外提供REST接口，其他所有的配置客戶端啟動時根據spring.cloud.config配置的{application}/{profile}/{label}信息去配置服務器拉取相應的配置。配置倉庫支持多樣的源，如Git、SVN、jdbc數據庫和本地文件系統等。

其他應用啟動，從配置服務器拉取配置。（配置中心還支持動態刷新配置信息，不需要重啟應用，通過spring-cloud-config-monitor監控模塊，其中包含了/monitor刷新API，webhook調用該端點API，達到動態刷新的效果。）

Spring Cloud Config 特點

提供配置的服務端和客戶端支持；

集中式管理分布式環境下的應用配置；

基于 Spring 環境，可以無縫與Spring應用集成；

可用于任何語言開發的程序，為其管理與提供配置信息；

默認實現基于git倉庫，可以進行版本管理。

Nacos

Nacos官網

Nacos 致力于幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集，幫助您快速實現動態服務發現、服務配置、服務元數據及流量管理。

Nacos 幫助您更敏捷和容易地構建、交付和管理微服務平臺。Nacos 是構建以“服務”為中心的現代應用架構 (例如微服務范式、云原生范式) 的服務基礎設施。

Nacos 主要特點

服務發現和服務健康監測 ：

Nacos 支持基于 DNS 和基于 RPC 的服務發現。服務提供者使用原生SDK、OpenAPI、或一個獨立的Agent TODO注冊 Service 后，服務消費者可以使用DNS TODO 或HTTP&API查找和發現服務。

Nacos 提供對服務的實時的健康檢查，阻止向不健康的主機或服務實例發送請求。Nacos 支持傳輸層 (PING 或 TCP)和應用層 (如 HTTP、MySQL、用戶自定義）的健康檢查。對于復雜的云環境和網絡拓撲環境中（如 VPC、邊緣網絡等）服務的健康檢查，Nacos 提供了 agent 上報模式和服務端主動檢測2種健康檢查模式。Nacos 還提供了統一的健康檢查儀表盤，幫助您根據健康狀態管理服務的可用性及流量。

動態配置服務 ：

動態配置服務可以讓您以中心化、外部化和動態化的方式管理所有環境的應用配置和服務配置。

動態配置消除了配置變更時重新部署應用和服務的需要，讓配置管理變得更加高效和敏捷。

配置中心化管理讓實現無狀態服務變得更簡單，讓服務按需彈性擴展變得更容易。

Nacos 提供了一個簡潔易用的UI (控制臺樣例 Demo) 幫助您管理所有的服務和應用的配置。Nacos 還提供包括配置版本跟蹤、金絲雀發布、一鍵回滾配置以及客戶端配置更新狀態跟蹤在內的一系列開箱即用的配置管理特性，幫助您更安全地在生產環境中管理配置變更和降低配置變更帶來的風險。

動態 DNS 服務 ：

動態 DNS 服務支持權重路由，讓您更容易地實現中間層負載均衡、更靈活的路由策略、流量控制以及數據中心內網的簡單DNS解析服務。動態DNS服務還能讓您更容易地實現以 DNS 協議為基礎的服務發現，以幫助您消除耦合到廠商私有服務發現 API 上的風險。

Nacos 提供了一些簡單的 DNS APIs TODO 幫助您管理服務的關聯域名和可用的 IP:PORT 列表。

小節一下：

Nacos是阿里開源的，支持基于 DNS 和基于 RPC 的服務發現。

Nacos的注冊中心支持CP也支持AP ，對他來說只是一個命令的切換，隨你玩，還支持各種注冊中心遷移到Nacos，反正一句話，只要你想要的他就有。

Nacos除了服務的注冊發現之外，還支持動態配置服務 ，一句話概括就是Nacos = Spring Cloud注冊中心 + Spring Cloud配置中心 。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

配置中心對比和選型

由于 Disconf 不再維護，下面對比一下 Spring Cloud Config、Apollo 和 Nacos。

配置中心對比

灰度發布 ：

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來做版本管理，更方便些。

配置格式校驗 ：

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端點。

Nacos和Apollo在配置實時推送鏈路上是比較簡單高效的，Spring Cloud Config的配置推送引入Spring Cloud Bus，鏈路較長，比較復雜。

多語言支持 ：

Spring Cloud服務于Java生態，一開始只是針對Java微服務應用，對于非Java應用的微服務調用，可以使用Sidecar提供了HTTP API，但動態配置方面還不能很好的支持。

Apollo已經支持了多種語言，并且提供了open API。其他不支持的語言，Apollo的接入成本相對較低。

Nacos支持主流的語言，例如Java、Go、Python、Nodejs、PHP等，也提供了open API。

性能對比 ：

Nacos的讀寫性能最高，Apollo次之，Spring Cloud Config的依賴Git場景不適合開放的大規模自動化運維API。

配置中心選型

總的來說：

Apollo和Nacos相對于Spring Cloud Config的生態支持更廣，在配置管理流程上做的更好。

Apollo相對于Nacos在配置管理做的更加全面，不過使用起來也要麻煩一些。

Apollo容器化較困難，Nacos有官網的鏡像可以直接部署，總體來說，Nacos比Apollo更符合KISS原則。

Nacos使用起來相對比較簡潔，在對性能要求比較高的大規模場景更適合。

此外，Nacos除了提供配置中心的功能，還提供了動態服務發現、服務共享與管理的功能，降低了服務化改造過程中的難度。

但對于一個開源項目的選型，除了以上這幾個方面，項目上的人力投入（迭代進度、文檔的完整性）、社區的活躍度（issue的數量和解決速度、Contributor數量、社群的交流頻次等）、社區的規范程度（免責說明、安全性說明等），這些可能才是用戶更關注的內容。

審核編輯：劉清