nacos 簡介
nacos /nɑ:kəʊs/ 是 dynamic naming and configuration service的首字母簡稱。目标是建構一個更易于建構雲原生應用的動态服務發現、配置管理和服務管理平台。
nacos 在阿裡巴巴起源于 2008 年五彩石項目（該項目完成微服務拆分和業務中台建設），成長于十年的阿裡雙十一峰值考驗，這一階段主要幫助業務解決微服務的擴充性和高可用問題，解決了百萬執行個體擴充性問題（10w->100w執行個體）。2018 年我們深刻感受到開源軟體行業的影響，是以決定将 nacos 開源，輸出阿裡十年關于服務發現和配管管理的沉澱，推動微服務行業發展，加速企業數字化轉型。
随着近幾年雲原生技術的發展，服務網格技術的提出，越來越多的公司嘗試将微服務架構遷移到服務網格架構，這對nacos也提出了一個新的訴求，那就是如何更好的支援服務網格生态。
nacos無縫支援服務網格
我們先看下微服務1.0下的架構，流量從tengine進來，經過微服務網關，然後再進入微服務體系。
這裡解釋下為什麼分了兩層網關，第一層tegine是負責流量的接入，核心具備的能力是抗大流量、安全防護和支援https證書，追求的是通用性、穩定性和高性能。第二層是微服務網關，這層網關側重的是認證鑒權、服務治理、協定轉換、動态路由等微服務相關的能力，比如開源的spring cloud gateway，zuul等都屬于微服務網關。
流量進入微服務體系後，會通過微服務架構實作服務間的調用，比如hsf/dubbo、spring cloud等等，那麼nacos在這裡起到的核心作用是服務發現能力，比如cousumer會先從nacos擷取provider的服務清單位址，然後再發起調用，還有微服務網關也會通過nacos擷取上遊的服務清單。這些能力主要通過sdk的方式提供，同時也會在sdk上增加一些負載均衡、容載保護的政策。
微服務1.0架構主要存在以下幾個問題：
1、tengine不支援動态配置，包括開源的nginx原生也是不支援的，阿裡内部是定期reload配置的方式實作配置變更，這導緻配置不能及時變更，影響研發效率；
2、fat sdk模式下，服務治理、服務發現等邏輯與sdk強耦合，如果需要變更邏輯，就得修改sdk，推動業務方更新；
3、多語言下需要維護不同語言的sdk，成本高，服務治理政策難以統一;
随着雲原生技術的發展和微服務2.0架構的提出，很多公司正在嘗試通過服務網格技術去解決微服務1.0架構中的問題。在微服務架構2.0架構中，流量是通過 ingress 網關接入的，進入微服務體系，與1.0架構不同的是引入了資料面envoy和控制面istio，envoy以sidecar模式與應用部署在同一個pod中，會劫持應用的進出流量，然後可以通過控制面istio下發的xds配置實作流量控制、安全、可觀測能力，這一架構的優勢是将服務治理能力與業務邏輯解耦，把服務架構中sdk大部分能力剝離出來，下沉到sidecar，也實作了不同語言的統一治理。
服務網格技術優勢非常多，但是新架構的引入也會帶來新的問題，尤其是對于技術包袱比較重的公司，将面臨的問題，比如：sidecar性能問題、私有協定支援問題、新舊架構體系如何平滑遷移等等。
本文主要關注新舊架構體系平滑遷移這個問題，平滑遷移必然會面對的兩個關于服務發現的問題：
1、新舊架構體系如何互相發現，因為遷移過程必然存在兩個體系共存的情況，應用需要互相調用；
2、注冊中心如何支援微服務網格生态，因為istio目前預設支援的是k8s的service服務發現機制；
我們看下在nacos服務網格生态下是如何解決這些問題，架構圖如下，流量是從雲原生網關（雲原生網關，它具備的特點是與微服務架構保持相容，既支援微服務網關，同時又能符合雲原生架構，支援k8s标準的ingress網關）進來，然後進入微服務體系，微服務體系中1.0應用(非mesh化應用)和已經mesh化的應用共存。
先看下非mesh化應用是如何通路已經mesh化的應用， 從這個架構圖可以看到非mesh化的應用還是通過sdk方式從nacos進行服務注冊或者服務訂閱，已經mesh化的provider也會注冊到nacos上，這樣非mesh化的應用也能擷取到已經mesh化的應用服務資訊，provider注冊服務一般是通過sdk方式，因為開源envoy不支援代理注冊功能，當然我們阿裡内部實作的時候，其實已經把服務注冊的能力下沉到sidecar。
另一個問題，mesh化的應用的服務發現是怎麼做的。我們可以看架構圖的下面這部分，nacos已經支援了mcp server的能力，istio是通過mcp協定從nacos擷取全量的服務資訊清單，然後再轉化成xds配置下發到envoy，這樣即支援了mesh化應用内的服務發現，也能通路非mesh化的服務，業務在mesh化過程中服務發現不需要做任何改造，就能無縫遷移。
這裡簡單介紹下mcp協定，mcp協定是istio社群提出的元件之間配置同步協定，這個協定在1.8之後就廢棄了，替代方案是mcp over xds協定，nacos兩個協定都相容。
除了mcp協定同步方案外，也有其它方案實作注冊中心的服務資料同步到servicemesh體系，我們對這些方案做了對比，如下圖描述：
nacos服務網格生态阿裡落地實踐
最後給大家介紹下阿裡巴巴nacos服務網格生态的實踐，下面這張圖總體概括了阿裡落地的兩個場景。
場景一： 釘釘雲上和集團互通的場景，本質其實就是混合雲場景下的應用互通，我們是用了網關去打通這兩個環境，釘釘vpc（阿裡雲部署）這邊用的是mse雲原生網關，集團用的是envoy網關，他們之間使用dubbo3.0的triple協定實作網絡通訊，網關的控制面都使用的是istio，istio會通過mcp協定從nacos同步服務清單資料。
使用這個架構解決了兩個問題：
1、私有雲和公有雲網絡通訊安全問題，因為網關之間使用mtls加密通訊； 2、平滑支援微服務架構，因為應用通過triple協定調用網關，不需要業務做代碼改動，服務發現則是通過nacos mcp去同步資料； 這套架構同時也用于螞蟻集團互通的場景，就是這張圖的左邊，螞蟻的網關使用的是mosn on envoy的架構。
場景二： 集團的微服務mesh化場景，對應這張圖的中下部分，内部落地與社群的差異點是，envoy直接對接了nacos注冊中心，使用這個方案主要還是考慮到性能問題，我們有些應用會有幾萬的執行個體ip，如果通過eds推送，因為資料量過大，會導緻istio oom或者envoy資料面cpu飙高等問題。