今天這篇文章將重點分析 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，因為相比賬號密碼，服務器地址會更容易泄露。

系統復雜度的差異

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

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

我不能接受的是，apollo 為了實現客戶端到 config service 的負載均衡而引入了過多的組件。

如圖，增加了 SLB、meta server、eureka 等組件，這個我真的覺得沒必要，直接使用 SLB 來做負載均衡就行。

但官方說之所以這么設計是為了避免客戶端和 config service 之間的長連接給 SLB 增加過多的負擔，這么說的話，，也不無道理。

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

我們來看看 nacos，首先，它沒有將配置中心拆成很多個服務，其次，它的負載均衡方案也比較簡單，一個 SLB 就可以搞定。要知道 nacos 同樣也維護著與客戶端的長連接。

那么，這兩種架構哪種更好呢？我會更傾向于使用 nacos，至少中小型系統我會這么選擇，因為它更簡單。