簡介：Nacos 是阿里巴巴于 2018 年開源的注冊(cè)中心及配置中心產(chǎn)品，幫助用戶的分布式微服務(wù)應(yīng)用進(jìn)行服務(wù)發(fā)現(xiàn)和配置管理功能。隨著 Nacos2.0 版本的發(fā)布，在性能和擴(kuò)展性上取得較大突破后，社區(qū)開始考慮如何提供更加云原生方向的功能和用法。本次分享主要介紹 Nacos 在 2.0 版本在Kubernetes 環(huán)境下對(duì)服務(wù)發(fā)現(xiàn)生態(tài)的應(yīng)用探索成果及后續(xù)探索方向的規(guī)劃。

作者：楊翊（席翁）

議題簡介：Nacos 是阿里巴巴于 2018 年開源的注冊(cè)中心及配置中心產(chǎn)品，幫助用戶的分布式微服務(wù)應(yīng)用進(jìn)行服務(wù)發(fā)現(xiàn)和配置管理功能。隨著 Nacos2.0 版本的發(fā)布，在性能和擴(kuò)展性上取得較大突破后，社區(qū)開始考慮如何提供更加云原生方向的功能和用法。本次分享主要介紹 Nacos 在 2.0 版本在Kubernetes 環(huán)境下對(duì)服務(wù)發(fā)現(xiàn)生態(tài)的應(yīng)用探索成果及后續(xù)探索方向的規(guī)劃。

分享人：楊翊（席翁），Alibaba Nacos PMC，Apache ShardingSphere PMC，目前主要涉獵服務(wù)發(fā)現(xiàn)及數(shù)據(jù)庫中間件的開發(fā)。

目錄：

? ? Nacos2.0簡介

? ? Nacos在K8s中服務(wù)發(fā)現(xiàn)的應(yīng)用實(shí)踐

? ? Nacos的K8s服務(wù)網(wǎng)格應(yīng)用規(guī)劃

正文：

一、Nacos2.0簡介

1. ?什么是Nacos

Nacos/nɑ:k??s/是Dynamic Naming and Configuration Service的首字母簡稱，是一個(gè)更易于構(gòu)建云原生應(yīng)用的動(dòng)態(tài)服務(wù)發(fā)現(xiàn)、配置管理和服務(wù)管理平臺(tái)。

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

Nacos在開源的三年多中，用戶的使用場景變得越來越復(fù)雜，用戶規(guī)模越來越龐大，基于Nacos1.0的HTTP架構(gòu)就暴露出來了性能問題和擴(kuò)展性問題，于是Nacos進(jìn)行了2.0的架構(gòu)升級(jí)，引入了Grpc這個(gè)更高效的通信協(xié)議。并對(duì)功能架構(gòu)做了大量的重構(gòu)和優(yōu)化。最終使得Nacos2.0在擴(kuò)展性和性能上提升了10倍。

2. ?Nacos2.0架構(gòu)：

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

a. ?接入層

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

b. ?通信協(xié)議和連接層

接下來一層是通信協(xié)議和連接層。

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

Nacos2.0在連接層上統(tǒng)一進(jìn)行了請(qǐng)求處理的抽象，并且做了流量控制和負(fù)載均衡，以防止Nacos服務(wù)端在大量應(yīng)用注冊(cè)或配置的時(shí)候把服務(wù)端壓垮導(dǎo)致雪崩效應(yīng)，影響更多人應(yīng)用。

c. ?功能層

功能層包括服務(wù)發(fā)現(xiàn)Naming和配置管理Config，Nacos2.0做了大量的重構(gòu)和優(yōu)化，也是性能能夠提升10倍的另一個(gè)原因。

d. ?一次性協(xié)議

Nacos2.0給服務(wù)發(fā)現(xiàn)提供的是Distro協(xié)議和Raft協(xié)議，目前已經(jīng)將Raft協(xié)議替換為SOFA的JRaft協(xié)議，新增了Notify協(xié)議用于配置管理中來通知配置發(fā)生變更。

e. ?持久化層

因?yàn)橛泻芏嗟呐渲眯畔⒒蚍?wù)元數(shù)據(jù)是需要持久化的，所以推薦在生產(chǎn)環(huán)境中使用MySQL這一類的RDS去做持久化會(huì)相對(duì)穩(wěn)定一些。但是在不是特別重要的場景下，我們也可以使用Derby數(shù)據(jù)庫或本地的文件系統(tǒng)進(jìn)行存儲(chǔ)。

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

目前已經(jīng)由社區(qū)志愿者開發(fā)完成了一些插件，正在準(zhǔn)備合并主干分支中。

另一方面，對(duì)于原生能力適配后續(xù)也會(huì)根據(jù)插件化的方式進(jìn)行擴(kuò)展，比如MCP協(xié)議、xDS協(xié)議。

3. ?Nacos2.0開源生態(tài)

在整個(gè)微服務(wù)生態(tài)中，Nacos也在積極和其他微服務(wù)開源社區(qū)和產(chǎn)品進(jìn)行結(jié)合。

比如Dubbo、RPC框架和SOFA的RPC框架以及應(yīng)用框架Spring Cloud Alibaba、還有高可用框架Sentinel（在運(yùn)行生態(tài)中做一些隔斷等操作）。

各類網(wǎng)關(guān)也用到了Nacos，比如阿里基于Nginx研發(fā)的Tengine網(wǎng)關(guān)、Spring Cloud Gateway、Zuul都是社區(qū)中比較常用的。

Nacos也在和原生社區(qū)進(jìn)行結(jié)合，比如MCP協(xié)議就是進(jìn)行數(shù)據(jù)交換、向Envoy網(wǎng)關(guān)推送配置規(guī)則、和應(yīng)用框架（比如Dapr多語言框架）進(jìn)行結(jié)合。

二、Nacos在K8s中服務(wù)發(fā)現(xiàn)的應(yīng)用實(shí)踐

1. ?早期的應(yīng)用實(shí)踐

早期Nacos及整個(gè)微服務(wù)應(yīng)用體系并沒有完全接入到K8s的能力體系中（比如服務(wù)網(wǎng)格體系），K8s最初是作為一個(gè)容器資源調(diào)度的平臺(tái)來使用的，在這個(gè)框架下，所有的應(yīng)用節(jié)點(diǎn)以及Nacos自身節(jié)點(diǎn)會(huì)基于K8s進(jìn)行部署，用K8s的一些自我恢復(fù)以及易于擴(kuò)容縮容的能力作為資源的調(diào)度。

在K8s框架下面，流量依次經(jīng)過以下兩層：

a. ?流量首先會(huì)從Tengine網(wǎng)關(guān)進(jìn)入，Tengine網(wǎng)關(guān)需要承載一些大流量的接入，其核心能力是安全防護(hù)和http證書認(rèn)證，追求的是通用性、穩(wěn)定性和高性能；

b. ?流量進(jìn)入Tengine網(wǎng)關(guān)后，會(huì)進(jìn)入微服務(wù)網(wǎng)關(guān)。微服務(wù)網(wǎng)關(guān)側(cè)重的是鑒權(quán)的認(rèn)證和服務(wù)的治理，比如流量的動(dòng)態(tài)路由、協(xié)議轉(zhuǎn)換（http轉(zhuǎn)Dubbo協(xié)議）這樣的相關(guān)能力；像是Spring Cloud、gateway、Zuul都屬于微服務(wù)網(wǎng)管類型。流量在經(jīng)過微服務(wù)網(wǎng)關(guān)的一個(gè)轉(zhuǎn)發(fā)和路由后就會(huì)進(jìn)入到整個(gè)微服務(wù)體系中，在微服務(wù)體系中的微服務(wù)框架Dubbo或者阿里內(nèi)部的HSF，以及云上應(yīng)用框架Spring Cloud Gateway，它們會(huì)通過SDK服務(wù)注冊(cè)到Nacos中，同時(shí)，可能也會(huì)通過Nacos SDK訂閱它所依賴的服務(wù)，獲取到它的服務(wù)列表，最后進(jìn)行流量的調(diào)用。

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

a. ?Tengine不支持熱更新

Tengine網(wǎng)關(guān)識(shí)別基于Nginx開發(fā)的，不支持動(dòng)態(tài)配置，在配置變更后，需要人工進(jìn)行reload(重新加載)操作才能使變更后的配置生效，這就導(dǎo)致了緊急配置不能及時(shí)生效，影響研發(fā)效率和線上處理故障的效率；

b. ?兩層網(wǎng)關(guān)成本高

流量經(jīng)過兩層網(wǎng)關(guān)（Tengine網(wǎng)關(guān)和微服務(wù)網(wǎng)關(guān)），流量的RT會(huì)相對(duì)變長，而且架構(gòu)中如果引入一個(gè)插件，系統(tǒng)會(huì)變得更加復(fù)雜，對(duì)應(yīng)的運(yùn)維成本和服務(wù)器成本會(huì)增加；

c. ?Fat SDK模式，服務(wù)治理、服務(wù)發(fā)現(xiàn)等邏輯與SDK強(qiáng)耦合，升級(jí)困難

在Nacos架構(gòu)中，服務(wù)發(fā)現(xiàn)能力主要是基于應(yīng)用所依賴的Nacos SDK所實(shí)現(xiàn)的，這會(huì)導(dǎo)致SDK和應(yīng)用的耦合度非常高，SDK一旦出現(xiàn)問題或需要添加一個(gè)功能時(shí)，就需要應(yīng)用側(cè)對(duì)SDK進(jìn)行升級(jí)，這個(gè)升級(jí)過程時(shí)間長而且難度大；

d. ?多語言維護(hù)成本高，服務(wù)治理策略不統(tǒng)一

不同公司的業(yè)務(wù)和系統(tǒng)會(huì)使用不同的編程語言，維護(hù)不同多語言的SDK成本會(huì)比較高。不同語言的SDK在實(shí)現(xiàn)上會(huì)有一定的差別，而且版本演進(jìn)遲緩，這導(dǎo)致有不能統(tǒng)一功能或治理策略，影響到最終的流量治理情況；

e. ?純粹只拿K8s作為調(diào)度，應(yīng)用程度低

這個(gè)框架是純粹的將K8s作為一個(gè)資源調(diào)度的工具，并沒有使用到K8s提供的一些高級(jí)能力比如服務(wù)網(wǎng)格。

2. ?云原生改造-使用服務(wù)網(wǎng)格

為了解決以上5個(gè)問題，就需要對(duì)應(yīng)用和框架進(jìn)行改造。

在改造的時(shí)候，我們先看到了K8s服務(wù)網(wǎng)格中抽象的服務(wù)面和控制面的概念。

控制面就是服務(wù)治理中的一個(gè)思想，它把所有的流量控制能力下沉到Sidecar中；數(shù)據(jù)面負(fù)責(zé)流量轉(zhuǎn)發(fā)。

當(dāng)控制面出現(xiàn)問題的時(shí)候，數(shù)據(jù)面仍然能夠通過原來的配合進(jìn)行流量轉(zhuǎn)發(fā)，不會(huì)受到影響，這其實(shí)和微服務(wù)治理的思想是一致的，所以就決定以服務(wù)網(wǎng)格為方向進(jìn)行改造。

改造可分為以下幾個(gè)方面：

a. ?首先要替換微服務(wù)網(wǎng)關(guān)，因?yàn)镵8s的網(wǎng)關(guān)定義了一套標(biāo)準(zhǔn)的接口，即Ingress網(wǎng)關(guān)，Ingress本身就是一個(gè)標(biāo)準(zhǔn)的接口或者說是一套能力的定義。具體的Ingress網(wǎng)關(guān)實(shí)現(xiàn)有很多種方式，比如Envoy網(wǎng)關(guān)就是其中之一，并且Envoy網(wǎng)關(guān)目前基本上已經(jīng)成為當(dāng)前社區(qū)的首選，所以我們也將采用Ingress網(wǎng)關(guān)、Envoy網(wǎng)關(guān)來替換原來的微服務(wù)網(wǎng)關(guān)。

b. ?在應(yīng)用節(jié)點(diǎn)方面，在引入了數(shù)據(jù)面Envoy和控制面Istio后，Envoy會(huì)以Sidecar模式和應(yīng)用部署在同一個(gè)Pod之中，來劫持應(yīng)用的進(jìn)駐流量。通過Istio下發(fā)的xDS配置來實(shí)現(xiàn)流量的控制、安全防護(hù)和可觀測能力的構(gòu)建。

這樣的架構(gòu)的優(yōu)勢，是使服務(wù)治理能力和業(yè)務(wù)邏輯能力完全分開了，也能解決一部分多語言的問題。但是在應(yīng)用過程中，這個(gè)架構(gòu)會(huì)遇到很多問題，特別是對(duì)于一些技術(shù)占比比較大的企業(yè)，這個(gè)問題會(huì)更加嚴(yán)峻：

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

b. ?應(yīng)用元數(shù)據(jù)需要轉(zhuǎn)移到Pod的label或annotation中，維護(hù)成本和改造成本高；

c. ?注冊(cè)中心如何支持服務(wù)網(wǎng)格生態(tài)？

3. ?解決方案

a. ?將網(wǎng)關(guān)升級(jí)優(yōu)化

將兩個(gè)網(wǎng)關(guān)Tengine網(wǎng)關(guān)和Envoy網(wǎng)關(guān)進(jìn)行融合，融合后的網(wǎng)關(guān)命名為云原生網(wǎng)關(guān)。云原生網(wǎng)關(guān)同時(shí)具備了微服務(wù)網(wǎng)關(guān)的能力，能夠直接對(duì)接K8s的所有服務(wù)體系，而且具備了一定Tengine網(wǎng)關(guān)的能力、https證書認(rèn)證、安全防護(hù)的擴(kuò)展能力。這個(gè)云原生網(wǎng)關(guān)的優(yōu)勢就是將兩個(gè)網(wǎng)關(guān)合二為一，這樣減少了服務(wù)器的部署成本。

這個(gè)云原生網(wǎng)關(guān)其實(shí)已經(jīng)在阿里云上提供給廣大用戶生產(chǎn)使用了（可以搜索“微服務(wù)引擎MSE”）。

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

Envoy網(wǎng)關(guān)接入服務(wù)網(wǎng)格體系后，應(yīng)用的流量也會(huì)被Envoy網(wǎng)關(guān)的Sidecar進(jìn)行轉(zhuǎn)發(fā)。在新的接入體系中，未接入服務(wù)網(wǎng)格體系的應(yīng)用可以通過原來的Fat SDK將服務(wù)注冊(cè)到Nacos之上；對(duì)于接入了服務(wù)網(wǎng)格的應(yīng)用節(jié)點(diǎn)或新應(yīng)用，可以通過Sidecar將信息注冊(cè)到Nacos中，Nacos就有了一個(gè)全量的服務(wù)信息，對(duì)于未接入服務(wù)網(wǎng)格體系的應(yīng)用節(jié)點(diǎn)來說，可以通過Fat SDK直接進(jìn)入到所有的服務(wù)列表，包括接入和未接入的所有應(yīng)用，就可以在整個(gè)K8s體系中進(jìn)行一個(gè)正確的流量調(diào)用。

對(duì)于一些接入了服務(wù)網(wǎng)格體系的應(yīng)用節(jié)點(diǎn)，可以通過Istio、xDS協(xié)議獲取到Nacos所有新舊的服務(wù)節(jié)點(diǎn)，也可以在Envoy網(wǎng)關(guān)中進(jìn)行正確的流量路由。

b. ?MCP協(xié)議和MCP-Over-XDS協(xié)議

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

Nacos支持MCP協(xié)議和MCP Over XDS協(xié)議，最終，Nacos可以支持新舊服務(wù)系統(tǒng)，也可以通過原來的Fat SDK獲取到所有的應(yīng)用節(jié)點(diǎn)，這樣就可以實(shí)現(xiàn)整個(gè)新舊微服務(wù)體系中互聯(lián)互通、平滑迭代，并且能夠無縫支持服務(wù)網(wǎng)格生態(tài)。

4. ?阿里落地實(shí)踐

在阿里的落地實(shí)踐架構(gòu)中，中間部分是集團(tuán)的服務(wù)架構(gòu)，如果新業(yè)務(wù)或部分應(yīng)用的灰度節(jié)點(diǎn)會(huì)接入MSE體系，基于Envoy/Sidecar方式注冊(cè)到Nacos中，很多正在承載線上業(yè)務(wù)流量的節(jié)點(diǎn)仍然使用舊的SDK的體系進(jìn)行注冊(cè)和發(fā)現(xiàn)。在Nacos管理的所有服務(wù)列表中，通過Istio下發(fā)到Ingress的Envoy網(wǎng)關(guān)，實(shí)現(xiàn)預(yù)期的調(diào)用。隨著灰度程度擴(kuò)大，會(huì)逐漸將原來的Fat SDK模式逐漸全部轉(zhuǎn)化為Envoy/Sidecar模式。

在右邊釘釘?shù)募軜?gòu)模型中，因?yàn)獒斸敱旧硎且粋€(gè)新的業(yè)務(wù)，而且它和集團(tuán)之間依賴關(guān)系比較弱，所以它可以直接使用這種云原生網(wǎng)關(guān)加服務(wù)網(wǎng)格的架構(gòu)進(jìn)行落地，流量經(jīng)過MSE云原生網(wǎng)關(guān)，云原生網(wǎng)關(guān)中有從Nacos網(wǎng)關(guān)中獲取到的所有服務(wù)的信息，就可以通過Dubbo3協(xié)議轉(zhuǎn)發(fā)到各個(gè)微服務(wù)體系框架中，進(jìn)行和預(yù)期一樣的調(diào)用。

上圖左邊是螞蟻的用戶流量，它先是經(jīng)過Tengine網(wǎng)關(guān)，然后是經(jīng)過Mson On Envoy網(wǎng)關(guān)，再路由到它們自身的一個(gè)SOFA Micro Service體系中進(jìn)行調(diào)用。在跨業(yè)務(wù)域的調(diào)用過程中，云原生網(wǎng)關(guān)和Envoy網(wǎng)關(guān)也能夠很好的進(jìn)行互相調(diào)用、互相發(fā)現(xiàn)，這樣的話也可以解決跨業(yè)務(wù)域之間的網(wǎng)絡(luò)安全性能問題，因?yàn)橹挥芯W(wǎng)關(guān)可以進(jìn)行互相調(diào)用和互相發(fā)現(xiàn)，微服務(wù)體系之間是不能互相調(diào)用和發(fā)現(xiàn)的。

三、Nacos的K8s服務(wù)網(wǎng)格應(yīng)用規(guī)劃

1. ?趨勢分析

? ? 根據(jù)CNCF的調(diào)查，27%的公司正在生產(chǎn)環(huán)境中使用微服務(wù)網(wǎng)格，也有23%的公司正在評(píng)估服務(wù)網(wǎng)格技術(shù)。服務(wù)網(wǎng)格新技術(shù)正在被廣大社區(qū)和開發(fā)者所認(rèn)可；

? ? 服務(wù)網(wǎng)格技術(shù)經(jīng)過這幾年的發(fā)展逐漸趨于穩(wěn)定，社區(qū)也越來越標(biāo)準(zhǔn)化。比如微軟就提出了一套控制面的API標(biāo)準(zhǔn)。但是服務(wù)網(wǎng)格技術(shù)目前沒有在社區(qū)內(nèi)達(dá)成共識(shí)，反而由XDS演化來的UDPA在CNCF的運(yùn)作下最有可能成為數(shù)據(jù)面的標(biāo)準(zhǔn)；

? ? 統(tǒng)一控制面將是Nacos后續(xù)參與服務(wù)網(wǎng)格的主要方向,也會(huì)成為Nacos未來發(fā)展和更新的主要方向。

2. ?Nacos統(tǒng)一控制面

在K8s服務(wù)發(fā)現(xiàn)體系中其實(shí)類似于動(dòng)態(tài)DNS的能力，實(shí)現(xiàn)由域名（服務(wù)名）到IP的轉(zhuǎn)換過程，它其實(shí)是一個(gè)應(yīng)用級(jí)別或Pod級(jí)別的信息，根據(jù)這個(gè)Pod級(jí)別的信息來生成對(duì)應(yīng)控制面規(guī)則，它的粒度是比較粗的。

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

Nacos可以通過一定手段獲取到相關(guān)信息，可以獲取到暴露了哪些接口、輸入/輸出參數(shù)對(duì)應(yīng)的是什么等這類信息，利用這些更細(xì)節(jié)、更細(xì)膩的信息來進(jìn)行控制面的生成，能夠更精細(xì)的控制流量的轉(zhuǎn)發(fā)（灰度能力），簡單來說就是微服務(wù)治理能力，這樣可以作為原生服務(wù)網(wǎng)格能力的增強(qiáng)。

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

3. ?Nacos的服務(wù)治理生態(tài)

其實(shí)在整個(gè)的實(shí)踐和落地過程中，將已經(jīng)運(yùn)行在微服務(wù)產(chǎn)品或微服務(wù)體系中的應(yīng)用遷移到服務(wù)網(wǎng)格體系中的代價(jià)非常大的，而且這個(gè)過程中，對(duì)于不同的業(yè)務(wù)線、不同部門在對(duì)接過程中是有很多重復(fù)工作的，將微服務(wù)體系遷移到微服務(wù)網(wǎng)格中同樣也會(huì)面臨這樣的問題和阻力。

所以我們希望將Nacos和其它微服務(wù)產(chǎn)品共同解決這個(gè)問題，可以共同制定一個(gè)微服務(wù)治理的標(biāo)準(zhǔn)協(xié)議，來實(shí)現(xiàn)低成本或無成本的無縫對(duì)接；也可以將服務(wù)治理的標(biāo)準(zhǔn)協(xié)議轉(zhuǎn)化成服務(wù)網(wǎng)格協(xié)議（比如xDS協(xié)議），可以快速實(shí)現(xiàn)和原生服務(wù)網(wǎng)格控制面的對(duì)接，讓使用微服務(wù)產(chǎn)品的用戶享受到低成本遷移到服務(wù)網(wǎng)格生態(tài)的便利，這也是Nacos今后發(fā)展的主要方向。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。