作者：席翁
繼 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架構下的服務發現，用戶端通過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+小夥伴！ 感謝你們對中國開源事業的推動 ！
除了參與開源，我們也歡迎更多有能力及有意願的同學加入阿裡雲共建雲原生，詳情請點選
職位連結。
掃碼了解更多技術幹貨和客戶案例：