重磅官宣：Nacos2.0發佈，性能提高10倍

做者：席翁

繼 Nacos 1.0 發佈以來，Nacos 迅速被成千上萬家企業採用，並構建起強大的生態。可是隨着用戶深刻使用，逐漸暴露一些性能問題，所以咱們啓動了 Nacos 2.0 的隔代產品設計，時隔半年咱們終於將其所有實現，實測性能提高 10 倍，相信能知足全部用戶的性能需求。下面由我表明社區爲你們介紹一下這款跨代產品。

Nacos 簡介

Nacos 是一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。它孵化於阿里巴巴，成長於十年雙十一的洪峯考驗，沉澱了簡單易用、穩定可靠、性能卓越的核心競爭力。

Nacos 2.0 架構

全新 2.0 架構不只將性能大幅提高 10 倍，並且內核進行了分層抽象，而且實現插件擴展機制。

Nacos 2.0 架構層次以下圖，它相比Nacos1.X的最主要變化是：

• 通訊層統一到 gRPC 協議，同時完善了客戶端和服務端的流量控制和負載均衡能力，提高的總體吞吐。
• 將存儲和一致性模型作了充分抽象分層，架構更簡單清晰，代碼更加健壯，性能更增強悍。
• 設計了可拓展的接口，提高了集成能力，如讓用戶擴展實現各自的安全機制。

Nacos2.0 服務發現升級一致性模型

Nacos2.0 架構下的服務發現，客戶端經過 gRPC，發起註冊服務或訂閱服務的請求。服務端使用 Client 對象來記錄該客戶端使用 gRPC 鏈接發佈了哪些服務，又訂閱了哪些服務，並將該 Client 進行服務間同步。因爲實際的使用習慣是服務到客戶端的映射，即服務下有哪些客戶端實例；所以 2.0 的服務端會經過構建索引和元數據，快速生成相似 1.X 中的 Service 信息，並將 Service 的數據經過  gRPC Stream 進行推送。

Nacos2.0 配置管理升級通訊機制

配置管理以前用 Http1.1 的 Keep Alive 模式 30s 發一個心跳模擬長連接，協議難以理解，內存消耗大，推送性能弱，所以 2.0 經過 gRPC 完全解決這些問題，內存消耗大量下降。

Nacos2.0 架構優點

 Nacos2.0 大幅下降了資源消耗，提高吞吐性能，優化客戶端和服務端交互，對用戶更加友好；雖然可觀測性略微降低，可是總體性價比很是高。

Nacos2.0 性能提高

因爲 Nacos 由服務發現和配置管理兩大模塊構成，業務模型略有差別，所以咱們下面分別介紹一下具體壓測指標。

Nacos2.0 服務發現的性能提高
服務發現場景咱們主要關注客戶端數，服務數實例數，及服務訂閱者數在大規模場景下，服務端在同步，推送及穩定狀態時的性能表現。同時還關注在有大量服務在進行上下線時，系統的性能表現。

• 容量及穩定狀態測試

該場景主要關注隨着服務規模和客戶端實例規模上漲，系統性能表現。

能夠看到 2.0.0 版本在 10W 級客戶端規模下，可以穩定的支撐，在達到穩定狀態後，CPU 的損耗很是低。雖然在最初的大量註冊階段，因爲存在瞬時的大量註冊和推送，所以有必定的推送超時，可是會在重試後推送成功，不會影響數據一致性。

反觀 1.X 版本，在 10W、5W 級客戶端下，服務端徹底處於 Full GC 狀態，推送徹底失敗，集羣不可用；在 2W 客戶端規模下，雖然服務端運行狀態正常，但因爲心跳處理不及時，大量服務在摘除和註冊階段反覆進行，所以達不到穩定狀態，CPU 一直很高。1.2W 客戶端規模下，能夠穩定運行，但穩態時 CPU 消耗是更大規模下 2.0 的 3 倍以上。

• 頻繁變動測試

該場景主要關注業務大規模發佈，服務頻繁推送條件下，不一樣版本的吞吐和失敗率。

頻繁變動時，2.0 和 1.X 在達到穩定狀態後，均能穩定支撐，其中 2.0 因爲再也不有瞬時的推送風暴，所以推送失敗率歸 0，而 1.X 的 UDP 推送的不穩定性致使了有極小部分推送出現了超時，須要重試推送。

Nacos2.0 配置管理的性能提高

因爲配置是少寫多讀場景，因此瓶頸主要在單臺監聽的客戶端數量以及配置的推送獲取上，所以配置管理的壓測性能主要集中於單臺服務端的鏈接容量以及大量推送的比較。

• Nacos2.0 鏈接容量測試

該場景主要關注不一樣客戶端規模下的系統壓力。

Nacos2.0 最高單機可以支撐 4.2w 個配置客戶端鏈接，在鏈接創建的階段，有大量訂閱請求須要處理，所以 CPU 消耗較高，但達到穩態後，CPU 的消耗會變得很低。幾乎沒有消耗。

反觀 Nacos1.X， 在客戶端 6000 時，穩定狀態的 CPU 一直很高，且 GC 頻繁，主要緣由是長輪訓是經過 hold 請求來保持鏈接，每 30s 須要回一次 Response 而且從新發起鏈接和請求。須要作大量的上下文切換，同時還須要持有全部 Request 和 Response。當規模達到 1.2w 客戶端時，已經沒法達到穩態，因此沒法支撐這個量級的客戶端數。

• Nacos2.0 頻繁推送測試

該場景關注不一樣推送規模下的系統表現。

在頻繁變動的場景，兩個版本都處於 6000 個客戶端鏈接中。 明顯能夠發現 2.0 版本的性能損耗要遠低於 1.X 版本。在 3000tps 的推送場景下， 優化程度約優化了 3 倍。

Nacos2.0 性能結論

針對服務發現場景，Nacos2.0 可以在 10W 級規模下，穩定運行；相比 Nacos1.X 版本的 1.2W 規模，提高約 10 倍。
針對配置管理場景，Nacos2.0 單機最高可以支撐 4.2W 個客戶端鏈接；相比 Nacos1.X，提高了 7 倍。且推送時的性能明顯好於1.X。

Nacos 生態及 2.X 後續規劃

隨着 Nacos 三年的發展，幾乎支持了全部的 RPC 框架和微服務生態，而且引領雲原生微服務生態發展。

Nacos 是整個微服務生態中很是核心的組件，它能夠無縫和 K8s 服務發現體系互通，經過 MCP/XDS 協議與 Istio 通訊，將 Nacos 服務下發 Sidecar；一樣也能夠和 CoreDNS 聯合，將 Nacos 服務經過域名模式暴露給下游調用。

Nacos 目前已經和各種微服務 RPC 框架融合進行服務發現；另外能夠協助高可用框架 Sentinel 進行各種管理規則的控制和下發。

若是隻使用 RPC 框架，有時候並不足夠簡單，由於部分 RPC 框架好比 gRPC 和 Thrift，還須要自行啓動 Server 並告知 client 該調用哪一個 IP。這時候就須要和應用框架進行融合，好比 SCA、Dapr 等；固然也能夠經過 Envoy Sidecar 來進行流量控制，應用層的RPC就不須要知道服務 的 IP 列表了。

最後，Nacos 還能夠和各種微服務網關打通，實現接入層的分發和微服務調用。

Nacos 生態在阿里的實踐

目前 Nacos 已經完成了自研、開源、商業化三位一體的建設，阿里內部的釘釘、考拉、餓了麼、優酷等業務域已經所有采用雲產品 MSE 中的 Nacos 服務，而且與阿里和雲原生的技術棧無縫整合。下面咱們以釘釘爲例簡單作一下介紹。

Nacos 運行在微服務引擎MSE （全託管的Nacos集羣 ）上，進行維護和多集羣管理； 業務的各種 Dubbo3 或 HSF 服務在啓動時，經過 Dubbo3 自身註冊到 Nacos 集羣中；而後 Nacos 經過 MCP 協議將服務信息同步到 Istio 和 Ingress-Envoy 網關。

用戶流量從北向進入集團的 VPC 網絡中，先經過一個統一接入 Ingress-Tengine 網關，他能夠將域名解析並路由到不一樣的機房、單元等。本週咱們也同步更新了 Tengine 2.3.3版本，內核升級到 Nginx Core 1.18.0 ，支持 Dubbo 協議 ，支持 DTLSv1 和 DTLSv1.2，支持 Prometheus 格式，從而提高阿里雲微服務生態完整性、安全性、可觀測性。

經過統一接入層網關後，用戶請求會經過 Ingress-Envoy 微服務網關，轉發到對應的微服務中，並進行調用。若是須要調用到其餘網絡域的服務，會經過 Ingress-Envoy 微服務網關將流量導入到對應的 VPC 網絡中，從而打通不一樣安全域、網絡域和業務域的服務。

微服務之間的相互調用，會經過 Envoy Sidecar 或傳統的微服務自訂閱的方式進行。最終，用戶請求在各個微服務的互相調用中，完成並返回給用戶。

Nacos 2.X 的規劃

Nacos2.X 將在 2.0 解決性能問題的基礎上，經過插件化實現新的功能並改造大量舊功能，使得 Nacos 可以更方便，更易於拓展。

總結

Nacos2.0 做爲一個跨代版本，完全解決了 Nacos1.X 的性能問題，將性能提高了 10 倍。而且經過抽象和分層讓架構更加簡單，經過插件化更好的擴展，讓 Nacos 可以支持更多場景，融合更廣生態。相信 Nacos2.X 在後續版本迭代後，會更加易用，解決更多微服務問題，並向着 Mesh 化進行更深刻地探索。

加入咱們

歡迎你們在 Nacos Github  上提交 issue 與 PR 進行討論和貢獻，或加入 Nacos 社區羣參與社區討論。 也趁此機會感謝參與 Nacos 貢獻的 200+小夥伴！感謝大家對中國開源事業的推進 ！

除了參與開源，咱們也歡迎更多有能力及有意願的同窗加入阿里雲共建雲原生，詳情可點擊 職位連接。

Nacos 企業版1元包活動限時推廣中…點擊查看