Spring Cloud Config、Apollo、Nacos配置中心選型及對比

---

資源總體皆來源於網絡，自己根據多家博文，作者等進行了個人的歸納和整理。

---

主流配置中心的比較 Spring Cloud Config、Apollo、Nacos。

1、Nacos

• Nacos 致力於幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集，幫助您實現動態服務發現、服務配置管理、服務及流量管理。
• Nacos 幫助您更敏捷和容易地構建、交付和管理微服務平臺。 Nacos 是構建以“服務”爲中心的現代應用架構(例如微服務範式、雲原生範式)的服務基礎設施。

Nacos 支持基於 DNS 和基於 RPC 的服務發現。在Spring Cloud中使用Nacos，只需要先下載 Nacos 並啓動 Nacos server，Nacos只需要簡單的配置就可以完成服務的註冊發現。

Nacos除了服務的註冊發現之外，還支持動態配置服務。動態配置服務可以讓您以中心化、外部化和動態化的方式管理所有環境的應用配置和服務配置。動態配置消除了配置變更時重新部署應用和服務的需要，讓配置管理變得更加高效和敏捷。配置中心化管理讓實現無狀態服務變得更簡單，讓服務按需彈性擴展變得更容易。

1.1 Nacos主要提供以下四大功能

1. 服務發現與服務健康檢查
   Nacos使服務更容易註冊自己並通過DNS或HTTP接口發現其他服務。Nacos還提供服務的實時健康檢查，以防止向不健康的主機或服務實例發送請求。

2. 動態配置管理
   動態配置服務允許您在所有環境中以集中和動態的方式管理所有服務的配置。Nacos消除了在更新配置時重新部署應用程序和服務的需要，這使配置更改更加高效和靈活。

3. 動態DNS服務
   Nacos支持加權路由，使您可以更輕鬆地在數據中心的生產環境中實施中間層負載平衡，靈活的路由策略，流量控制和簡單的DNS解析服務。它可以幫助您輕鬆實現基於DNS的服務發現，並防止應用程序耦合到特定於供應商的服務發現API。

4. 服務和元數據管理
   Nacos提供易於使用的服務儀表板，可幫助您管理服務元數據，配置，kubernetes DNS，服務運行狀況和指標統計。

2、Spring Cloud Config

爲服務端和客戶端提供了分佈式系統的外部配置支持，配置服務器爲各應用的所有環境提供了一箇中心化的外部配置。Spring Cloud 配置服務器默認採用 Git 來存儲配置信息，其配置存儲、版本管理、發佈等功能都基於 Git 或其他外圍系統來實現。

支持Profile的方式隔離多個環境，通過在Git上配置多個Profile的配置文件，客戶端啓動時指定Profile就可以訪問對應的配置文件。單獨創建一個配置文件的項目，在config server的git中配置即可。

Spring Cloud Config原生不支持配置的實時推送，需要依賴Git的WebHook、Spring Cloud Bus和客戶端/bus/refresh端點:

1. 基於Git的WebHook，配置變更觸發server端refresh
2. Server端接收到請求併發送給Spring Cloud Bus
3. Spring Cloud Bus接到消息並通知給客戶端
4. 客戶端接收到通知，請求Server端獲取最新配置

3、Apollo

Apollo： 攜程開源的配置管理中心，具備規範的權限、流程治理等特性。能夠集中化管理應用不同環境、不同集羣的配置，配置修改後能夠實時推送到應用端，並且具備規範的權限、流程治理等特性，適用於微服務配置管理場景。

• Apollo有 單獨的管理界面，並且不用整合gitee/gitlab，配置簡單。
• 用戶在Apollo修改完配置併發布後，客戶端能實時（1秒）接收到最新的配置，並通知到應用程序。
• 支持配置的灰度發佈，比如點了發佈後，只對部分應用實例生效，等觀察一段時間沒問題後再推給所有應用實例。
• Apollo自身提供了比較完善的統一配置管理界面，支持多環境、多數據中心配置管理、權限、流程治理等特性。
• 配置中心作爲基礎服務，可用性要求非常高，這就要求Apollo對外部依賴儘可能地少，目前唯一的外部依賴是MySQL，所以部署非常簡單，只要安裝好Java和MySQL就可以讓Apollo跑起來，Apollo還提供了打包腳本，一鍵就可以生成所有需要的安裝包，並且支持自定義運行時參數。

4、Eureka，Apollo，Spring Cloud Config三者對比

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-1mNpvxLE-1589335604620)(https://pics2.baidu.com/feed/55e736d12f2eb938e919ed1b2e15f133e4dd6f65.jpeg?token=a7d3087ca0c954a2131754f345984771)]

4.1 Nacos vs Spring Cloud

• Nacos = Spring Cloud Eureka + Spring Cloud Config
• Nacos 可以與 Spring, Spring Boot, Spring Cloud 集成，並能代替 Spring Cloud Eureka, Spring Cloud Config。
  1. 通過 Nacos Server 和 spring-cloud-starter-alibaba-nacos-config 實現配置的動態變更。
  2. 通過 Nacos Server 和 spring-cloud-starter-alibaba-nacos-discovery 實現服務的註冊與發現。

4.2 Apollo 與 Nacos 功能對比

• nacos配置文件支持比較多的格式，支持yaml、text、json、xml、html、Properties，apollo只支持xml、text、Properties的格式，沒有兼容springboot中比較通用的yaml配置。
• apollo用戶管理以及權限管理做的比較好和全面，適合做部門或者公司級的配置中心。nacos比較簡潔明瞭（也可以說沒有做權限這一塊的開發），適合做小組內，或者小型java團體使用。
• apollo區分多環境是直接通過環境指定，可以直接對比和切換，而nacos是通過命名空間進行區分的。
• nacos是支持多格式的配置文件，但是解析上沒有apollo做的好，apollo雖然支持的配置格式較少，不過會進行解析，使每個配置看起來比較直觀，修改的時候比較直觀，可以對單個進行修改。

4.2.1 Nacos與Apollo對比結論

1. Nacos部署簡化，Nacos整合了註冊中心、配置中心功能，且部署相比apollo簡單，方便管理和監控。
2. apollo容器化較困難，Nacos有官網的鏡像可以直接部署，總體來說，Nacos比apollo更符合KISS原則
3. 性能方面，Nacos讀寫tps比apollo稍強一些

4.3 Nacos與Eureka註冊中心對比

阿里的nacos : 性能最好

1. 他同時支持AP和CP模式,他根據服務註冊選擇臨時和永久來決定走AP模式還是CP模式,
2. 他這裏支持CP模式對於我的理解來說,應該是爲了配置中心集羣,因爲nacos可以同時作爲註冊中心和配置中心,
3. 因爲他的配置中心信息是保存在nacos裏面的,假如因爲nacos其中一臺掛掉後,還沒有同步配置信息,就可能發生配置不一致的情況.,
4. 配置中心的配置變更是服務端有監聽器,配置中心發生配置變化,然後服務端會監聽到配置發生變化,從而做出改變

eureka+spring cloud config:

1. 性能也不差,對於服務數量小於上千臺來說,性能沒有問題
2. eureka: 可以做註冊中心,完全AP,支持註冊中心之間的節點複製,同時支持服務端同時註冊多個註冊中心節點, 所以不存節點信息不一致的情況
3. config: 單獨服務,是從git倉庫拉取配置信息,然後服務端從config服務裏面拉取配置信息緩存到本地倉庫， 這裏配置的變更比較麻煩,他需要結合bus組件,同時約束了只能用rabbitmq和kafka來進行通知服務端進行配置變更。
4. 但是保證了數據的一致性,因爲他的配置信息在git倉庫上,git倉庫只有一個,就會數據一致

4.3.1 Nacos與Eureka對比結論

1. Nacos具備服務優雅上下線和流量管理（API+後臺管理頁面），而Eureka的後臺頁面僅供展示，需要使用api操作上下線且不具備流量管理功能。
2. 從部署來看，Nacos整合了註冊中心、配置中心功能，把原來兩套集羣整合成一套，簡化了部署維護
3. 從長遠來看，Eureka開源工作已停止，後續不再有更新和維護，而Nacos在以後的版本會支持SpringCLoud+Kubernetes的組合，填補 2 者的鴻溝，在兩套體系下可以採用同一套服務發現和配置管理的解決方案，這將大大的簡化使用和維護的成本。同時來說,Nacos 計劃實現 Service Mesh，是未來微服務的趨勢
4. 從伸縮性和擴展性來看Nacos支持跨註冊中心同步，而Eureka不支持，且在伸縮擴容方面，Nacos比Eureka更優（nacos支持大數量級的集羣）。
5. Nacos具有分組隔離功能，一套Nacos集羣可以支撐多項目、多環境。