介紹4種常用的配置中心

配置中心基礎(chǔ)

為什么要用配置中心？

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

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

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

配置中心支持功能

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

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

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

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

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

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

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

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

常用配置中心

寫在前面

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

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

但是我們選擇配置中心時(shí)，為什么不優(yōu)先考慮Zookeeper和ETCD，因?yàn)橐韵聝牲c(diǎn)原因：

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

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

大白話總結(jié)一下，就是專業(yè)的人干專業(yè)的事，他兩很多功能沒法支持 ?？赡苣銜?huì)問(wèn)，那你們公司為啥用ETCD作為配置中心呢？因?yàn)槲覀冏约簩懥藗€(gè)后臺(tái)，支持權(quán)限、灰度發(fā)布、版本控制等功能。

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

Apollo

GitHub

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

Apollo框架

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

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

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

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

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

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

調(diào)用流程 ：

ConfigService是一個(gè)獨(dú)立的微服務(wù)，服務(wù)于Client進(jìn)行配置獲取。

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

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

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

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

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

如果你了解RPC和注冊(cè)中心，這幅圖其實(shí)不難理解：

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

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

由于Meta Server是集群部署，需要搞個(gè)NginxLB去找Meta Server機(jī)器。

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

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

Apollo特性

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

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

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

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

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

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

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

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

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

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

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

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

提供開放平臺(tái)API ：

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

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

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

最后通過(guò)后臺(tái)界面，直觀感受一下：

Disconf

GitHub

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

Disconf框架

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

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

Disconf特點(diǎn)

支持配置（配置項(xiàng)+配置文件）的分布式化管理：

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

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

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

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

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

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

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

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

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

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

Spring Cloud Config

GitHub

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

Spring Cloud Config 工作原理

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

工作流程：

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

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

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

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

Spring Cloud Config 特點(diǎn)

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

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

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

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

默認(rèn)實(shí)現(xiàn)基于git倉(cāng)庫(kù)，可以進(jìn)行版本管理。

Nacos

Nacos官網(wǎng)

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

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

Nacos 主要特點(diǎn)

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

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

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

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

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

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

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

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

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

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

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

小節(jié)一下：

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

Nacos的注冊(cè)中心支持CP也支持AP ，對(duì)他來(lái)說(shuō)只是一個(gè)命令的切換，隨你玩，還支持各種注冊(cè)中心遷移到Nacos，反正一句話，只要你想要的他就有。

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

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

配置中心對(duì)比和選型

由于 Disconf 不再維護(hù)，下面對(duì)比一下 Spring Cloud Config、Apollo 和 Nacos。

配置中心對(duì)比

灰度發(fā)布 ：

Spring Cloud Config支持通過(guò)/bus/refresh端點(diǎn)的destination參數(shù)來(lái)指定要更新配置的機(jī)器，不過(guò)整個(gè)流程不夠自動(dòng)化和體系化。

Apollo可以直接在控制臺(tái)上點(diǎn)灰度發(fā)布指定發(fā)布機(jī)器的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通過(guò)項(xiàng)目的維度來(lái)對(duì)配置進(jìn)行權(quán)限管理，一個(gè)項(xiàng)目的owner可以授權(quán)給其他用戶配置的修改發(fā)布權(quán)限。

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

版本管理&回滾 ：

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

Spring Cloud Config通過(guò)Git來(lái)做版本管理，更方便些。

配置格式校驗(yàn) ：

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

Apollo和Nacos都會(huì)對(duì)配置格式的正確性進(jìn)行檢驗(yàn)，可以有效防止人為錯(cuò)誤。

監(jiān)聽查詢 ：

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

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

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

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

多環(huán)境 ：

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

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

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

多集群 ：

Spring Cloud Config可以通過(guò)搭建多套Config Server，Git使用同一個(gè)Git的多個(gè)倉(cāng)庫(kù)，來(lái)實(shí)現(xiàn)物理隔離。

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

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

配置實(shí)時(shí)推送 ：

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

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

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

多語(yǔ)言支持 ：

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

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

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

性能對(duì)比 ：

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

配置中心選型

總的來(lái)說(shuō)：

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

Apollo相對(duì)于Nacos在配置管理做的更加全面，不過(guò)使用起來(lái)也要麻煩一些。

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

Nacos使用起來(lái)相對(duì)比較簡(jiǎn)潔，在對(duì)性能要求比較高的大規(guī)模場(chǎng)景更適合。

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

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

審核編輯：劉清