Nacos 簡介

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

Nacos 在阿里巴巴起源于 2008 年五彩石項(xiàng)目（該項(xiàng)目完成微服務(wù)拆分和業(yè)務(wù)中臺建設(shè)），成長于十年的阿里雙十一峰值考驗(yàn)，這一階段主要幫助業(yè)務(wù)解決微服務(wù)的擴(kuò)展性和高可用問題，解決了百萬實(shí)例擴(kuò)展性問題（10w->100w實(shí)例）。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ìn)來，經(jīng)過微服務(wù)網(wǎng)關(guān)，然后再進(jìn)入微服務(wù)體系。

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

流量進(jìn)入微服務(wù)體系后，會通過微服務(wù)框架實(shí)現(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上增加一些負(fù)載均衡、容載保護(hù)的策略。

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

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

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

3、多語言下需要維護(hù)不同語言的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)接入的，進(jìn)入微服務(wù)體系，與1.0架構(gòu)不同的是引入了數(shù)據(jù)面Envoy和控制面Istio，Envoy以Sidecar模式與應(yīng)用部署在同一個Pod中，會劫持應(yīng)用的進(jìn)出流量，然后可以通過控制面Istio下發(fā)的XDS配置實(shí)現(xiàn)流量控制、安全、可觀測能力，這一架構(gòu)的優(yōu)勢是將服務(wù)治理能力與業(yè)務(wù)邏輯解耦，把服務(wù)框架中SDK大部分能力剝離出來，下沉到Sidecar，也實(shí)現(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)的問題：

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

2、注冊中心如何支持微服務(wù)網(wǎng)格生態(tài)，因?yàn)閕stio目前默認(rèn)支持的是k8s的service服務(wù)發(fā)現(xiàn)機(jī)制；

我們看下在Nacos服務(wù)網(wǎng)格生態(tài)下是如何解決這些問題，架構(gòu)圖如下，流量是從云原生網(wǎng)關(guān)（云原生網(wǎng)關(guān)，它具備的特點(diǎn)是與微服務(wù)架構(gòu)保持兼容，既支持微服務(wù)網(wǎng)關(guān)，同時又能符合云原生架構(gòu)，支持K8s標(biāo)準(zhǔn)的ingress網(wǎng)關(guān)）進(jìn)來，然后進(jì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進(jìn)行服務(wù)注冊或者服務(wù)訂閱，已經(jīng)mesh化的provider也會注冊到Nacos上，這樣非mesh化的應(yīng)用也能獲取到已經(jīng)mesh化的應(yīng)用服務(wù)信息，provider注冊服務(wù)一般是通過sdk方式，因?yàn)殚_源envoy不支持代理注冊功能，當(dāng)然我們阿里內(nèi)部實(shí)現(xiàn)的時候，其實(shí)已經(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é)議同步方案外，也有其它方案實(shí)現(xiàn)注冊中心的服務(wù)數(shù)據(jù)同步到ServiceMesh體系，我們對這些方案做了對比，如下圖描述：

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

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

場景一：

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

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

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

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

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

場景二：

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