簡介：Nacos 在阿里巴巴起源于 2008 年五彩石項目（該項目完成微服務(wù)拆分和業(yè)務(wù)中臺建設(shè)），成長于十年的阿里雙十一峰值考驗，這一階段主要幫助業(yè)務(wù)解決微服務(wù)的擴展性和高可用問題，解決了百萬實例擴展性問題（10w->100w實例）。2018 年我們深刻感受到開源軟件行業(yè)的影響，因此決定將 Nacos 開源，輸出阿里十年關(guān)于服務(wù)發(fā)現(xiàn)和配管管理的沉淀，推動微服務(wù)行業(yè)發(fā)展，加速企業(yè)數(shù)字化轉(zhuǎn)型。 隨著近幾年云原生技術(shù)的發(fā)展，服務(wù)網(wǎng)格技術(shù)的提出，越來越多的公司嘗試將微服務(wù)架構(gòu)遷移到服務(wù)網(wǎng)格架構(gòu)，這對 Nacos 提出了一個新的訴求，那就是如何更好的支持服務(wù)網(wǎng)格生態(tài)。

作者 | 懷成

Nacos 簡介

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

Nacos 在阿里巴巴起源于 2008 年五彩石項目（該項目完成微服務(wù)拆分和業(yè)務(wù)中臺建設(shè)），成長于十年的阿里雙十一峰值考驗，這一階段主要幫助業(yè)務(wù)解決微服務(wù)的擴展性和高可用問題，解決了百萬實例擴展性問題（10w->100w實例）。2018 年我們深刻感受到開源軟件行業(yè)的影響，因此決定將 Nacos 開源，輸出阿里十年關(guān)于服務(wù)發(fā)現(xiàn)和配管管理的沉淀，推動微服務(wù)行業(yè)發(fā)展，加速企業(yè)數(shù)字化轉(zhuǎn)型。

隨著近幾年云原生技術(shù)的發(fā)展，服務(wù)網(wǎng)格技術(shù)的提出，越來越多的公司嘗試將微服務(wù)架構(gòu)遷移到服務(wù)網(wǎng)格架構(gòu)，這對 Nacos 提出了一個新的訴求，那就是如何更好的支持服務(wù)網(wǎng)格生態(tài)。

Nacos 無縫支持服務(wù)網(wǎng)格

我們先看下微服務(wù) 1.0 下的架構(gòu)，流量從 Tengine 進來，經(jīng)過微服務(wù)網(wǎng)關(guān)，然后再進入微服務(wù)體系。

這里解釋下為什么分了兩層網(wǎng)關(guān)，第一層 Tegine 是負責流量的接入，核心具備的能力是抗大流量、安全防護和支持 https 證書，追求的是通用性、穩(wěn)定性和高性能。第二層是微服務(wù)網(wǎng)關(guān)，這層網(wǎng)關(guān)側(cè)重的是認證鑒權(quán)、服務(wù)治理、協(xié)議轉(zhuǎn)換、動態(tài)路由等微服務(wù)相關(guān)的能力，比如開源的 spring cloud gateway，zuul 等都屬于微服務(wù)網(wǎng)關(guān)。

流量進入微服務(wù)體系后，會通過微服務(wù)框架實現(xiàn)服務(wù)間的調(diào)用，比如 hsf/dubbo、spring cloud 等等，那么 Nacos 在這里起到的核心作用是服務(wù)發(fā)現(xiàn)能力，比如 cousumer 會先從 Nacos 獲取 provider 的服務(wù)列表地址，然后再發(fā)起調(diào)用，還有微服務(wù)網(wǎng)關(guān)也會通過 Nacos 獲取上游的服務(wù)列表。這些能力主要通過 SDK 的方式提供，同時也會在 SDK 上增加一些負載均衡、容載保護的策略。

微服務(wù) 1.0 架構(gòu)主要存在以下幾個問題：

Tengine 不支持動態(tài)配置，包括開源的 Nginx 原生也是不支持的，阿里內(nèi)部是定期 reload 配置的方式實現(xiàn)配置變更，這導(dǎo)致配置不能及時變更，影響研發(fā)效率；

Fat SDK 模式下，服務(wù)治理、服務(wù)發(fā)現(xiàn)等邏輯與 SDK 強耦合，如果需要變更邏輯，就得修改 SDK，推動業(yè)務(wù)方升級；

多語言下需要維護不同語言的 SDK，成本高，服務(wù)治理策略難以統(tǒng)一。

隨著云原生技術(shù)的發(fā)展和微服務(wù) 2.0 架構(gòu)的提出，很多公司正在嘗試通過服務(wù)網(wǎng)格技術(shù)去解決微服務(wù) 1.0 架構(gòu)中的問題。在微服務(wù)架構(gòu) 2.0 架構(gòu)中，流量是通過 ingress 網(wǎng)關(guān)接入的，進入微服務(wù)體系，與 1.0 架構(gòu)不同的是引入了數(shù)據(jù)面 Envoy 和控制面 Istio。

Envoy 以 Sidecar 模式與應(yīng)用部署在同一個 Pod 中，會劫持應(yīng)用的進出流量，然后可以通過控制面 Istio 下發(fā)的 XDS 配置實現(xiàn)流量控制、安全、可觀測能力，這一架構(gòu)的優(yōu)勢是將服務(wù)治理能力與業(yè)務(wù)邏輯解耦，把服務(wù)框架中 SDK 大部分能力剝離出來，下沉到 Sidecar，也實現(xiàn)了不同語言的統(tǒng)一治理。

服務(wù)網(wǎng)格技術(shù)優(yōu)勢非常多，但是新架構(gòu)的引入也會帶來新的問題，尤其是對于技術(shù)包袱比較重的公司，將面臨的問題，比如：sidecar 性能問題、私有協(xié)議支持問題、新舊架構(gòu)體系如何平滑遷移等等。

本文主要關(guān)注新舊架構(gòu)體系平滑遷移這個問題，平滑遷移必然會面對的兩個關(guān)于服務(wù)發(fā)現(xiàn)的問題：

新舊架構(gòu)體系如何互相發(fā)現(xiàn)，因為遷移過程必然存在兩個體系共存的情況，應(yīng)用需要互相調(diào)用；

注冊中心如何支持微服務(wù)網(wǎng)格生態(tài)，因為 istio 目前默認支持的是 k8s 的 service 服務(wù)發(fā)現(xiàn)機制；

我們看下在 Nacos 服務(wù)網(wǎng)格生態(tài)下是如何解決這些問題，架構(gòu)圖如下，流量是從云原生網(wǎng)關(guān)（云原生網(wǎng)關(guān)，它具備的特點是與微服務(wù)架構(gòu)保持兼容，既支持微服務(wù)網(wǎng)關(guān)，同時又能符合云原生架構(gòu)，支持 K8s 標準的 ingress 網(wǎng)關(guān)）進來，然后進入微服務(wù)體系，微服務(wù)體系中 1.0 應(yīng)用(非 mesh 化應(yīng)用)和已經(jīng) mesh 化的應(yīng)用共存。

先看下非 mesh 化應(yīng)用是如何訪問已經(jīng) mesh 化的應(yīng)用。

從這個架構(gòu)圖可以看到非 mesh 化的應(yīng)用還是通過 SDK 方式從 Nacos 進行服務(wù)注冊或者服務(wù)訂閱，已經(jīng) mesh 化的 provider 也會注冊到 Nacos 上，這樣非 mesh 化的應(yīng)用也能獲取到已經(jīng) mesh 化的應(yīng)用服務(wù)信息，provider 注冊服務(wù)一般是通過 sdk 方式，因為開源 envoy 不支持代理注冊功能，當然我們阿里內(nèi)部實現(xiàn)的時候，其實已經(jīng)把服務(wù)注冊的能力下沉到 sidecar。

另一個問題，mesh 化的應(yīng)用的服務(wù)發(fā)現(xiàn)是怎么做的。

我們可以看架構(gòu)圖的下面這部分，Nacos 已經(jīng)支持了 MCP server 的能力，Istio 是通過 MCP 協(xié)議從 Nacos 獲取全量的服務(wù)信息列表，然后再轉(zhuǎn)化成 XDS 配置下發(fā)到 envoy，這樣即支持了 mesh 化應(yīng)用內(nèi)的服務(wù)發(fā)現(xiàn)，也能訪問非 mesh 化的服務(wù)，業(yè)務(wù)在 mesh 化過程中服務(wù)發(fā)現(xiàn)不需要做任何改造，就能無縫遷移。

這里簡單介紹下 MCP 協(xié)議，MCP 協(xié)議是 Istio 社區(qū)提出的組件之間配置同步協(xié)議，這個協(xié)議在 1.8 之后就廢棄了，替代方案是 MCP over XDS 協(xié)議，Nacos 兩個協(xié)議都兼容。

除了 MCP 協(xié)議同步方案外，也有其它方案實現(xiàn)注冊中心的服務(wù)數(shù)據(jù)同步到 ServiceMesh 體系，我們對這些方案做了對比，如下圖描述：

Nacos 服務(wù)網(wǎng)格生態(tài)阿里落地實踐

最后給大家介紹下阿里巴巴 Nacos 服務(wù)網(wǎng)格生態(tài)的實踐，下面這張圖總體概括了阿里落地的兩個場景。

場景一：

釘釘云上和集團互通的場景，本質(zhì)其實就是混合云場景下的應(yīng)用互通，我們是用了網(wǎng)關(guān)去打通這兩個環(huán)境，釘釘 vpc（阿里云部署）這邊用的是 MSE 云原生網(wǎng)關(guān)，集團用的是 Envoy 網(wǎng)關(guān)，他們之間使用 Dubbo3.0 的 triple 協(xié)議實現(xiàn)網(wǎng)絡(luò)通訊，網(wǎng)關(guān)的控制面都使用的是 Istio，Istio 會通過 MCP 協(xié)議從 Nacos 同步服務(wù)列表數(shù)據(jù)。

使用這個架構(gòu)解決了兩個問題：

1、私有云和公有云網(wǎng)絡(luò)通訊安全問題，因為網(wǎng)關(guān)之間使用 mtls 加密通訊；

2、平滑支持微服務(wù)架構(gòu)，因為應(yīng)用通過 triple 協(xié)議調(diào)用網(wǎng)關(guān)，不需要業(yè)務(wù)做代碼改動，服務(wù)發(fā)現(xiàn)則是通過 Nacos mcp 去同步數(shù)據(jù)；

這套架構(gòu)同時也用于螞蟻集團互通的場景，就是這張圖的左邊，螞蟻的網(wǎng)關(guān)使用的是 Mosn on Envoy 的架構(gòu)。

場景二：

集團的微服務(wù) mesh 化場景，對應(yīng)這張圖的中下部分，內(nèi)部落地與社區(qū)的差異點是，Envoy 直接對接了 Nacos 注冊中心，使用這個方案主要還是考慮到性能問題，我們有些應(yīng)用會有幾萬的實例 ip，如果通過 EDS 推送，因為數(shù)據(jù)量過大，會導(dǎo)致 Istio OOM 或者 Envoy 數(shù)據(jù)面 cpu 飆高等問題。

本文是 Nacos 服務(wù)網(wǎng)格生態(tài)直播的文本整理，完整直播內(nèi)容可以參看：https://yqh.aliyun.com/live/detail/26211

Nacos 源代碼倉庫：https://github.com/alibaba/nacos

原文鏈接：https://developer.aliyun.com/article/789199?

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的如何用 Nacos 构建服务网格生态？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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