天天看點

如何用 Nacos 建構服務網格生态

nacos 簡介

nacos /nɑ:kəʊs/ 是 dynamic naming and configuration service的首字母簡稱。目标是建構一個更易于建構雲原生應用的動态服務發現、配置管理和服務管理平台。

nacos 在阿裡巴巴起源于 2008 年五彩石項目(該項目完成微服務拆分和業務中台建設),成長于十年的阿裡雙十一峰值考驗,這一階段主要幫助業務解決微服務的擴充性和高可用問題,解決了百萬執行個體擴充性問題(10w->100w執行個體)。2018 年我們深刻感受到開源軟體行業的影響,是以決定将 nacos 開源,輸出阿裡十年關于服務發現和配管管理的沉澱,推動微服務行業發展,加速企業數字化轉型。

随着近幾年雲原生技術的發展,服務網格技術的提出,越來越多的公司嘗試将微服務架構遷移到服務網格架構,這對nacos也提出了一個新的訴求,那就是如何更好的支援服務網格生态。

如何用 Nacos 建構服務網格生态

nacos無縫支援服務網格

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

這裡解釋下為什麼分了兩層網關,第一層tegine是負責流量的接入,核心具備的能力是抗大流量、安全防護和支援https證書,追求的是通用性、穩定性和高性能。第二層是微服務網關,這層網關側重的是認證鑒權、服務治理、協定轉換、動态路由等微服務相關的能力,比如開源的spring cloud gateway,zuul等都屬于微服務網關。

流量進入微服務體系後,會通過微服務架構實作服務間的調用,比如hsf/dubbo、spring cloud等等,那麼nacos在這裡起到的核心作用是服務發現能力,比如cousumer會先從nacos擷取provider的服務清單位址,然後再發起調用,還有微服務網關也會通過nacos擷取上遊的服務清單。這些能力主要通過sdk的方式提供,同時也會在sdk上增加一些負載均衡、容載保護的政策。

如何用 Nacos 建構服務網格生态

微服務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,也實作了不同語言的統一治理。

如何用 Nacos 建構服務網格生态

服務網格技術優勢非常多,但是新架構的引入也會帶來新的問題,尤其是對于技術包袱比較重的公司,将面臨的問題,比如:sidecar性能問題、私有協定支援問題、新舊架構體系如何平滑遷移等等。

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

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

2、注冊中心如何支援微服務網格生态,因為istio目前預設支援的是k8s的service服務發現機制; ​

我們看下在nacos服務網格生态下是如何解決這些問題,架構圖如下,流量是從雲原生網關(雲原生網關,它具備的特點是與微服務架構保持相容,既支援微服務網關,同時又能符合雲原生架構,支援k8s标準的ingress網關)進來,然後進入微服務體系,微服務體系中1.0應用(非mesh化應用)和已經mesh化的應用共存。

如何用 Nacos 建構服務網格生态

先看下非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服務網格生态阿裡落地實踐

最後給大家介紹下阿裡巴巴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飙高等問題。