Nacos 簡(jiǎn)介

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

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

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

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

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

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

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

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

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

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

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

隨著云原生技術(shù)的發(fā)展和微服務(wù)2.0架構(gòu)的提出，很多公司正在嘗試通過(guò)服務(wù)網(wǎng)格技術(shù)去解決微服務(wù)1.0架構(gòu)中的問(wèn)題。在微服務(wù)架構(gòu)2.0架構(gòu)中，流量是通過(guò) ingress 網(wǎng)關(guān)接入的，進(jìn)入微服務(wù)體系，與1.0架構(gòu)不同的是引入了數(shù)據(jù)面Envoy和控制面Istio，Envoy以Sidecar模式與應(yīng)用部署在同一個(gè)Pod中，會(huì)劫持應(yīng)用的進(jìn)出流量，然后可以通過(guò)控制面Istio下發(fā)的XDS配置實(shí)現(xiàn)流量控制、安全、可觀測(cè)能力，這一架構(gòu)的優(yōu)勢(shì)是將服務(wù)治理能力與業(yè)務(wù)邏輯解耦，把服務(wù)框架中SDK大部分能力剝離出來(lái)，下沉到Sidecar，也實(shí)現(xiàn)了不同語(yǔ)言的統(tǒng)一治理。

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

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

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

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

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

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

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

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

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

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

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

場(chǎng)景一：

釘釘云上和集團(tuán)互通的場(chǎng)景，本質(zhì)其實(shí)就是混合云場(chǎng)景下的應(yīng)用互通，我們是用了網(wǎng)關(guān)去打通這兩個(gè)環(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會(huì)通過(guò)MCP協(xié)議從Nacos同步服務(wù)列表數(shù)據(jù)。

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

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

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

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

場(chǎng)景二：

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