Nacos 簡介

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

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

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

Nacos無縫支持服務網格

我們先看下微服務1.0下的架構，流量從Tengine進來，經過微服務網關，然后再進入微服務體系。

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

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

微服務1.0架構主要存在以下幾個問題：

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

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

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

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

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

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

1、新舊架構體系如何互相發(fā)現，因為遷移過程必然存在兩個體系共存的情況，應用需要互相調用；

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

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

先看下非mesh化應用是如何訪問已經mesh化的應用， 從這個架構圖可以看到非mesh化的應用還是通過SDK方式從Nacos進行服務注冊或者服務訂閱，已經mesh化的provider也會注冊到Nacos上，這樣非mesh化的應用也能獲取到已經mesh化的應用服務信息，provider注冊服務一般是通過sdk方式，因為開源envoy不支持代理注冊功能，當然我們阿里內部實現的時候，其實已經把服務注冊的能力下沉到sidecar。

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

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

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

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

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

場景一：

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

使用這個架構解決了兩個問題：

1、私有云和公有云網絡通訊安全問題，因為網關之間使用mtls加密通訊；

2、平滑支持微服務架構，因為應用通過triple協議調用網關，不需要業(yè)務做代碼改動，服務發(fā)現則是通過Nacos mcp去同步數據；

這套架構同時也用于螞蟻集團互通的場景，就是這張圖的左邊，螞蟻的網關使用的是Mosn on Envoy的架構。

場景二：

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