前不久，在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架構存在的問題
一句話總結，心跳多，無效查詢多，心跳續約感知變化慢，連線消耗大，資源空耗嚴重。
1、 心跳數量多，導致TPS居高不下
通過心跳續約，當服務規模上升時，特別是類似Dubbo的介面級服務較多時，心跳及配置後設資料的輪詢數量眾多，導致叢集TPS很高，系統資源高度空耗。
2、 通過心跳續約感知服務變化，時延長
心跳續約需要達到超時時間才會移除並通知訂閱者，預設為15s，時延較長，時效性差。若改短超時時間，當網路抖動時，會頻繁觸發變更推送，對客戶端服務端都有更大損耗。
3、 UDP推送不可靠，導致QPS居高不下
由於UDP不可靠，因此客戶端測需要每隔一段時間進行對賬查詢，保證客戶端快取的服務列表的狀態正確，當訂閱客戶端規模上升時，叢集QPS很高，但大多數服務列表其實不會頻繁改變，造成無效查詢，從而存在資源空耗。
4、基於HTTP短連線模型，TIME_WAIT狀態連線過多
HTTP短連線模型，每次客戶端請求都會建立和銷燬TCP連結，TCP協議銷燬的連結狀態是WAIT_TIME，完全釋放還需要一定時間，當TPS和QPS較高時，服務端和客戶端可能有大量的WAIT_TIME狀態連結，從而會導致connect time out錯誤或者Cannot assign requested address 的問題。
5、配置模組的30秒長輪詢 引起的頻繁GC
配置模組使用HTTP短連線阻塞模型來模擬長連線通訊，但是由於並非真實的長連線模型，因此每30秒需要進行一次請求和資料的上下文切換，每一次切換都有引起造成一次記憶體浪費，從而導致服務端頻繁GC。
2.0架構
Nacos 2.0 架構最主要的變化就是增加了對長連線的支援，gRPC 和 Rsocket 實現了長連線 RPC 呼叫和推送能力。
2.0服務模型
雖然Nacos2.0的在架構層次上並未做太大的變化，但是具體的模型細節卻有不小的改動，依舊使用註冊服務的流程
Nacos 2.0架構的優缺點
優點
1、 客戶端不再需要定時傳送例項心跳，只需要有一個維持連線可用keepalive訊息即可。重複TPS可以大幅降低。
2、 TCP連線斷開可以被快速感知到，提升反應速度。
3、 長連線的流式推送，比UDP更加可靠；nio的機制具有更高的吞吐量，而且由於可靠推送，可以加長客戶端用於對賬服務列表的時間，甚至刪除相關的請求。重複的無效QPS可以大幅降低。
4、 長連線避免頻繁連線開銷，可以大幅緩解TIME_ WAIT問題。
5、 真實的長連線，解決配置模組GC問題。
6、 更細粒度的同步內容，減少服務節點間的通訊壓力。
缺點
沒有銀彈的方案，新架構也會引入一些新問題
1、 內部結構複雜度上升，管理連線狀態，連線的負載均衡需要管理。
2、 資料由原來的無狀態，變為與連線繫結的有狀態資料，流程鏈路更長。
3、 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架構的一些缺點，如負載均衡，可觀測性進行提升。