為什么需要配置中心
配置實時生效:
傳統(tǒng)的靜態(tài)配置方式要想修改某個配置只能修改之后重新發(fā)布應用梅鹦,要實現(xiàn)動態(tài)性,可以選擇使用數(shù)據(jù)庫评腺,通過定時輪詢訪問數(shù)據(jù)庫來感知配置的變化帘瞭。輪詢頻率低感知配置變化的延時就長,輪詢頻率高蒿讥,感知配置變化的延時就短蝶念,但比較損耗性能,需要在實時性和性能之間做折中芋绸。配置中心專門針對這個業(yè)務場景媒殉,兼顧實時性和一致性來管理動態(tài)配置。
配置管理流程:
配置的權(quán)限管控摔敛、灰度發(fā)布廷蓉、版本管理、格式檢驗和安全配置等一系列的配置管理相關(guān)的特性也是配置中心不可獲取的一部分马昙。
開源配置中心基本介紹
目前市面上用的比較多的配置中心有:(按開源時間排序)
Disconf
2014年7月百度開源的配置管理中心桃犬,同樣具備配置的管理能力刹悴,不過目前已經(jīng)不維護了,最近的一次提交是兩年前了攒暇。
Spring Cloud Config
2014年9月開源土匀,Spring Cloud 生態(tài)組件,可以和Spring Cloud體系無縫整合形用。
Apollo
2016年5月就轧,攜程開源的配置管理中心,具備規(guī)范的權(quán)限田度、流程治理等特性妒御。
Nacos
2018年6月,阿里開源的配置中心镇饺,也可以做DNS和RPC的服務發(fā)現(xiàn)乎莉。
配置中心核心概念的對比
由于Disconf不再維護,下面對比一下Spring Cloud Config兰怠、Apollo和Nacos梦鉴。
Spring Cloud Config、Apollo和Nacos在配置管理領(lǐng)域的概念基本相同揭保,但是也存在一些不同的點,使用配置的過程中會涉及到一些比較重要的概念魄宏。
應用
應用是客戶端系統(tǒng)的基本單位秸侣,Spring Cloud Config 將應用名稱和對應Git中的文件名稱關(guān)聯(lián)起來了,這樣可以起到多個應用配置相互隔離的作用宠互。Apollo的配置都是在某個應用下面的(除了公共配置)味榛,也起到了多個應用配置相互隔離的作用。Nacos的應用概念比較弱予跌,只有一個用于區(qū)分配置的額外屬性搏色,不過可以使用 Group 來做應用字段,可以起到隔離作用券册。
集群
不同的環(huán)境可以搭建不同的集群频轿,這樣可以起到物理隔離的作用,Spring Cloud Config烁焙、Apollo航邢、Nacos都支持多個集群。
Label Profile & 環(huán)境 & 命名空間
Spring Cloud Config可以使用Label和Profile來做邏輯隔離骄蝇,Label指遠程倉庫的分支膳殷,Profile類似Maven Profile可以區(qū)分環(huán)境,比如{application}-{profile}.properties九火。
Nacos的命名空間和Apollo的環(huán)境一樣赚窃,是一個邏輯概念册招,可以作為環(huán)境邏輯隔離。Apollo中的命名空間指配置的名稱勒极,具體的配置項指配置文件中的一個Property跨细。
配置管理功能的對比
作為配置中心,配置的整個管理流程應該具備流程化能力河质。
灰度發(fā)布
配置的灰度發(fā)布是配置中心比較重要的功能冀惭,當配置的變更影響比較大的時候,需要先在部分應用實例中驗證配置的變更是否符合預期掀鹅,然后再推送到所有應用實例散休。
Spring Cloud Config支持通過/bus/refresh端點的destination參數(shù)來指定要更新配置的機器,不過整個流程不夠自動化和體系化乐尊。
Apollo可以直接在控制臺上點灰度發(fā)布指定發(fā)布機器的IP戚丸,接著再全量發(fā)布,做得比較體系化扔嵌。
Nacos目前發(fā)布到0.9版本限府,還不支持灰度發(fā)布。
權(quán)限管理
配置的變更和代碼變更都是對應用運行邏輯的改變痢缎,重要的配置變更常常會帶來核彈的效果胁勺,對于配置變更的權(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)限管理能力麻养。
版本管理&回滾
當配置變更不符合預期的時候褐啡,需要根據(jù)配置的發(fā)布版本進行回滾。Spring Cloud Config鳖昌、Apollo和Nacos都具備配置的版本管理和回滾能力备畦,可以在控制臺上查看配置的變更情況或進行回滾操作。Spring Cloud Config通過Git來做版本管理遗遵,更方便些萍恕。
配置格式校驗
應用的配置數(shù)據(jù)存儲在配置中心一般都會以一種配置格式存儲,比如Properties车要、Json允粤、Yaml等,如果配置格式錯誤,會導致客戶端解析配置失敗引起生產(chǎn)故障类垫,配置中心對配置的格式校驗能夠有效防止人為錯誤操作的發(fā)生司光,是配置中心核心功能中的剛需。
Spring Cloud Config使用Git悉患,目前還不支持格式檢驗残家,格式的正確性依賴研發(fā)人員自己。
Apollo和Nacos都會對配置格式的正確性進行檢驗售躁,可以有效防止人為錯誤坞淮。
監(jiān)聽查詢
當排查問題或者進行統(tǒng)計的時候,需要知道一個配置被哪些應用實例使用到陪捷,以及一個實例使用到了哪些配置回窘。
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)境
在實際生產(chǎn)中症杏,配置中心常常需要涉及多環(huán)境或者多集群,業(yè)務在開發(fā)的時候可以將開發(fā)環(huán)境和生產(chǎn)環(huán)境分開瑞信,或者根據(jù)不同的業(yè)務線存在多個生產(chǎn)環(huán)境厉颤。如果各個環(huán)境之間的相互影響比較小(開發(fā)環(huán)境影響到生產(chǎn)環(huán)境穩(wěn)定性)凡简,配置中心可以通過邏輯隔離的方式支持多環(huán)境逼友。
Spring Cloud Config支持Profile的方式隔離多個環(huán)境,通過在Git上配置多個Profile的配置文件秤涩,客戶端啟動時指定Profile就可以訪問對應的配置文件帜乞。
Apollo也支持多環(huán)境,在控制臺創(chuàng)建配置的時候就要指定配置所在的環(huán)境筐眷,客戶端在啟動的時候指定JVM參數(shù)ENV來訪問對應環(huán)境的配置文件黎烈。
Nacos通過命名空間來支持多環(huán)境,每個命名空間的配置相互隔離,客戶端指定想要訪問的命名空間就可以達到邏輯隔離的作用照棋。
多集群
當對穩(wěn)定性要求比較高资溃,不允許各個環(huán)境相互影響的時候,需要將多個環(huán)境通過多集群的方式進行物理隔離烈炭。
Spring Cloud Config可以通過搭建多套Config Server溶锭,Git使用同一個Git的多個倉庫,來實現(xiàn)物理隔離符隙。
Apollo可以搭建多套集群趴捅,Apollo的控制臺和數(shù)據(jù)更新推送服務分開部署,控制臺部署一套就可以管控多個集群霹疫。
Nacos控制臺和后端配置服務是部署在一起的拱绑,可以通過不同的域名切換來支持多集群。
配置實時推送的對比
當配置變更的時候更米,配置中心需要將配置實時推送到應用客戶端欺栗。
Nacos和Apollo配置推送都是基于HTTP長輪詢,客戶端和配置中心建立HTTP長聯(lián)接征峦,當配置變更的的時候迟几,配置中心把配置推送到客戶端。
Spring Cloud Config原生不支持配置的實時推送栏笆,需要依賴Git的WebHook类腮、Spring Cloud Bus和客戶端/bus/refresh端點:
1、基于Git的WebHook蛉加,配置變更觸發(fā)server端refresh
2蚜枢、Server端接收到請求并發(fā)送給Spring Cloud Bus
3、Spring Cloud Bus接到消息并通知給客戶端
4针饥、客戶端接收到通知厂抽,請求Server端獲取最新配置
整體比較下來,Nacos和Apollo在配置實時推送鏈路上是比較簡單高效的丁眼,Spring Cloud Config的配置推送引入Spring Cloud Bus筷凤,鏈路較長,比較復雜苞七。
部署結(jié)構(gòu) & 高可用的對比
Spring Cloud Config
Spring Cloud Config包含config-server藐守、Git和Spring Cloud Bus三大組件:
1、config-server提供給客戶端獲取配置;
2蹂风、Git用于存儲和修改配置;
3卢厂、Spring Cloud Bus通知客戶端配置變更;
本地測試模式下,Spring Cloud Bus和config-server需要部署一個節(jié)點惠啄,Git使用GitHub就可以慎恒。在生產(chǎn)環(huán)境中任内,Spring Cloud Config,config-server需要部署至少兩個節(jié)點巧号。Spring Cloud Bus如果使用RabbitMQ族奢,普通集群模式至少需要兩個節(jié)點。
Git服務如果使用GitHub就不用考慮高可用問題丹鸿,如果考慮到安全性要自建Git私有倉庫越走,整體的成本比較高。Web服務可以部署多節(jié)點支持高可用靠欢,由于Git有數(shù)據(jù)的一致性問題廊敌,可以通過以下的方式來支持高可用:
1、Git+Keepalived冷備模式门怪,當主Git掛了可以馬上切到備Git;
2骡澈、Git多節(jié)點部署,存儲使用網(wǎng)絡文件系統(tǒng)或者通過DRBD實現(xiàn)多個Git節(jié)點的數(shù)據(jù)同步;
Apollo
Apollo分為MySQL掷空,Config Service肋殴,Admin Service衣式,Portal四個模塊:
1荠耽、MySQL存儲Apollo元數(shù)據(jù)和用戶配置數(shù)據(jù);
2鹰贵、Config Service提供配置的讀取够滑、推送等功能,客戶端請求都是落到Config Service上;
3侦另、Admin Service提供配置的修改器躏、發(fā)布等功能昆烁,Portal操作的服務就是Admin Service;
4赤炒、Portal提供給用戶配置管理界面;
本地測試Config Service氯析,Admin Service,Portal三個模塊可以合并一起部署莺褒,MySQL單獨安裝并創(chuàng)建需要的表結(jié)構(gòu)掩缓。在生產(chǎn)環(huán)境使用Apollo,Portal可以兩個節(jié)點單獨部署遵岩,穩(wěn)定性要求沒那么高的話拾因,Config Service和Admin Service可以部署在一起,數(shù)據(jù)庫支持主備容災旷余。
Nacos
Nacos部署需要Nacos Service和MySQL:
1、Nacos對外提供服務扁达,支持配置管理和服務發(fā)現(xiàn);
2正卧、MySQL提供Nacos的數(shù)據(jù)持久化存儲;
單機模式下,Nacos可以使用嵌入式數(shù)據(jù)庫部署一個節(jié)點跪解,就能啟動炉旷。如果對MySQL比較熟悉,想要了解整體數(shù)據(jù)流向,可以安裝MySQL提供給Nacos數(shù)據(jù)持久化服務窘行。生產(chǎn)環(huán)境使用Nacos饥追,Nacos服務需要至少部署三個節(jié)點,再加上MySQL主備罐盔。
整體來看
Nacos的部署結(jié)構(gòu)比較簡單但绕,運維成本較低。Apollo部署組件較多惶看,運維成本比Nacos高捏顺。Spring Cloud Config生產(chǎn)高可用的成本最高。
多語言支持的對比
一個公司的各個系統(tǒng)可能語言不盡相同纬黎,現(xiàn)在使用的比較多的比如C++幅骄,Java,PHP本今,Python拆座,Nodejs,還有Go等冠息。引入配置中心之后挪凑,配置中心要想讓多語言的系統(tǒng)都能享受到動態(tài)配置的能力,需要支持多語言生態(tài)铐达。
多語言支持
Spring Cloud服務于Java生態(tài)岖赋,一開始只是針對Java微服務應用,對于非Java應用的微服務調(diào)用瓮孙,可以使用Sidecar提供了HTTP API唐断,但動態(tài)配置方面還不能很好的支持。
Apollo已經(jīng)支持了多種語言杭抠,并且提供了open API脸甘。其他不支持的語言,Apollo的接入成本相對較低偏灿。
Nacos支持主流的語言丹诀,例如Java、Go翁垂、Python铆遭、Nodejs、PHP等沿猜,也提供了open API枚荣。
遷移支持
國內(nèi)主流的互聯(lián)網(wǎng)公司仍是以Java為主,除了原生Java SDK啼肩,在對整個Java生態(tài)橄妆,比如Spring Boot和Spring Cloud的支持上衙伶,三個產(chǎn)品都是支持的。
Spring Cloud Config原生就支持Spring Boot和Spring Cloud害碾,Nacos通過Spring Cloud for Alibaba支持Spring Boot和Spring Cloud生態(tài)矢劲,符合Spring生態(tài)中的標準實現(xiàn)方式,可以無縫從Spring Cloud Conig遷移到Nacos慌随。
Apollo支持Spring Boot和Spring Cloud項目芬沉,但是實現(xiàn)方式不同于標準,無法做無縫遷移儒陨,從Spring Cloud遷移到Apollo花嘶,存在代碼改造和兼容性成本。
性能對比
性能也是配置中心繞不過的一環(huán)蹦漠,在同樣的機器規(guī)格下椭员,如果能支撐更大的業(yè)務量,勢必能替公司節(jié)省更多的資源成本笛园,提高資源利用率隘击。應用客戶端對配置中心的接口操作有讀、寫和變更通知研铆,由于變更通知需要大量的客戶端實例,不好模擬測試場景棵红,下面僅對讀和寫操作做了測試凶赁。
硬件環(huán)境
Nacos和Apollo使用同樣的數(shù)據(jù)庫(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分為讀內(nèi)存緩存和從數(shù)據(jù)庫中讀兩種方式御毅,從數(shù)據(jù)庫中讀能達到7500根欧,從內(nèi)存讀緩存性能可以達到9000QPS。Spring Cloud Config使用jGit讀寫Git端蛆,由于有客戶端限制咽块,單機讀能力被限制在7QPS。
3節(jié)點讀場景
將配置中心的壓測節(jié)點數(shù)都部署成3個節(jié)點欺税。Nacos QPS可以達到45000 QPS侈沪,Apollo讀內(nèi)存緩存可以達到27000 QPS。Nacos和Apollo由于讀場景各個節(jié)點是獨立的晚凿,基本就是單機讀場景的3倍關(guān)系亭罪。Spring Cloud Config三個節(jié)點讀能力可以到達21QPS。
單機寫場景
同樣的方式歼秽,多臺機器同時在配置中心修改不同的配置应役。Nacos QPS可以達到1800,Apollo未使用默認的數(shù)據(jù)庫連接池(10)QPS只能達到800 QPS(CPU未壓滿)燥筷,調(diào)整連接池至100可以達到1100 QPS(CPU壓滿)箩祥。Git在提交同一個項目的時候會加鎖,單機Git寫能在5QPS左右肆氓,Spring Cloud Config在使用的時候以一個項目作為數(shù)據(jù)源袍祖,寫能力受到Git限制。
3節(jié)點寫場景
同樣的方式谢揪,將配置中心的壓測節(jié)點數(shù)都部署成3個節(jié)點蕉陋。Nacos QPS可以達到6000,Apollo可以達到3300 QPS(CPU壓滿)拨扶,此時MySQL數(shù)據(jù)庫因為配置較高凳鬓,未成為性能瓶頸。Spring Cloud Config三個節(jié)點時候患民,Git也是一個節(jié)點缩举,寫QPS為5。
整體上來看匹颤,Nacos的讀寫性能最高仅孩,Apollo次之,Spring Cloud Config的依賴Git場景不適合開放的大規(guī)模自動化運維API惋嚎。
功能特性對比總結(jié)
這里列一個表格總結(jié)一下三個產(chǎn)品的功能特點杠氢。
對比項目/配置中心 | spring cloud config | apollo | nacos |
---|---|---|---|
開源時間 | 2014.9 | 2016.5 | 2018.6 |
配置實時推送 | 支持(Spring Cloud Bus) | 支持(HTTP長輪詢1s內(nèi)) | 支持(HTTP長輪詢1s內(nèi)) |
版本管理 | 支持(Git) | 自動管理 | 自動管理 |
配置回滾 | 支持(Git) | 支持 | 支持 |
灰度發(fā)布 | 支持 | 支持 | 待支持 |
權(quán)限管理 | 支持 | 支持 | 待支持 |
多集群多環(huán)境 | 支持 | 支持 | 支持 |
監(jiān)聽查詢 | 支持 | 支持 | 支持 |
多語言 | 只支持Java | Go,C++,Python,Java,.net,OpenAPI | Python,Java,Nodejs,OpenAPI |
分布式高可用最小集群數(shù)量 | Config-Server2+Git+MQ | Config2+Admin3+Portal*2+Mysql=8 | Nacos*3+MySql=4 |
配置格式校驗 | 不支持 | 支持 | 支持 |
通信協(xié)議 | HTTP和AMQP | HTTP | HTTP |
數(shù)據(jù)一致性 | Git保證數(shù)據(jù)一致性,Config-Server從Git讀取數(shù)據(jù) | 數(shù)據(jù)庫模擬消息隊列另伍,Apollo定時讀消息 | HTTP異步通知 |
單機讀(tps) | 7(限流所制) | 9000 | 15000 |
單機寫(tps) | 5(限流所制) | 1100 | 1800 |
3節(jié)點讀 | 21(限流所制) | 27000 | 45000 |
3節(jié)點寫 | 5(限流所制) | 3300 | 5600 |
總的來說
1鼻百、Apollo和Nacos相對于Spring Cloud Config的生態(tài)支持更廣,在配置管理流程上做的更好摆尝。
2温艇、Apollo相對于Nacos在配置管理做的更加全面,不過使用起來也要麻煩一些堕汞。
3勺爱、apollo容器化較困難,Nacos有官網(wǎng)的鏡像可以直接部署讯检,總體來說琐鲁,Nacos比apollo更符合KISS原則卫旱。
4、Nacos部署和使用起來相對比較簡潔围段,在對性能要求比較高的大規(guī)模場景更適合顾翼。
此外,Nacos除了提供配置中心的功能奈泪,還提供了動態(tài)服務發(fā)現(xiàn)适贸、服務共享與管理的功能,降低了服務化改造過程中的難度涝桅。
以上拜姿,我們從產(chǎn)品功能、使用體驗冯遂、實施過程和性能 4 個緯度對Spring Cloud Config蕊肥、Apollo和Nacos進行對比。但對于一個開源項目的選型债蜜,除了以上這4個方面晴埂,項目上的人力投入(迭代進度、文檔的完整性)寻定、社區(qū)的活躍度(issue的數(shù)量和解決速度儒洛、Contributor數(shù)量、社群的交流頻次等)狼速、社區(qū)的規(guī)范程度(免責說明琅锻、安全性說明等),這些可能才是用戶更關(guān)注的內(nèi)容向胡。
參考文檔
https://springcloud.cc/spring-cloud-config.html
https://github.com/ctripcorp/apollo
https://nacos.io/