因?yàn)楣具M(jìn)行系統(tǒng)的服務(wù)化拆分，導(dǎo)致模塊驟增，隨之而來(lái)配置文件管理難度也隨之增加，所以想采用一個(gè)配置集中管理的中間件。

下面對(duì)市面比較流行的Naocs和Apollo從各方面進(jìn)行比較。

1. 配置中心

1.1 什么是配置

應(yīng)用程序在啟動(dòng)和運(yùn)行的時(shí)候往往需要讀取一些配置信息，配置基本上伴隨著應(yīng)用程序的整個(gè)生命周期，比如：數(shù) 據(jù)庫(kù)連接參數(shù)、啟動(dòng)參數(shù)等。

配置主要有以下幾個(gè)特點(diǎn)：

• 配置是獨(dú)立于程序的只讀變量

配置對(duì)于程序是只讀的，程序通過(guò)讀取配置來(lái)改變自己的行為，但是程序不應(yīng)該去改變配置

• 配置伴隨應(yīng)用的整個(gè)生命周期

配置貫穿于應(yīng)用的整個(gè)生命周期，應(yīng)用在啟動(dòng)時(shí)通過(guò)讀取配置來(lái)初始化，在運(yùn)行時(shí)根據(jù)配置調(diào)整行為。

比如：?jiǎn)?dòng)時(shí)需要讀取服務(wù)的端口號(hào)、系統(tǒng)在運(yùn)行過(guò)程中需要讀取定時(shí)策略執(zhí)行定時(shí)任務(wù)等。

• 配置可以有多種加載方式

常見(jiàn)的有程序內(nèi)部hard code，配置文件，環(huán)境變量，啟動(dòng)參數(shù)，基于數(shù)據(jù)庫(kù)等

• 配置需要治理

同一份程序在不同的環(huán)境(開(kāi)發(fā)，測(cè)試，生產(chǎn))、不同的集群(如不同的數(shù)據(jù)中心)經(jīng)常需要有不同的配置，所以需要有完善的環(huán)境、集群配置管理

1.2 什么是配置中心

在分布式服務(wù)架構(gòu)中，當(dāng)系統(tǒng)從一個(gè)單體應(yīng)用，被拆分成分布式系統(tǒng)上一個(gè)個(gè)服務(wù)節(jié)點(diǎn)后，配置文件也必須跟著遷移 (分割)，這樣配置就分散了，不僅如此，分散中還包含著冗余，如下圖

而配置中心將配置從各應(yīng)用中剝離出來(lái)，對(duì)配置進(jìn)行統(tǒng)一管理，應(yīng)用自身不需要自己去管理配置。如下圖

配置中心的服務(wù)流程如下：

1、用戶(hù)在配置中心發(fā)布、更新配置信息。

2、服務(wù)A和服務(wù)B及時(shí)得到配置更新通知，從配置中心獲取配置。

總得來(lái)說(shuō)，配置中心就是一種統(tǒng)一管理各種應(yīng)用配置的基礎(chǔ)服務(wù)組件。

1.3 為什么需要配置中心

隨分布式微服務(wù)的發(fā)展，服務(wù)節(jié)點(diǎn)越來(lái)越多，配置問(wèn)題逐漸顯現(xiàn)出來(lái)：

• 隨著程序功能的日益復(fù)雜，程序的配置日益增多，各種功能的開(kāi)關(guān)、參數(shù)的配置、服務(wù)器的地址
• 大量模塊使用各自的配置，可能導(dǎo)致運(yùn)維繁瑣、管理混亂、各個(gè)節(jié)點(diǎn)配置文件不一致
• 對(duì)配置的期望也越來(lái)越高，配置修改后實(shí)時(shí)生效，灰度發(fā)布， 版本管理 ，環(huán)境區(qū)分，完善的權(quán)限、審核機(jī)制等

在這樣的大環(huán)境下，傳統(tǒng)的通過(guò)配置文件、數(shù)據(jù)庫(kù)等方式已經(jīng)越來(lái)越無(wú)法滿足開(kāi)發(fā)人員對(duì)配置管理的需求。

1.4 配置中心小結(jié)

總結(jié)一下，在傳統(tǒng)巨型單體應(yīng)用紛紛轉(zhuǎn)向分布式服務(wù)架構(gòu)的歷史進(jìn)程中，配置中心是服務(wù)化不可缺少的一個(gè)系統(tǒng)組件，在這種背景下中心化的配置服務(wù)即配置中心應(yīng)運(yùn)而生，一個(gè)合格的配置中心需要滿足如下特性：

• 配置項(xiàng)容易讀取和修改
• 分布式環(huán)境下應(yīng)用配置的可管理性，即提供遠(yuǎn)程管理配置的能力
• 支持對(duì)配置的修改的檢視以把控風(fēng)險(xiǎn)
• 可以查看配置修改的歷史記錄
• 不同部署環(huán)境下應(yīng)用配置的隔離性

整個(gè)配置中心的作用系統(tǒng)運(yùn)行時(shí)能夠動(dòng)態(tài)調(diào)整程序的行為。

2. 開(kāi)源配置中心介紹

目前市面流行的配置中心有：

• Disconf

2014年7月，百度開(kāi)源的配置管理中心，同樣具備配置的管理能力，不過(guò)目前已經(jīng)不維護(hù)了 。

• Spring Cloud Config

2014年9月，Spring Cloud 開(kāi)源生態(tài)組件，可以和Spring Cloud體系無(wú)縫整合，但依賴(lài)Git或SVN 。

• Apollo

2016年5月，攜程開(kāi)源的配置管理中心，具備規(guī)范的權(quán)限、流程治理等特性。

• Nacos

2018年6月，阿里開(kāi)源的配置中心，也可以做RPC的服務(wù)發(fā)現(xiàn)。

因Disconf不再維護(hù)，且Spring Cloud Config 需要依賴(lài)Git或SVN。所以只介紹下Apollo和Nacos

2.1 Nacos

Nacos包含的注冊(cè)中心+配置中心，以下只說(shuō)配置中心。

2.1.1 簡(jiǎn)介

Nacos 致力于幫助服務(wù)發(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文檔中心地址：https://nacos.io/zh-cn/docs/what-is-nacos.html

2.1.2 特性

Nacos 支持幾乎所有主流類(lèi)型的服務(wù)發(fā)現(xiàn)、配置和管理，現(xiàn)只說(shuō)Nacos的配置中心功能。

• 動(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幫助您管理所有的服務(wù)和應(yīng)用的配置。
• Nacos 還提供包括配置版本跟蹤、金絲雀發(fā)布、一鍵回滾配置以及客戶(hù)端配置更新?tīng)顟B(tài)跟蹤在內(nèi)的一系列開(kāi)箱即用的配置管理特性，幫助您更安全地在生產(chǎn)環(huán)境中管理配置變更和降低配置變更帶來(lái)的風(fēng)險(xiǎn)。

2.1.3 架構(gòu)

Nacos配置中心分為Server與Client，server采用Java編寫(xiě)，為client提供配置服務(wù)。

Client可以用多語(yǔ)言實(shí)現(xiàn)，Client與服務(wù)模塊嵌套在一起，Nacos提供SDK和OpenAPI，如果沒(méi)有SDK也可以根據(jù)OpenAPI手動(dòng)寫(xiě)服務(wù)注冊(cè)與發(fā)現(xiàn)和配置拉取的邏輯 。

配置中心架構(gòu)圖：

• 用戶(hù)通過(guò)Nacos Server的控制臺(tái)集中對(duì)多個(gè)服務(wù)的配置進(jìn)行管理。
• 各服務(wù)統(tǒng)一從Nacos Server集群中獲取各自的配置，并監(jiān)聽(tīng)配置的變化。

2.1.4 開(kāi)發(fā)

Nacos配置中心支持與Spring、Spring Boot、Spring Cloud整合，通過(guò)xml或注解方式即可輕松實(shí)現(xiàn)。演示下與Spring項(xiàng)目進(jìn)行整合。

1.服務(wù)端

控制臺(tái)發(fā)布配置截圖

• Nacos服務(wù)端增加useLocalCacheSwitch配置，用于控制是否使用緩存
• 發(fā)布配置

2.客戶(hù)端

1. <dependency> 
2.      <groupId>com.alibaba.nacos</groupId> 
3.      <artifactId>nacos-client</artifactId> 
4.      <version>1.4.1</version> 
5.  </dependency> 
6.  <dependency> 
7.      <groupId>com.alibaba.nacos</groupId> 
8.      <artifactId>nacos-spring-context</artifactId> 
9.      <version>1.0.0</version> 
10.  </dependency> 

1. <!--NacosServer地址--> 
2. <nacos:global-properties server-addr="192.168.134.128:8848" /> 
3. <!--在NacosServer配置的文件--> 
4. <nacos:property-source data-id="application.properties"  
5.                        group-id="redirectpaymentservice"  
6.                        auto-refreshed="true"/> 

1. @Service("Tx2101") 
2. public class Tx2101 extends TxBase { 
3.  
4.     @NacosValue(value = "${useLocalCacheSwitch}", autoRefreshed = true) 
5.     private boolean useLocalCacheSwitch; 
6.  
7.     @Override 
8.     public Document process(Document document) throws CodeException { 
9.         System.out.println("是否刷新緩存：" + useLocalCacheSwitch); 
10.         return null; 
11.     } 
12. } 

• 編寫(xiě)java代碼，動(dòng)態(tài)刷新配置
• applicationContext.xml增加NacosServer的相關(guān)配置
• pom.xml 增加nacos-client的依賴(lài)

3.效果

1. 是否刷新緩存：false 

1. 是否刷新緩存：true 

• 在Nacos服務(wù)端改變useLocalCacheSwitch的配置后，再次訪問(wèn)2101接口，打印如下：
• 模塊啟動(dòng)后訪問(wèn)2101接口，打印如下：

2.1.5 灰度

Nacos服務(wù)端修改配置后，勾選Beat發(fā)布，指定IP地址，然后選擇發(fā)布Beta。

• 只有指定的IP節(jié)點(diǎn)的配置被更新

2.1.5 部署

在單機(jī)模式下，Nacos沒(méi)有任何依賴(lài)，默認(rèn)使用內(nèi)嵌的數(shù)據(jù)庫(kù)作為存儲(chǔ)引擎，也可換成mysql;在集群模式下，Nacos依賴(lài)Mysql做存儲(chǔ)。

生產(chǎn)環(huán)境使用Nacos為了達(dá)到高可用不能使用單機(jī)模式，需要搭建nacos集群。

下圖是官方推薦的集群方案，通過(guò)域名 + VIP模式的方式來(lái)實(shí)現(xiàn)。客戶(hù)端配置的nacos，當(dāng)Nacos集群遷移時(shí)，客戶(hù)端配置無(wú)需修改。

集群部署架構(gòu)圖：

集群部署架構(gòu)圖

2.1.7 小結(jié)

Nacos使用簡(jiǎn)單、部署方便、性能較高，能夠?qū)崿F(xiàn)基本的配置管理，提供的控制臺(tái)也非常簡(jiǎn)潔。

但權(quán)限方面控制粒度較粗，且沒(méi)有審核機(jī)制。

2.2 Apollo

2.2.1 簡(jiǎn)介

Apollo(阿波羅)是攜程框架部門(mén)研發(fā)的分布式配置中心，能夠集中化管理應(yīng)用的不同環(huán)境、不同集群的配置，配 置修改后能夠?qū)崟r(shí)推送到應(yīng)用端，并且具備規(guī)范的權(quán)限、流程治理等特性，適用于微服務(wù)配置管理場(chǎng)景。

Apollo包括服務(wù)端和客戶(hù)端兩部分：

服務(wù)端基于Spring Boot和Spring Cloud開(kāi)發(fā)，打包后可以直接運(yùn)行，不需要額外安裝Tomcat等應(yīng)用容器。Java客戶(hù)端不依賴(lài)任何框架，能夠運(yùn)行于所有Java運(yùn)行時(shí)環(huán)境，同時(shí)對(duì)Spring/Spring Boot環(huán)境也有較好的支持。

• 文檔：https://github.com/ctripcorp/apollo/wiki。

2.2.2 特性

基于配置的特殊性，所以Apollo從設(shè)計(jì)之初就立志于成為一個(gè)有治理能力的配置發(fā)布平臺(tái)，目前提供了以下的特性：

• 統(tǒng)一管理不同環(huán)境、不同集群的配置
• 配置修改實(shí)時(shí)生效(熱發(fā)布)
• 版本發(fā)布管理
• 灰度發(fā)布
• 權(quán)限管理、發(fā)布審核、操作審計(jì)
• 客戶(hù)端配置信息監(jiān)控
• 提供Java和.Net原生客戶(hù)端
• 提供開(kāi)放平臺(tái)API
• 部署簡(jiǎn)單

2.2.3 架構(gòu)

Apollo架構(gòu)從外部和內(nèi)部進(jìn)行分析

• 地址：https://ctripcorp.github.io/apollo/#/zh/design/apollo-design

基礎(chǔ)模型

如下即是Apollo的基礎(chǔ)模型：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)
2. 用戶(hù)在配置中心對(duì)配置進(jìn)行修改并發(fā)布
3. 配置中心通知Apollo客戶(hù)端有配置更新
4. Apollo客戶(hù)端從配置中心拉取最新的配置、更新本地配置并通知到應(yīng)用

2.2.4 開(kāi)發(fā)

Apollo支持API方式和Spring整合方式 。

API方式靈活，功能完備，配置值實(shí)時(shí)更新(熱發(fā)布)，支持所有Java環(huán)境。

Spring方式接入簡(jiǎn)單，如

• 代碼中直接使用，如：@Value("${someKeyFromApollo:someDefaultValue}")
• 直接托管spring的配置，如在apollo中直接配置spring.datasource.url=jdbc:mysql://localhost:3306/somedb?characterEncoding=utf8
• Placeholder方式：
• Spring boot的@ConfigurationProperties方式

Spring方式也可以結(jié)合API方式使用，如注入Apollo的Config對(duì)象，就可以照常通過(guò)API方式獲取配置了

下面只介紹下Spring整合Apollo方式，做一個(gè)演示：

1.服務(wù)端

• 控制臺(tái)添加useLocalCacheSwitch配置，用于控制是否使用緩存
• 發(fā)布配置

2.客戶(hù)端

1. <dependency>  
2.     <groupId>com.ctrip.framework.apollo</groupId>   
3.     <artifactId>apollo-client</artifactId>   
4.     <version>1.1.0</version>  
5. </dependency> 

1. <apollo:config/> 

1. -Dapp.id=RedirectPaymentService -Denv=DEV -Ddev_meta=http://localhost:8080 

1. @Service("Tx2101") 
2. public class Tx2101 extends TxBase { 
3.  
4.     @Value("${useLocalCacheSwitch:false}") 
5.     private boolean useLocalCacheSwitch; 
6.  
7.     @Override 
8.     public Document process(Document document) throws CodeException { 
9.         System.out.println("是否刷新緩存：" + useLocalCacheSwitch); 
10.         return null; 
11.     } 
12. } 

• 編寫(xiě)java代碼，動(dòng)態(tài)刷新配置
• VM options啟動(dòng)參數(shù)
• applicationContext.xml增加apollo相關(guān)配置
• pom.xml 增加apollo-client的依賴(lài)

3.效果

1. 是否刷新緩存：false 

1. 是否刷新緩存：true 

• 在Apollo控制臺(tái)改變useLocalCacheSwitch的配置后，再次訪問(wèn)2101接口，打印如下：
• 模塊啟動(dòng)后訪問(wèn)2101接口，打印如下：

2.2.5 灰度

Apollo控制臺(tái)創(chuàng)建灰度版本，配置灰度規(guī)則，指定灰度的IP或AppID。

指定的IP節(jié)點(diǎn)或AppID模塊的配置被更新

2.2.6 部署

Apollo高可用架構(gòu)模塊的概覽 :

上圖簡(jiǎn)要描述了Apollo的總體設(shè)計(jì)，我們可以從下往上看：

• Config Service提供配置的讀取、推送等功能，服務(wù)對(duì)象是Apollo客戶(hù)端
• Admin Service提供配置的修改、發(fā)布等功能，服務(wù)對(duì)象是Apollo Portal(管理界面)
• Config Service和Admin Service都是多實(shí)例、無(wú)狀態(tài)部署，所以需要將自己注冊(cè)到Eureka中并保持心跳
• 在Eureka之上我們架了一層Meta Server用于封裝Eureka的服務(wù)發(fā)現(xiàn)接口
• Client通過(guò)域名訪問(wèn)Meta Server獲取Config Service服務(wù)列表(IP+Port)，而后直接通過(guò)IP+Port訪問(wèn)服務(wù)，同時(shí)在Client側(cè)會(huì)做load balance、錯(cuò)誤重試
• Portal通過(guò)域名訪問(wèn)Meta Server獲取Admin Service服務(wù)列表(IP+Port)，而后直接通過(guò)IP+Port訪問(wèn)服務(wù)，同時(shí)在Portal側(cè)會(huì)做load balance、錯(cuò)誤重試
• 為了簡(jiǎn)化部署，我們實(shí)際上會(huì)把Config Service、Eureka和Meta Server三個(gè)邏輯角色部署在同一個(gè)JVM進(jìn)程中

2.2.7 小結(jié)

Apollo在配置管理流程上比較完善，相應(yīng)配置的發(fā)布審核、權(quán)限管理等、配置的繼承等，但Apollo需要使用人員進(jìn)行簡(jiǎn)單學(xué)習(xí)，存在學(xué)習(xí)成本。

Appollo部署較為復(fù)雜需要3個(gè)模塊同時(shí)工作，部署一套生產(chǎn)高可用集群至少需要7個(gè)節(jié)點(diǎn)。

3. 總結(jié)

3.1 功能比較

3.2 結(jié)論

從配置中心角度來(lái)看，性能方面Nacos的讀寫(xiě)性能最高，Apollo次之;功能方面Apollo最為完善，但Nacos具有Apollo大部分配置管理功能。Nacos的一大優(yōu)勢(shì)是整合了注冊(cè)中心、配置中心功能，部署和操作相比 Apollo都要直觀簡(jiǎn)單，因此它簡(jiǎn)化了架構(gòu)復(fù)雜度，并減輕運(yùn)維及部署工作。

總的來(lái)看，Apollo和Nacos生態(tài)支持都很廣泛，在配置管理流程上做的都很好。Apollo相對(duì)于Nacos在配置管理做的更加全面;Nacos則使用起來(lái)相對(duì)比較簡(jiǎn)潔，在對(duì)性能要求比較高的大規(guī)模場(chǎng)景更適合。

對(duì)于公司目前來(lái)說(shuō)，修改配置的次數(shù)不是特別的頻繁，對(duì)于配置權(quán)限的管理不是特別嚴(yán)格的，且對(duì)讀寫(xiě)性能有一定要求的，可采用Nacos，反之使用Apollo。

原文鏈接：https://mp.weixin.qq.com/s/oZxjQq5vAXJL8gZkzToCFA