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

配置中心基礎(chǔ)

為什么要用配置中心？

配置中心支持功能

常用配置中心

寫在前面

Apollo

Disconf

Spring Cloud Config

Nacos

配置中心對比和選型

配置中心對比

配置中心選型

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

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

配置中心基礎(chǔ)

為什么要用配置中心？

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

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

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

配置中心支持功能

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

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

版本管理&回滾 ：當(dāng)配置變更不符合預(yù)期的時候，需要根據(jù)配置的發(fā)布版本進行回滾。

配置格式校驗 ：應(yīng)用的配置數(shù)據(jù)存儲在配置中心一般都會以一種配置格式存儲，比如Properties、Json、Yaml等，如果配置格式錯誤，會導(dǎo)致客戶端解析配置失敗引起生產(chǎn)故障，配置中心對配置的格式校驗?zāi)軌蛴行Х乐谷藶殄e誤操作的發(fā)生，是配置中心核心功能中的剛需。

監(jiān)聽查詢 ：當(dāng)排查問題或者進行統(tǒng)計的時候，需要知道一個配置被哪些應(yīng)用實例使用到，以及一個實例使用到了哪些配置。

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

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

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

常用配置中心

寫在前面

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

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

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

沒有方便的UI管理工具，且缺乏權(quán)限、審核、灰度發(fā)布、審核機制等；

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

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

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

Apollo

GitHub

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

Apollo框架

Apollo的框架有點復(fù)雜，如果不考慮分布式微服務(wù)架構(gòu)中的服務(wù)發(fā)現(xiàn)問題，Apollo的最簡架構(gòu)如下圖所示：

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

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

AdminService ：提供配置管理接口，提供配置修改發(fā)布接口，服務(wù)于管理界面Portal。

Client ：為應(yīng)用獲取配置，支持實時更新，通過MetaServer獲取ConfigService的服務(wù)列表，使用客戶端軟負載SLB方式調(diào)用ConfigService。

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

調(diào)用流程 ：

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

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

AdminService是一個獨立的微服務(wù)，服務(wù)于Portal進行配置管理。Portal通過調(diào)用AdminService進行配置管理和發(fā)布。

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

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

加上分布式微服務(wù)架構(gòu)中的服務(wù)發(fā)現(xiàn)，真正的Apollo框架如下：

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

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

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

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

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

我講的已經(jīng)夠清楚了，如果還是不懂，就看這篇文章 [微服務(wù)架構(gòu)~攜程Apollo配置中心架構(gòu)剖析》

Apollo特性

統(tǒng)一管理不同環(huán)境、不同集群的配置 ：

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

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

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

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

版本發(fā)布管理 + 灰度發(fā)布

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

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

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

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

支持Spring Placeholder、Annotation和Spring Boot的ConfigurationProperties，方便應(yīng)用使用。

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

提供開放平臺API ：

Apollo自身提供了比較完善的統(tǒng)一配置管理界面，支持多環(huán)境、多數(shù)據(jù)中心配置管理、權(quán)限、流程治理等特性。

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

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

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

Disconf

GitHub

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

Disconf框架

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

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

Disconf特點

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

配置發(fā)布統(tǒng)一化

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

配置更新自動化：用戶在平臺更新配置，使用該配置的系統(tǒng)會自動發(fā)現(xiàn)該情況，并應(yīng)用新配置。特殊地，如果用戶為此配置定義了回調(diào)函數(shù)類，則此函數(shù)類會被自動調(diào)用。

配置異構(gòu)系統(tǒng)管理：

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

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

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

需要Spring編程環(huán)境。

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

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

Spring Cloud Config

GitHub

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

Spring Cloud Config 工作原理

應(yīng)用架構(gòu)圖：

工作流程：

在部署環(huán)境之前，需要將相應(yīng)的配置信息推送到配置倉庫；

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

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

其他應(yīng)用啟動，從配置服務(wù)器拉取配置。（配置中心還支持動態(tài)刷新配置信息，不需要重啟應(yīng)用，通過spring-cloud-config-monitor監(jiān)控模塊，其中包含了/monitor刷新API，webhook調(diào)用該端點API，達到動態(tài)刷新的效果。）

Spring Cloud Config 特點

提供配置的服務(wù)端和客戶端支持；

集中式管理分布式環(huán)境下的應(yīng)用配置；

基于 Spring 環(huán)境，可以無縫與Spring應(yīng)用集成；

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

默認實現(xiàn)基于git倉庫，可以進行版本管理。

Nacos

Nacos官網(wǎng)

Nacos 致力于幫助您發(fā)現(xiàn)、配置和管理微服務(wù)。Nacos 提供了一組簡單易用的特性集，幫助您快速實現(xiàn)動態(tài)服務(wù)發(fā)現(xiàn)、服務(wù)配置、服務(wù)元數(shù)據(jù)及流量管理。

Nacos 幫助您更敏捷和容易地構(gòu)建、交付和管理微服務(wù)平臺。Nacos 是構(gòu)建以“服務(wù)”為中心的現(xiàn)代應(yīng)用架構(gòu) (例如微服務(wù)范式、云原生范式) 的服務(wù)基礎(chǔ)設(shè)施。

Nacos 主要特點

服務(wù)發(fā)現(xiàn)和服務(wù)健康監(jiān)測 ：

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

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

動態(tài)配置服務(wù) ：

動態(tài)配置服務(wù)可以讓您以中心化、外部化和動態(tài)化的方式管理所有環(huán)境的應(yīng)用配置和服務(wù)配置。

動態(tài)配置消除了配置變更時重新部署應(yīng)用和服務(wù)的需要，讓配置管理變得更加高效和敏捷。

配置中心化管理讓實現(xiàn)無狀態(tài)服務(wù)變得更簡單，讓服務(wù)按需彈性擴展變得更容易。

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

動態(tài) DNS 服務(wù) ：

動態(tài) DNS 服務(wù)支持權(quán)重路由，讓您更容易地實現(xiàn)中間層負載均衡、更靈活的路由策略、流量控制以及數(shù)據(jù)中心內(nèi)網(wǎng)的簡單DNS解析服務(wù)。動態(tài)DNS服務(wù)還能讓您更容易地實現(xiàn)以 DNS 協(xié)議為基礎(chǔ)的服務(wù)發(fā)現(xiàn)，以幫助您消除耦合到廠商私有服務(wù)發(fā)現(xiàn) API 上的風(fēng)險。

Nacos 提供了一些簡單的 DNS APIs TODO 幫助您管理服務(wù)的關(guān)聯(lián)域名和可用的 IP:PORT 列表。

小節(jié)一下：

Nacos是阿里開源的，支持基于 DNS 和基于 RPC 的服務(wù)發(fā)現(xiàn)。

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

Nacos除了服務(wù)的注冊發(fā)現(xiàn)之外，還支持動態(tài)配置服務(wù) ，一句話概括就是Nacos = Spring Cloud注冊中心 + Spring Cloud配置中心 。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

配置中心對比和選型

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

配置中心對比

灰度發(fā)布 ：

Spring Cloud Config支持通過/bus/refresh端點的destination參數(shù)來指定要更新配置的機器，不過整個流程不夠自動化和體系化。

Apollo可以直接在控制臺上點灰度發(fā)布指定發(fā)布機器的IP，接著再全量發(fā)布，做得比較體系化。Nacos目前發(fā)布到0.9版本，還不支持灰度發(fā)布。

權(quán)限管理 ：

Spring Cloud Config依賴Git的權(quán)限管理能力，開源的GitHub權(quán)限控制可以分為Admin、Write和Read權(quán)限，權(quán)限管理比較完善。

Apollo通過項目的維度來對配置進行權(quán)限管理，一個項目的owner可以授權(quán)給其他用戶配置的修改發(fā)布權(quán)限。

Nacos目前看還不具備權(quán)限管理能力。

版本管理&回滾 ：

Spring Cloud Config、Apollo和Nacos都具備配置的版本管理和回滾能力，可以在控制臺上查看配置的變更情況或進行回滾操作。

Spring Cloud Config通過Git來做版本管理，更方便些。

配置格式校驗 ：

Spring Cloud Config使用Git，目前還不支持格式檢驗，格式的正確性依賴研發(fā)人員自己。

Apollo和Nacos都會對配置格式的正確性進行檢驗，可以有效防止人為錯誤。

監(jiān)聽查詢 ：

Spring Cloud Config使用Spring Cloud Bus推送配置變更，Spring Cloud Bus兼容 RabbitMQ、Kafka等，支持查詢訂閱Topic和Consumer的訂閱關(guān)系。

Apollo可以通過灰度實例列表查看監(jiān)聽配置的實例列表，但實例監(jiān)聽的配置(Apollo稱為命名空間)目前還沒有展示出來。

Nacos可以查看監(jiān)聽配置的實例，也可以查看實例監(jiān)聽的配置情況。

基本上，這三個產(chǎn)品都具備監(jiān)聽查詢能力，在我們自己的使用過程中，Nacos使用起來相對簡單，易用性相對更好些。

多環(huán)境 ：

Spring Cloud Config支持Profile的方式隔離多個環(huán)境，通過在Git上配置多個Profile的配置文件，客戶端啟動時指定Profile就可以訪問對應(yīng)的配置文件。

Apollo也支持多環(huán)境，在控制臺創(chuàng)建配置的時候就要指定配置所在的環(huán)境，客戶端在啟動的時候指定JVM參數(shù)ENV來訪問對應(yīng)環(huán)境的配置文件。

Nacos通過命名空間來支持多環(huán)境，每個命名空間的配置相互隔離，客戶端指定想要訪問的命名空間就可以達到邏輯隔離的作用。

多集群 ：

Spring Cloud Config可以通過搭建多套Config Server，Git使用同一個Git的多個倉庫，來實現(xiàn)物理隔離。

Apollo可以搭建多套集群，Apollo的控制臺和數(shù)據(jù)更新推送服務(wù)分開部署，控制臺部署一套就可以管控多個集群。

Nacos控制臺和后端配置服務(wù)是部署在一起的，可以通過不同的域名切換來支持多集群。

配置實時推送 ：

Nacos和Apollo配置推送都是基于HTTP長輪詢，客戶端和配置中心建立HTTP長聯(lián)接，當(dāng)配置變更的的時候，配置中心把配置推送到客戶端。

Spring Cloud Config原生不支持配置的實時推送，需要依賴Git的WebHook、Spring Cloud Bus和客戶端/bus/refresh端點。

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

多語言支持 ：

Spring Cloud服務(wù)于Java生態(tài)，一開始只是針對Java微服務(wù)應(yīng)用，對于非Java應(yīng)用的微服務(wù)調(diào)用，可以使用Sidecar提供了HTTP API，但動態(tài)配置方面還不能很好的支持。

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

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

性能對比 ：

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

配置中心選型

總的來說：

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

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

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

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

此外，Nacos除了提供配置中心的功能，還提供了動態(tài)服務(wù)發(fā)現(xiàn)、服務(wù)共享與管理的功能，降低了服務(wù)化改造過程中的難度。

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

審核編輯：劉清