今天這篇文章將重點(diǎn)分析 nacos 和 apollo 在設(shè)計(jì)上的差異；以下分析基于 apollo 1.8.0 和 nacos 2.1.0。

安全性的差異

這里說(shuō)的安全性，不是指控制臺(tái)讀配置中心，而是客戶端讀配置中心。

之前我說(shuō)過(guò)，如果所有環(huán)境都共用一個(gè)配置中心，會(huì)存在安全問(wèn)題。因?yàn)殚_發(fā)人員能拿到測(cè)試環(huán)境的配置，按理也能拿到生產(chǎn)環(huán)境的配置。

為了解決這個(gè)問(wèn)題，一般有兩個(gè)方案：

①不同環(huán)境使用不同的配置中心。

apollo 用的就是這一種，當(dāng)客戶端需要獲取生產(chǎn)配置時(shí)，運(yùn)維需要在項(xiàng)目的啟動(dòng)參數(shù)中指定生產(chǎn)環(huán)境的配置中心。

這種方案要想可靠，生產(chǎn)環(huán)境的 config server 地址絕對(duì)不能泄露?？膳碌氖?，我曾經(jīng)就遇到過(guò)直接把 config server 注冊(cè)到公用 eureka 上面的。

②不同環(huán)境使用同一的配置中心，但要做好環(huán)境隔離。

nacos 則采用這一種，隔離的方案就是命名空間 + 鑒權(quán)。

和 apollo 不同，客戶端去讀 nacos 是需要賬號(hào)密碼的，當(dāng)客戶端需要獲取生產(chǎn)配置時(shí)，運(yùn)維需要在項(xiàng)目的啟動(dòng)參數(shù)中指定生產(chǎn)環(huán)境的 namespace 以及對(duì)應(yīng)的賬號(hào)密碼。

上面說(shuō)到了 namespace。apollo 和 nacos 都有這個(gè)概念，不過(guò)，在 apollo 里，namespace 可以看成是一個(gè)具體的配置文件，而 nacos 里，namespace 表示具體的環(huán)境。

它們的數(shù)據(jù)模型如下圖：

使用 apollo 是通過(guò)連接不同的 config server 來(lái)區(qū)分環(huán)境，而 nacos 則通過(guò)指定 namespace 來(lái)區(qū)分。

綜上，我們知道，要想確保安全，使用 apollo 時(shí)不能泄露 config server 生產(chǎn)環(huán)境的地址，使用 nacos 時(shí)不能泄露對(duì)應(yīng)生產(chǎn)環(huán)境 namespace 的賬號(hào)密碼。

如果要說(shuō)哪種方案更安全，我會(huì)更傾向于 nacos，因?yàn)橄啾荣~號(hào)密碼，服務(wù)器地址會(huì)更容易泄露。

系統(tǒng)復(fù)雜度的差異

在講 apollo 的設(shè)計(jì)時(shí)，我吐槽過(guò)，apollo 的架構(gòu)太重了。

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

我不能接受的是，apollo 為了實(shí)現(xiàn)客戶端到 config service 的負(fù)載均衡而引入了過(guò)多的組件。

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

但官方說(shuō)之所以這么設(shè)計(jì)是為了避免客戶端和 config service 之間的長(zhǎng)連接給 SLB 增加過(guò)多的負(fù)擔(dān)，這么說(shuō)的話，，也不無(wú)道理。

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

我們來(lái)看看 nacos，首先，它沒有將配置中心拆成很多個(gè)服務(wù)，其次，它的負(fù)載均衡方案也比較簡(jiǎn)單，一個(gè) SLB 就可以搞定。要知道 nacos 同樣也維護(hù)著與客戶端的長(zhǎng)連接。

那么，這兩種架構(gòu)哪種更好呢？我會(huì)更傾向于使用 nacos，至少中小型系統(tǒng)我會(huì)這么選擇，因?yàn)樗?jiǎn)單。