簡介
前面我們分析了攜程的 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 打包在一起部署。
我們來看看 nacos，首先，它沒有將配置中心拆成很多個服務，其次，它的負載均衡方案也比較簡單，一個 SLB 就可以搞定。要知道 nacos 同樣也維護着與客戶端的長連接。
那麼，這兩種架構哪種更好呢？我會更傾向於使用 nacos，至少中小型系統我會這麼選擇，因爲它更簡單。不過，apollo 考慮到長連接對 SLB 的負擔而增加了那麼多組件，按理是經過了深思熟慮，所以，我很想知道，在大型系統中使用 nacos，是否有遇到過 SLB 瓶頸的案例，希望有大佬指點。
以上基本講完了 nacos 的結構和使用。如有錯誤，歡迎指正。
最後，感謝閱讀。
參考資料
本文爲原創文章，轉載請附上原文出處鏈接：https://www.cnblogs.com/ZhangZiSheng001/p/16344519.html