• 配置中心基礎(chǔ)
• 為什么要用配置中心？
• 配置中心支持功能
• 常用配置中心
• 寫在前面
• Apollo
• Disconf
• Spring Cloud Config
• Nacos
• 配置中心對(duì)比和選型
• 配置中心對(duì)比
• 配置中心選型

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

學(xué)完注冊(cè)中心，再看配置中心這塊，感覺簡單很多，因?yàn)楹芏嘀R(shí)原理是相輔相成的，下面是文章目錄：

配置中心基礎(chǔ)

為什么要用配置中心？

• 配置實(shí)時(shí)生效：傳統(tǒng)的靜態(tài)配置方式要想修改某個(gè)配置只能修改之后重新發(fā)布應(yīng)用，要實(shí)現(xiàn)動(dòng)態(tài)性，可以選擇使用數(shù)據(jù)庫，通過定時(shí)輪詢?cè)L問數(shù)據(jù)庫來感知配置的變化。輪詢頻率低感知配置變化的延時(shí)就長，輪詢頻率高，感知配置變化的延時(shí)就短，但比較損耗性能，需要在實(shí)時(shí)性和性能之間做折中。配置中心專門針對(duì)這個(gè)業(yè)務(wù)場(chǎng)景，兼顧實(shí)時(shí)性和一致性來管理動(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ì)帶來核彈的效果，對(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)排查問題或者進(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)定性），配置中心可以通過邏輯隔離的方式支持多環(huán)境。
• 多集群：當(dāng)對(duì)穩(wěn)定性要求比較高，不允許各個(gè)環(huán)境相互影響的時(shí)候，需要將多個(gè)環(huán)境通過多集群的方式進(jìn)行物理隔離。

常用配置中心

寫在前面

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

但是我們選擇配置中心時(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ì)問，那你們公司為啥用ETCD作為配置中心呢？因?yàn)槲覀冏约簩懥藗€(gè)后臺(tái)，支持權(quán)限、灰度發(fā)布、版本控制等功能。

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

Apollo

GitHub：https://github.com/apolloconfig/apollo

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

Apollo框架

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

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

• ConfigService：提供配置獲取接口，提供配置推送接口，服務(wù)于Apollo客戶端。
• AdminService：提供配置管理接口，提供配置修改發(fā)布接口，服務(wù)于管理界面Portal。
• Client：為應(yīng)用獲取配置，支持實(shí)時(shí)更新，通過MetaServer獲取ConfigService的服務(wù)列表，使用客戶端軟負(fù)載SLB方式調(diào)用ConfigService。
• Portal：配置管理界面，通過MetaServer獲取AdminService的服務(wù)列表，使用客戶端軟負(fù)載SLB方式調(diào)用AdminService。

調(diào)用流程：

1. ConfigService是一個(gè)獨(dú)立的微服務(wù)，服務(wù)于Client進(jìn)行配置獲取。
2. Client和ConfigService保持長連接，通過一種拖拉結(jié)合(push & pull)的模式，實(shí)現(xiàn)配置實(shí)時(shí)更新的同時(shí)，保證配置更新不丟失。
3. AdminService是一個(gè)獨(dú)立的微服務(wù)，服務(wù)于Portal進(jìn)行配置管理。Portal通過調(diào)用AdminService進(jìn)行配置管理和發(fā)布。
4. ConfigService和AdminService共享ConfigDB，ConfigDB中存放項(xiàng)目在某個(gè)環(huán)境的配置信息。ConfigService/AdminService/ConfigDB三者在每個(gè)環(huán)境(DEV/FAT/UAT/PRO)中都要部署一份。
5. 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接口的形式暴露出來；
• 由于Meta Server是集群部署，需要搞個(gè)NginxLB去找Meta Server機(jī)器。

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

Apollo特性

• 統(tǒng)一管理不同環(huán)境、不同集群的配置：
• Apollo提供了一個(gè)統(tǒng)一界面集中式管理不同環(huán)境（environment）、不同集群（cluster）、不同命名空間（namespace）的配置。
• 同一份代碼部署在不同的集群，可以有不同的配置，比如zk的地址等。
• 通過命名空間（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ì)日志，可以方便地追蹤問題。
• 客戶端配置信息監(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ì)做過多限制，只要符合基本的格式就能夠保存。
• 對(duì)于有些使用方，它們的配置可能會(huì)有比較復(fù)雜的格式，而且對(duì)輸入的值也需要進(jìn)行校驗(yàn)后方可保存，如檢查數(shù)據(jù)庫、用戶名和密碼是否匹配。對(duì)于這類應(yīng)用，Apollo支持應(yīng)用方通過開放接口在Apollo進(jìn)行配置的修改和發(fā)布，并且具備完善的授權(quán)和權(quán)限控制。

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

Disconf

GitHub：https://github.com/knightliao/disconf

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

Disconf框架

Disconf是一套完整的基于zookeeper的分布式配置統(tǒng)一解決方案，它通過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ì)越來越多，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共享工具來共享主備的Context。
• 注解式編程，極簡的使用方式：我們追求的是極簡的、用戶編程體驗(yàn)良好的編程方式。通過簡單的標(biāo)注 極簡單的代碼撰寫，即可完成復(fù)雜的配置分布式化。
• 需要Spring編程環(huán)境。
• 可以托管任何類型的配置文件。
• 提供界面良好Web管理功能，可以非常方便的查看配置被哪些實(shí)例使用了。

Spring Cloud Config

GitHub：https://github.com/spring-cloud/spring-cloud-config

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

Spring Cloud Config 工作原理

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

工作流程：

• 在部署環(huán)境之前，需要將相應(yīng)的配置信息推送到配置倉庫；
• 配置服務(wù)器啟動(dòng)之后，將配置信息拉取并同步至本地倉庫；
• 配置服務(wù)器對(duì)外提供REST接口，其他所有的配置客戶端啟動(dòng)時(shí)根據(jù)spring.cloud.config配置的{application}/{profile}/{label}信息去配置服務(wù)器拉取相應(yīng)的配置。配置倉庫支持多樣的源，如Git、SVN、jdbc數(shù)據(jù)庫和本地文件系統(tǒng)等。
• 其他應(yīng)用啟動(dòng)，從配置服務(wù)器拉取配置。（配置中心還支持動(dòng)態(tài)刷新配置信息，不需要重啟應(yīng)用，通過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)境，可以無縫與Spring應(yīng)用集成；
• 可用于任何語言開發(fā)的程序，為其管理與提供配置信息；
• 默認(rèn)實(shí)現(xiàn)基于git倉庫，可以進(jìn)行版本管理。

Nacos

Nacos官網(wǎng)：https://nacos.io/zh-cn/docs/what-is-nacos.html

Nacos 致力于幫助您發(fā)現(xiàn)、配置和管理微服務(wù)。Nacos 提供了一組簡單易用的特性集，幫助您快速實(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)無狀態(tài)服務(wù)變得更簡單，讓服務(wù)按需彈性擴(kuò)展變得更容易。
• Nacos 提供了一個(gè)簡潔易用的UI (控制臺(tái)樣例 Demo) 幫助您管理所有的服務(wù)和應(yīng)用的配置。Nacos 還提供包括配置版本跟蹤、金絲雀發(fā)布、一鍵回滾配置以及客戶端配置更新狀態(tài)跟蹤在內(nèi)的一系列開箱即用的配置管理特性，幫助您更安全地在生產(chǎn)環(huán)境中管理配置變更和降低配置變更帶來的風(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)的簡單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 提供了一些簡單的 DNS APIs TODO 幫助您管理服務(wù)的關(guān)聯(lián)域名和可用的 IP:PORT 列表。

小節(jié)一下：

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

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

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

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

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

配置中心對(duì)比

• 灰度發(fā)布：
• Spring Cloud Config支持通過/bus/refresh端點(diǎn)的destination參數(shù)來指定要更新配置的機(jī)器，不過整個(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通過項(xiàng)目的維度來對(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通過Git來做版本管理，更方便些。
• 配置格式校驗(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可以通過灰度實(shí)例列表查看監(jiān)聽配置的實(shí)例列表，但實(shí)例監(jiān)聽的配置(Apollo稱為命名空間)目前還沒有展示出來。
• Nacos可以查看監(jiān)聽配置的實(shí)例，也可以查看實(shí)例監(jiān)聽的配置情況。
• 基本上，這三個(gè)產(chǎn)品都具備監(jiān)聽查詢能力，在我們自己的使用過程中，Nacos使用起來相對(duì)簡單，易用性相對(duì)更好些。
• 多環(huán)境：
• Spring Cloud Config支持Profile的方式隔離多個(gè)環(huán)境，通過在Git上配置多個(gè)Profile的配置文件，客戶端啟動(dòng)時(shí)指定Profile就可以訪問對(duì)應(yīng)的配置文件。
• Apollo也支持多環(huán)境，在控制臺(tái)創(chuàng)建配置的時(shí)候就要指定配置所在的環(huán)境，客戶端在啟動(dòng)的時(shí)候指定JVM參數(shù)ENV來訪問對(duì)應(yīng)環(huán)境的配置文件。
• Nacos通過命名空間來支持多環(huán)境，每個(gè)命名空間的配置相互隔離，客戶端指定想要訪問的命名空間就可以達(dá)到邏輯隔離的作用。
• 多集群：
• Spring Cloud Config可以通過搭建多套Config Server，Git使用同一個(gè)Git的多個(gè)倉庫，來實(shí)現(xiàn)物理隔離。
• Apollo可以搭建多套集群，Apollo的控制臺(tái)和數(shù)據(jù)更新推送服務(wù)分開部署，控制臺(tái)部署一套就可以管控多個(gè)集群。
• Nacos控制臺(tái)和后端配置服務(wù)是部署在一起的，可以通過不同的域名切換來支持多集群。
• 配置實(shí)時(shí)推送：
• Nacos和Apollo配置推送都是基于HTTP長輪詢，客戶端和配置中心建立HTTP長聯(lián)接，當(dāng)配置變更的的時(shí)候，配置中心把配置推送到客戶端。
• Spring Cloud Config原生不支持配置的實(shí)時(shí)推送，需要依賴Git的WebHook、Spring Cloud Bus和客戶端/bus/refresh端點(diǎn)。
• Nacos和Apollo在配置實(shí)時(shí)推送鏈路上是比較簡單高效的，Spring Cloud Config的配置推送引入Spring Cloud Bus，鏈路較長，比較復(fù)雜。
• 多語言支持：
• 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)支持了多種語言，并且提供了open API。其他不支持的語言，Apollo的接入成本相對(duì)較低。
• Nacos支持主流的語言，例如Java、Go、Python、Nodejs、PHP等，也提供了open API。
• 性能對(duì)比：
• Nacos的讀寫性能最高，Apollo次之，Spring Cloud Config的依賴Git場(chǎng)景不適合開放的大規(guī)模自動(dòng)化運(yùn)維API。

配置中心選型

總的來說：

• Apollo和Nacos相對(duì)于Spring Cloud Config的生態(tài)支持更廣，在配置管理流程上做的更好。
• Apollo相對(duì)于Nacos在配置管理做的更加全面，不過使用起來也要麻煩一些。
• Apollo容器化較困難，Nacos有官網(wǎng)的鏡像可以直接部署，總體來說，Nacos比Apollo更符合KISS原則。
• Nacos使用起來相對(duì)比較簡潔，在對(duì)性能要求比較高的大規(guī)模場(chǎng)景更適合。

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

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

盡信書則不如無書，因個(gè)人能力有限，難免有疏漏和錯(cuò)誤之處，如發(fā)現(xiàn)bug或者有更好的建議，歡迎批評(píng)指正，不吝感激。