簡介：Nacos 是阿里巴巴于 2018 年開源的注冊中心及配置中心產品，幫助用戶的分布式微服務應用進行服務發現和配置管理功能。隨著 Nacos2.0 版本的發布，在性能和擴展性上取得較大突破后，社區開始考慮如何提供更加云原生方向的功能和用法。本次分享主要介紹 Nacos 在 2.0 版本在Kubernetes 環境下對服務發現生態的應用探索成果及后續探索方向的規劃。

作者：楊翊（席翁）

議題簡介：Nacos 是阿里巴巴于 2018 年開源的注冊中心及配置中心產品，幫助用戶的分布式微服務應用進行服務發現和配置管理功能。隨著 Nacos2.0 版本的發布，在性能和擴展性上取得較大突破后，社區開始考慮如何提供更加云原生方向的功能和用法。本次分享主要介紹 Nacos 在 2.0 版本在Kubernetes 環境下對服務發現生態的應用探索成果及后續探索方向的規劃。

分享人：楊翊（席翁），Alibaba Nacos PMC，Apache ShardingSphere PMC，目前主要涉獵服務發現及數據庫中間件的開發。

目錄：

? ? Nacos2.0簡介

? ? Nacos在K8s中服務發現的應用實踐

? ? Nacos的K8s服務網格應用規劃

正文：

一、Nacos2.0簡介

1. ?什么是Nacos

Nacos/nɑ:k??s/是Dynamic Naming and Configuration Service的首字母簡稱，是一個更易于構建云原生應用的動態服務發現、配置管理和服務管理平臺。

Nacos誕生于阿里巴巴的五彩石項目，在阿里十年的雙十一中成長迭代，解決了應用擴展性和大規模治理的問題。為了幫助更多的公司和企業都能享受到微服務帶來的便利并加速數字化轉型，在2018年阿里巴巴將Nacos進行開源。

Nacos在開源的三年多中，用戶的使用場景變得越來越復雜，用戶規模越來越龐大，基于Nacos1.0的HTTP架構就暴露出來了性能問題和擴展性問題，于是Nacos進行了2.0的架構升級，引入了Grpc這個更高效的通信協議。并對功能架構做了大量的重構和優化。最終使得Nacos2.0在擴展性和性能上提升了10倍。

2. ?Nacos2.0架構：

Nacos2.0 架構圖，從上到下依次為接入層、通信協議、連接層、功能層、一次性協議、持久化層

a. ?接入層

首先是接入層，接入層為用戶使用和接入Nacos提供了一個入口，包括一些客戶端、OpenAPI、Springboot、阿里巴巴應用框架、Dubbo的RPC框架，也有一些用戶（主要是運維人員）通過控制臺使用Nacos。

b. ?通信協議和連接層

接下來一層是通信協議和連接層。

Nacos2.0的通信協議新增了gRPC協議，也沿用了Nacos1.0的http和UDP協議，這是為了方便已經在使用Nacos的用戶能夠平滑升級到Nacos2.0上，方便用戶升級。

Nacos2.0在連接層上統一進行了請求處理的抽象，并且做了流量控制和負載均衡，以防止Nacos服務端在大量應用注冊或配置的時候把服務端壓垮導致雪崩效應，影響更多人應用。

c. ?功能層

功能層包括服務發現Naming和配置管理Config，Nacos2.0做了大量的重構和優化，也是性能能夠提升10倍的另一個原因。

d. ?一次性協議

Nacos2.0給服務發現提供的是Distro協議和Raft協議，目前已經將Raft協議替換為SOFA的JRaft協議，新增了Notify協議用于配置管理中來通知配置發生變更。

e. ?持久化層

因為有很多的配置信息或服務元數據是需要持久化的，所以推薦在生產環境中使用MySQL這一類的RDS去做持久化會相對穩定一些。但是在不是特別重要的場景下，我們也可以使用Derby數據庫或本地的文件系統進行存儲。

由于用戶場景越來越復雜，Nacos開始做一些插件化的架構改造，例如鑒權、配置加解密以及多類型的數據元支持，這些都是反饋比較多的插件。

目前已經由社區志愿者開發完成了一些插件，正在準備合并主干分支中。

另一方面，對于原生能力適配后續也會根據插件化的方式進行擴展，比如MCP協議、xDS協議。

3. ?Nacos2.0開源生態

在整個微服務生態中，Nacos也在積極和其他微服務開源社區和產品進行結合。

比如Dubbo、RPC框架和SOFA的RPC框架以及應用框架Spring Cloud Alibaba、還有高可用框架Sentinel（在運行生態中做一些隔斷等操作）。

各類網關也用到了Nacos，比如阿里基于Nginx研發的Tengine網關、Spring Cloud Gateway、Zuul都是社區中比較常用的。

Nacos也在和原生社區進行結合，比如MCP協議就是進行數據交換、向Envoy網關推送配置規則、和應用框架（比如Dapr多語言框架）進行結合。

二、Nacos在K8s中服務發現的應用實踐

1. ?早期的應用實踐

早期Nacos及整個微服務應用體系并沒有完全接入到K8s的能力體系中（比如服務網格體系），K8s最初是作為一個容器資源調度的平臺來使用的，在這個框架下，所有的應用節點以及Nacos自身節點會基于K8s進行部署，用K8s的一些自我恢復以及易于擴容縮容的能力作為資源的調度。

在K8s框架下面，流量依次經過以下兩層：

a. ?流量首先會從Tengine網關進入，Tengine網關需要承載一些大流量的接入，其核心能力是安全防護和http證書認證，追求的是通用性、穩定性和高性能；

b. ?流量進入Tengine網關后，會進入微服務網關。微服務網關側重的是鑒權的認證和服務的治理，比如流量的動態路由、協議轉換（http轉Dubbo協議）這樣的相關能力；像是Spring Cloud、gateway、Zuul都屬于微服務網管類型。流量在經過微服務網關的一個轉發和路由后就會進入到整個微服務體系中，在微服務體系中的微服務框架Dubbo或者阿里內部的HSF，以及云上應用框架Spring Cloud Gateway，它們會通過SDK服務注冊到Nacos中，同時，可能也會通過Nacos SDK訂閱它所依賴的服務，獲取到它的服務列表，最后進行流量的調用。

在以上過程中，Nacos的核心作用是服務發現、負載均衡和服務治理，這也是絕大多數公司或開發者熟悉使用的服務框架，這個框架面臨的問題如下：

a. ?Tengine不支持熱更新

Tengine網關識別基于Nginx開發的，不支持動態配置，在配置變更后，需要人工進行reload(重新加載)操作才能使變更后的配置生效，這就導致了緊急配置不能及時生效，影響研發效率和線上處理故障的效率；

b. ?兩層網關成本高

流量經過兩層網關（Tengine網關和微服務網關），流量的RT會相對變長，而且架構中如果引入一個插件，系統會變得更加復雜，對應的運維成本和服務器成本會增加；

c. ?Fat SDK模式，服務治理、服務發現等邏輯與SDK強耦合，升級困難

在Nacos架構中，服務發現能力主要是基于應用所依賴的Nacos SDK所實現的，這會導致SDK和應用的耦合度非常高，SDK一旦出現問題或需要添加一個功能時，就需要應用側對SDK進行升級，這個升級過程時間長而且難度大；

d. ?多語言維護成本高，服務治理策略不統一

不同公司的業務和系統會使用不同的編程語言，維護不同多語言的SDK成本會比較高。不同語言的SDK在實現上會有一定的差別，而且版本演進遲緩，這導致有不能統一功能或治理策略，影響到最終的流量治理情況；

e. ?純粹只拿K8s作為調度，應用程度低

這個框架是純粹的將K8s作為一個資源調度的工具，并沒有使用到K8s提供的一些高級能力比如服務網格。

2. ?云原生改造-使用服務網格

為了解決以上5個問題，就需要對應用和框架進行改造。

在改造的時候，我們先看到了K8s服務網格中抽象的服務面和控制面的概念。

控制面就是服務治理中的一個思想，它把所有的流量控制能力下沉到Sidecar中；數據面負責流量轉發。

當控制面出現問題的時候，數據面仍然能夠通過原來的配合進行流量轉發，不會受到影響，這其實和微服務治理的思想是一致的，所以就決定以服務網格為方向進行改造。

改造可分為以下幾個方面：

a. ?首先要替換微服務網關，因為K8s的網關定義了一套標準的接口，即Ingress網關，Ingress本身就是一個標準的接口或者說是一套能力的定義。具體的Ingress網關實現有很多種方式，比如Envoy網關就是其中之一，并且Envoy網關目前基本上已經成為當前社區的首選，所以我們也將采用Ingress網關、Envoy網關來替換原來的微服務網關。

b. ?在應用節點方面，在引入了數據面Envoy和控制面Istio后，Envoy會以Sidecar模式和應用部署在同一個Pod之中，來劫持應用的進駐流量。通過Istio下發的xDS配置來實現流量的控制、安全防護和可觀測能力的構建。

這樣的架構的優勢，是使服務治理能力和業務邏輯能力完全分開了，也能解決一部分多語言的問題。但是在應用過程中，這個架構會遇到很多問題，特別是對于一些技術占比比較大的企業，這個問題會更加嚴峻：

a. ?只有全新的應用可以使用，無法和舊體系互通，無法做到平滑迭代；

b. ?應用元數據需要轉移到Pod的label或annotation中，維護成本和改造成本高；

c. ?注冊中心如何支持服務網格生態？

3. ?解決方案

a. ?將網關升級優化

將兩個網關Tengine網關和Envoy網關進行融合，融合后的網關命名為云原生網關。云原生網關同時具備了微服務網關的能力，能夠直接對接K8s的所有服務體系，而且具備了一定Tengine網關的能力、https證書認證、安全防護的擴展能力。這個云原生網關的優勢就是將兩個網關合二為一，這樣減少了服務器的部署成本。

這個云原生網關其實已經在阿里云上提供給廣大用戶生產使用了（可以搜索“微服務引擎MSE”）。

流量經過網關，只需一次轉發，這樣可以降低整個RT；另一方面，像應用側這方面的能力可以通過輕量級SDK將邏輯下沉到Sidecar中，然后這種輕量級SDK只是去獲取信息，然后直接和Sidecar進行交互，這樣大部分邏輯下沉到Sidecar之后，就會降低多語言的維護成本，不需要很大程度的改造業務代碼，可能只需要更換一下SDK版本就可以了。

Envoy網關接入服務網格體系后，應用的流量也會被Envoy網關的Sidecar進行轉發。在新的接入體系中，未接入服務網格體系的應用可以通過原來的Fat SDK將服務注冊到Nacos之上；對于接入了服務網格的應用節點或新應用，可以通過Sidecar將信息注冊到Nacos中，Nacos就有了一個全量的服務信息，對于未接入服務網格體系的應用節點來說，可以通過Fat SDK直接進入到所有的服務列表，包括接入和未接入的所有應用，就可以在整個K8s體系中進行一個正確的流量調用。

對于一些接入了服務網格體系的應用節點，可以通過Istio、xDS協議獲取到Nacos所有新舊的服務節點，也可以在Envoy網關中進行正確的流量路由。

b. ?MCP協議和MCP-Over-XDS協議

在Istio和Nacos之間使用MCP協議連接。MCP協議是Istio社區提出的用于服務組件之間服務同步的協議，在1.8版本之后，Istio社區用MCP-Over-XDS協議替換了MCP協議。

Nacos支持MCP協議和MCP Over XDS協議，最終，Nacos可以支持新舊服務系統，也可以通過原來的Fat SDK獲取到所有的應用節點，這樣就可以實現整個新舊微服務體系中互聯互通、平滑迭代，并且能夠無縫支持服務網格生態。

4. ?阿里落地實踐

在阿里的落地實踐架構中，中間部分是集團的服務架構，如果新業務或部分應用的灰度節點會接入MSE體系，基于Envoy/Sidecar方式注冊到Nacos中，很多正在承載線上業務流量的節點仍然使用舊的SDK的體系進行注冊和發現。在Nacos管理的所有服務列表中，通過Istio下發到Ingress的Envoy網關，實現預期的調用。隨著灰度程度擴大，會逐漸將原來的Fat SDK模式逐漸全部轉化為Envoy/Sidecar模式。

在右邊釘釘的架構模型中，因為釘釘本身是一個新的業務，而且它和集團之間依賴關系比較弱，所以它可以直接使用這種云原生網關加服務網格的架構進行落地，流量經過MSE云原生網關，云原生網關中有從Nacos網關中獲取到的所有服務的信息，就可以通過Dubbo3協議轉發到各個微服務體系框架中，進行和預期一樣的調用。

上圖左邊是螞蟻的用戶流量，它先是經過Tengine網關，然后是經過Mson On Envoy網關，再路由到它們自身的一個SOFA Micro Service體系中進行調用。在跨業務域的調用過程中，云原生網關和Envoy網關也能夠很好的進行互相調用、互相發現，這樣的話也可以解決跨業務域之間的網絡安全性能問題，因為只有網關可以進行互相調用和互相發現，微服務體系之間是不能互相調用和發現的。

三、Nacos的K8s服務網格應用規劃

1. ?趨勢分析

? ? 根據CNCF的調查，27%的公司正在生產環境中使用微服務網格，也有23%的公司正在評估服務網格技術。服務網格新技術正在被廣大社區和開發者所認可；

? ? 服務網格技術經過這幾年的發展逐漸趨于穩定，社區也越來越標準化。比如微軟就提出了一套控制面的API標準。但是服務網格技術目前沒有在社區內達成共識，反而由XDS演化來的UDPA在CNCF的運作下最有可能成為數據面的標準；

? ? 統一控制面將是Nacos后續參與服務網格的主要方向,也會成為Nacos未來發展和更新的主要方向。

2. ?Nacos統一控制面

在K8s服務發現體系中其實類似于動態DNS的能力，實現由域名（服務名）到IP的轉換過程，它其實是一個應用級別或Pod級別的信息，根據這個Pod級別的信息來生成對應控制面規則，它的粒度是比較粗的。

如果可以通過將應用中比較復雜的元數據下沉到Pod里面的lable或annotation中，單獨維護起來，服務網格原生控制面生成的也是能夠滿足一定需求的。但是這樣對于廣大開發者來說，特別是對已經習慣現有體系、同時要維護應用代碼和聲明式API的開發者來說，是比較難以接受的。

Nacos可以通過一定手段獲取到相關信息，可以獲取到暴露了哪些接口、輸入/輸出參數對應的是什么等這類信息，利用這些更細節、更細膩的信息來進行控制面的生成，能夠更精細的控制流量的轉發（灰度能力），簡單來說就是微服務治理能力，這樣可以作為原生服務網格能力的增強。

所以Nacos在未來會做一個控制面的功能，比如說直接實現xDS協議、暴露出一系列控制API等），提供給使用Nacos的用戶做控制面的管理；同時實現xDS協議對控制面的直接對接，也可以解決一部分由于MCP協議同步大量服務信息所帶來的一些問題。

3. ?Nacos的服務治理生態

其實在整個的實踐和落地過程中，將已經運行在微服務產品或微服務體系中的應用遷移到服務網格體系中的代價非常大的，而且這個過程中，對于不同的業務線、不同部門在對接過程中是有很多重復工作的，將微服務體系遷移到微服務網格中同樣也會面臨這樣的問題和阻力。

所以我們希望將Nacos和其它微服務產品共同解決這個問題，可以共同制定一個微服務治理的標準協議，來實現低成本或無成本的無縫對接；也可以將服務治理的標準協議轉化成服務網格協議（比如xDS協議），可以快速實現和原生服務網格控制面的對接，讓使用微服務產品的用戶享受到低成本遷移到服務網格生態的便利，這也是Nacos今后發展的主要方向。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的Nacos2.0的K8s服务发现生态应用及规划的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。