設定中心的設計-nacos vs apollo
簡介
前面我們分析了攜程的 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