簡介

前面我們分析了攜程的 apollo（見詳解apollo的設計與使用），現在再來看看阿里的 nacos，

和 apollo 一樣，nacos 也是一款配置中心，同樣可以實作配置的集中管理、分環境管理、即時生效等等，不過，nacos 還具備了服務發現的功能，

分析 apollo 時，我們通過四個問題展開：

為什么使用配置中心
如何設計一個配置中心
apollo 是如何設計的
如何使用 apollo

當然，我們也可以用同樣的套路來分析 nacos，不過，第 1、2 個問題是一樣的，沒必要再講一遍，而第 4 個問題嘛，我看官網的檔案已經足夠詳細，所以，這篇博客將重點分析 nacos 和 apollo 在設計上的差異，

以下分析基于 apollo 1.8.0 和 nacos 2.1.0，

安全性的差異

這里說的安全性，不是指控制臺讀配置中心，而是客戶端讀配置中心，

之前我說過，如果所有環境都共用一個配置中心，會存在安全問題，因為開發人員能拿到測驗環境的配置，按理也能拿到生產環境的配置，

為了解決這個問題，一般有兩個方案：

不同環境使用不同的配置中心，apollo 用的就是這一種，當客戶端需要獲取生產配置時，運維需要在專案的啟動引數中指定生產環境的配置中心，這種方案要想可靠，生產環境的 config server 地址絕對不能泄露，可怕的是，我曾經就遇到過直接把 config server 注冊到公用 eureka 上面的，

不同環境使用同一的配置中心，但要做好環境隔離，nacos 則采用這一種，隔離的方案就是命名空間 + 鑒權，和 apollo 不同，客戶端去讀 nacos 是需要賬號密碼的，當客戶端需要獲取生產配置時，運維需要在專案的啟動引數中指定生產環境的 namespace 以及對應的賬號密碼，

上面說到了 namespace，apollo 和 nacos 都有這個概念，不過，在 apollo 里，namespace 可以看成是一個具體的組態檔，而 nacos 里，namespace 表示具體的環境，它們的資料模型如下圖，使用 apollo 是通過連接不同的 config server 來區分環境，而 nacos 則通過指定 namespace 來區分，

綜上，我們知道，要想確保安全，使用 apollo 時不能泄露 config server 生產環境的地址，使用 nacos 時不能泄露對應生產環境 namespace 的賬號密碼，如果要說哪種方案更安全，我會更傾向于 nacos，因為相比賬號密碼，服務器地址會更容易泄露，// zzs001

系統復雜度的差異

在講 apollo 的設計時，我吐槽過，apollo 的架構太重了，

首先，它把配置中心拆成了 config service、admin service、portal，這一點我倒是可以接受，

我不能接受的是，apollo 為了實作客戶端到 config service 的負載均衡而引入了過多的組件，如圖，增加了 SLB、meta server、eureka 等組件，這個我真的覺得沒必要，直接使用 SLB 來做負載均衡就行，但官方說之所以這么設計是為了避免客戶端和 config service 之間的長連接給 SLB 增加過多的負擔，這么說的話，，也不無道理，

不過，有一點比較好的就是，apollo 把 config service、eureka 和 meta server 打包在一起部署，