Nacos 2.0 正式發佈，性能提高了 10 倍！！

前不久，在3月20號，Nacos 2.0.0 正式發佈了！我簡單看了下官方的介紹，可能nacos將來逐漸會成爲各大公司做爲服務治理和配置中心的主要中間件。

Nacos 簡介：一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平臺。

通俗點講，Nacos 就是一把微服務雙劍：註冊中心 + 配置中心，由阿里巴巴於 2018 年開源。

Nacos 2.0.0

概述

一圖看清naocs

架構模型

1.X架構：

Nacos 1.X 大體分爲5層， 分別是接入、通訊、功能、同步和持久化。

1.X服務模型

1.X架構存在的問題

一句話總結，心跳多，無效查詢多，心跳續約感知變化慢，鏈接消耗大，資源空耗嚴重。

一、 心跳數量多，致使TPS居高不下

經過心跳續約，當服務規模上升時，特別是相似Dubbo的接口級服務較多時，心跳及配置元數據的輪詢數量衆多，致使集羣TPS很高，系統資源高度空耗。

二、 經過心跳續約感知服務變化，時延長

心跳續約須要達到超時時間纔會移除並通知訂閱者，默認爲15s，時延較長，時效性差。若改短超時時間，當網絡抖動時，會頻繁觸發變動推送，對客戶端服務端都有更大損耗。

三、 UDP推送不可靠，致使QPS居高不下

因爲UDP不可靠，所以客戶端測須要每隔一段時間進行對帳查詢，保證客戶端緩存的服務列表的狀態正確，當訂閱客戶端規模上升時，集羣QPS很高，但大多數服務列表其實不會頻繁改變，形成無效查詢，從而存在資源空耗。

四、基於HTTP短鏈接模型，TIME_WAIT狀態鏈接過多

HTTP短鏈接模型，每次客戶端請求都會建立和銷燬TCP連接，TCP協議銷燬的連接狀態是WAIT_TIME，徹底釋放還須要必定時間，當TPS和QPS較高時，服務端和客戶端可能有大量的WAIT_TIME狀態連接，從而會致使connect time out錯誤或者Cannot assign requested address 的問題。

五、配置模塊的30秒長輪詢 引發的頻繁GC

配置模塊使用HTTP短鏈接阻塞模型來模擬長鏈接通訊，可是因爲並不是真實的長鏈接模型，所以每30秒須要進行一次請求和數據的上下文切換，每一次切換都有引發形成一次內存浪費，從而致使服務端頻繁GC。

2.0架構

Nacos 2.0 架構最主要的變化就是增長了對長鏈接的支持，gRPC 和 Rsocket 實現了長鏈接 RPC 調用和推送能力。

2.0服務模型

雖然Nacos2.0的在架構層次上並未作太大的變化，可是具體的模型細節卻有不小的改動，依舊使用註冊服務的流程

Nacos 2.0架構的優缺點

優勢
一、 客戶端再也不須要定時發送實例心跳，只須要有一個維持鏈接可用keepalive消息便可。重複TPS能夠大幅下降。

二、 TCP鏈接斷開能夠被快速感知到，提高反應速度。

三、 長鏈接的流式推送，比UDP更加可靠；nio的機制具備更高的吞吐量，並且因爲可靠推送，能夠加長客戶端用於對帳服務列表的時間，甚至刪除相關的請求。重複的無效QPS能夠大幅下降。

四、 長鏈接避免頻繁鏈接開銷，能夠大幅緩解TIME_ WAIT問題。

五、 真實的長鏈接，解決配置模塊GC問題。

六、 更細粒度的同步內容，減小服務節點間的通訊壓力。

缺點
沒有銀彈的方案，新架構也會引入一些新問題

一、 內部結構複雜度上升，管理鏈接狀態，鏈接的負載均衡須要管理。

二、 數據由原來的無狀態，變爲與鏈接綁定的有狀態數據，流程鏈路更長。

三、 RPC協議的觀測性不如HTTP。即便gRPC基於HTTP2.0Stream實現，仍然不如直接使用HTTP協議來的直觀。

Nacos 2.X 規劃

簡單分享下Nacos 2.X 的後期規劃吧。主要分爲文檔、質量和Roadmap。

在文檔和質量方面，Nacos 1.X都作的不是很好。文檔內容較少，僅有簡單使用文檔；和版本有必定脫節，更新不及時；沒有對技術內容的說明，參與貢獻難度高。代碼質量及測試質量也不是很高，雖然已經使用checkstyle進行了codeStyle的校驗以及開啓了社區協做review。可是這還遠遠不夠。Nacos 2.X將會逐步更新、細化官網使用文檔；經過電子書對技術細節進行解析；經過Github展現技術方案，促進討論及貢獻；而且對代碼進行大量重構及UT和IT的治理工做，在將來將Benchmark也會開源出來，方便給開源用戶進行壓測。
而RoadMap方面， Nacos 2.X 會對項目作大幅度的重構，完成初步插件化，並對剛纔2.0架構的一些缺點，如負載均衡，可觀測性進行提高。