因為公司進行系統的服務化拆分，導致模塊驟增，隨之而來配置文件管理難度也隨之增加，所以想采用一個配置集中管理的中間件。

下面對市面比較流行的Naocs和Apollo從各方面進行比較。

1. 配置中心

1.1 什么是配置

應用程序在啟動和運行的時候往往需要讀取一些配置信息，配置基本上伴隨著應用程序的整個生命周期，比如：數 據庫連接參數、啟動參數等。

配置主要有以下幾個特點：

• 配置是獨立于程序的只讀變量

配置對于程序是只讀的，程序通過讀取配置來改變自己的行為，但是程序不應該去改變配置

• 配置伴隨應用的整個生命周期

配置貫穿于應用的整個生命周期，應用在啟動時通過讀取配置來初始化，在運行時根據配置調整行為。

比如：啟動時需要讀取服務的端口號、系統在運行過程中需要讀取定時策略執行定時任務等。

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

常見的有程序內部hard code，配置文件，環境變量，啟動參數，基于數據庫等

• 配置需要治理

同一份程序在不同的環境(開發，測試，生產)、不同的集群(如不同的數據中心)經常需要有不同的配置，所以需要有完善的環境、集群配置管理

1.2 什么是配置中心

在分布式服務架構中，當系統從一個單體應用，被拆分成分布式系統上一個個服務節點后，配置文件也必須跟著遷移 (分割)，這樣配置就分散了，不僅如此，分散中還包含著冗余，如下圖

而配置中心將配置從各應用中剝離出來，對配置進行統一管理，應用自身不需要自己去管理配置。如下圖

配置中心的服務流程如下：

1、用戶在配置中心發布、更新配置信息。

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

總得來說，配置中心就是一種統一管理各種應用配置的基礎服務組件。

1.3 為什么需要配置中心

隨分布式微服務的發展，服務節點越來越多，配置問題逐漸顯現出來：

• 隨著程序功能的日益復雜，程序的配置日益增多，各種功能的開關、參數的配置、服務器的地址
• 大量模塊使用各自的配置，可能導致運維繁瑣、管理混亂、各個節點配置文件不一致
• 對配置的期望也越來越高，配置修改后實時生效，灰度發布， 版本管理 ，環境區分，完善的權限、審核機制等

在這樣的大環境下，傳統的通過配置文件、數據庫等方式已經越來越無法滿足開發人員對配置管理的需求。

1.4 配置中心小結

總結一下，在傳統巨型單體應用紛紛轉向分布式服務架構的歷史進程中，配置中心是服務化不可缺少的一個系統組件，在這種背景下中心化的配置服務即配置中心應運而生，一個合格的配置中心需要滿足如下特性：

• 配置項容易讀取和修改
• 分布式環境下應用配置的可管理性，即提供遠程管理配置的能力
• 支持對配置的修改的檢視以把控風險
• 可以查看配置修改的歷史記錄
• 不同部署環境下應用配置的隔離性

整個配置中心的作用系統運行時能夠動態調整程序的行為。

2. 開源配置中心介紹

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

• Disconf

2014年7月，百度開源的配置管理中心，同樣具備配置的管理能力，不過目前已經不維護了 。

• Spring Cloud Config

2014年9月，Spring Cloud 開源生態組件，可以和Spring Cloud體系無縫整合，但依賴Git或SVN 。

• Apollo

2016年5月，攜程開源的配置管理中心，具備規范的權限、流程治理等特性。

• Nacos

2018年6月，阿里開源的配置中心，也可以做RPC的服務發現。

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

2.1 Nacos

Nacos包含的注冊中心+配置中心，以下只說配置中心。

2.1.1 簡介

Nacos 致力于幫助服務發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集，幫助您快速實現動態服務發現、服務配置、服務元數據及流量管理。

Nacos 更敏捷和容易地構建、交付和管理微服務平臺。Nacos 是構建以“服務”為中心的現代應用架構 (例如微服務范式、云原生范式) 的服務基礎設施。

• Nacos文檔中心地址：https://nacos.io/zh-cn/docs/what-is-nacos.html

2.1.2 特性

Nacos 支持幾乎所有主流類型的服務發現、配置和管理，現只說Nacos的配置中心功能。

• 動態配置服務可以讓您以中心化、外部化和動態化的方式管理所有環境的應用配置和服務配置。
• 動態配置消除了配置變更時重新部署應用和服務的需要，讓配置管理變得更加高效和敏捷。
• 配置中心化管理讓實現無狀態服務變得更簡單，讓服務按需彈性擴展變得更容易。
• Nacos 提供了一個簡潔易用的UI幫助您管理所有的服務和應用的配置。
• Nacos 還提供包括配置版本跟蹤、金絲雀發布、一鍵回滾配置以及客戶端配置更新狀態跟蹤在內的一系列開箱即用的配置管理特性，幫助您更安全地在生產環境中管理配置變更和降低配置變更帶來的風險。

2.1.3 架構

Nacos配置中心分為Server與Client，server采用Java編寫，為client提供配置服務。

Client可以用多語言實現，Client與服務模塊嵌套在一起，Nacos提供SDK和OpenAPI，如果沒有SDK也可以根據OpenAPI手動寫服務注冊與發現和配置拉取的邏輯 。

配置中心架構圖：

• 用戶通過Nacos Server的控制臺集中對多個服務的配置進行管理。
• 各服務統一從Nacos Server集群中獲取各自的配置，并監聽配置的變化。

2.1.4 開發

Nacos配置中心支持與Spring、Spring Boot、Spring Cloud整合，通過xml或注解方式即可輕松實現。演示下與Spring項目進行整合。

1.服務端

控制臺發布配置截圖

• Nacos服務端增加useLocalCacheSwitch配置，用于控制是否使用緩存
• 發布配置

2.客戶端

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. } 

• 編寫java代碼，動態刷新配置
• applicationContext.xml增加NacosServer的相關配置
• pom.xml 增加nacos-client的依賴

3.效果

1. 是否刷新緩存：false 

1. 是否刷新緩存：true 

• 在Nacos服務端改變useLocalCacheSwitch的配置后，再次訪問2101接口，打印如下：
• 模塊啟動后訪問2101接口，打印如下：

2.1.5 灰度

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

• 只有指定的IP節點的配置被更新

2.1.5 部署

在單機模式下，Nacos沒有任何依賴，默認使用內嵌的數據庫作為存儲引擎，也可換成mysql;在集群模式下，Nacos依賴Mysql做存儲。

生產環境使用Nacos為了達到高可用不能使用單機模式，需要搭建nacos集群。

下圖是官方推薦的集群方案，通過域名 + VIP模式的方式來實現。客戶端配置的nacos，當Nacos集群遷移時，客戶端配置無需修改。

集群部署架構圖：

集群部署架構圖

2.1.7 小結

Nacos使用簡單、部署方便、性能較高，能夠實現基本的配置管理，提供的控制臺也非常簡潔。

但權限方面控制粒度較粗，且沒有審核機制。

2.2 Apollo

2.2.1 簡介

Apollo(阿波羅)是攜程框架部門研發的分布式配置中心，能夠集中化管理應用的不同環境、不同集群的配置，配 置修改后能夠實時推送到應用端，并且具備規范的權限、流程治理等特性，適用于微服務配置管理場景。

Apollo包括服務端和客戶端兩部分：

服務端基于Spring Boot和Spring Cloud開發，打包后可以直接運行，不需要額外安裝Tomcat等應用容器。Java客戶端不依賴任何框架，能夠運行于所有Java運行時環境，同時對Spring/Spring Boot環境也有較好的支持。

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

2.2.2 特性

基于配置的特殊性，所以Apollo從設計之初就立志于成為一個有治理能力的配置發布平臺，目前提供了以下的特性：

• 統一管理不同環境、不同集群的配置
• 配置修改實時生效(熱發布)
• 版本發布管理
• 灰度發布
• 權限管理、發布審核、操作審計
• 客戶端配置信息監控
• 提供Java和.Net原生客戶端
• 提供開放平臺API
• 部署簡單

2.2.3 架構

Apollo架構從外部和內部進行分析

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

基礎模型

如下即是Apollo的基礎模型：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區
2. 用戶在配置中心對配置進行修改并發布
3. 配置中心通知Apollo客戶端有配置更新
4. Apollo客戶端從配置中心拉取最新的配置、更新本地配置并通知到應用

2.2.4 開發

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

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

Spring方式接入簡單，如

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

Spring方式也可以結合API方式使用，如注入Apollo的Config對象，就可以照常通過API方式獲取配置了

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

1.服務端

• 控制臺添加useLocalCacheSwitch配置，用于控制是否使用緩存
• 發布配置

2.客戶端

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. } 

• 編寫java代碼，動態刷新配置
• VM options啟動參數
• applicationContext.xml增加apollo相關配置
• pom.xml 增加apollo-client的依賴

3.效果

1. 是否刷新緩存：false 

1. 是否刷新緩存：true 

• 在Apollo控制臺改變useLocalCacheSwitch的配置后，再次訪問2101接口，打印如下：
• 模塊啟動后訪問2101接口，打印如下：

2.2.5 灰度

Apollo控制臺創建灰度版本，配置灰度規則，指定灰度的IP或AppID。

指定的IP節點或AppID模塊的配置被更新

2.2.6 部署

Apollo高可用架構模塊的概覽 :

上圖簡要描述了Apollo的總體設計，我們可以從下往上看：

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

2.2.7 小結

Apollo在配置管理流程上比較完善，相應配置的發布審核、權限管理等、配置的繼承等，但Apollo需要使用人員進行簡單學習，存在學習成本。

Appollo部署較為復雜需要3個模塊同時工作，部署一套生產高可用集群至少需要7個節點。

3. 總結

3.1 功能比較

3.2 結論

從配置中心角度來看，性能方面Nacos的讀寫性能最高，Apollo次之;功能方面Apollo最為完善，但Nacos具有Apollo大部分配置管理功能。Nacos的一大優勢是整合了注冊中心、配置中心功能，部署和操作相比 Apollo都要直觀簡單，因此它簡化了架構復雜度，并減輕運維及部署工作。

總的來看，Apollo和Nacos生態支持都很廣泛，在配置管理流程上做的都很好。Apollo相對于Nacos在配置管理做的更加全面;Nacos則使用起來相對比較簡潔，在對性能要求比較高的大規模場景更適合。

對于公司目前來說，修改配置的次數不是特別的頻繁，對于配置權限的管理不是特別嚴格的，且對讀寫性能有一定要求的，可采用Nacos，反之使用Apollo。

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