簡介：本文分享了阿里巴巴服務網格技術三位一體戰略背後的思考和實踐，關於阿里雲服務網格 ASM 的一些產品功能，包括最近釋出的一些功能，歡迎大家點選下文檢視詳情～
作者：宗泉、宇曾
阿里巴巴三位一體戰略
阿里雲內部很早就提出了開源、自研、商業化三位一體戰略，先談談我對它的理解。
多年的軟體開發經驗告訴我們，開發出一款出色的軟體有一些關鍵要素：
- 溝通
- 反饋
- 實踐
在軟體開發過程中我們不能閉門造車，不能隨意“創造”業務場景需求。業務場景和產品功能需要提煉，開源給我們提供了一個共同創新的平臺，基於這個平臺，大家可以共同定義一些規範和標準。不同的廠商遵循相應的標準，客戶就沒有被鎖定的風險，可以不停地遷移，總是能找到最好的廠商，將自己的業務放上去，用最簡單、最便捷、最經濟的方式來運營自己的業務。
很多客戶在選擇阿里雲服務網格的時候，有一條比較重要的評判指標：是否和社群 Istio 相容。因為客戶擔心被鎖定，強依賴於阿里雲；
然後說到自研，也許有同學會問到，開源與自研是否互相矛盾，答案是否定的。
因為，我們這裡提到的自研，其實是基於開源的自研，並非摒棄開源的版本，重新造個新的輪子。自研是指我們要對開源產品有足夠深度的理解：
- 要掌握所有原始碼；
- 擁有修改每一行程式碼的能力
- 當然，自研還有意味著可能有自身業務特定獨有的需求場景，一些沒辦法標準化的場景。
基於自研，對開源產品的深度把控和理解，我們將有通用客戶場景需求的功能搬到雲上，封裝成雲產品，讓雲上客戶可以開箱即用去使用，這是商業化的初心。
回到阿里集團內部，開源、自研、商業其實是一個技術飛輪。
對於阿里的技術同學來說，每年的 雙11 都是一場“盛宴”。為了讓顧客有順滑的購物體驗，給商戶提供更多樣化的讓利活動，阿里電商平臺對於效率、可靠性、規模性的要求在 雙11 的驅動下成倍提高，激發著技術人的潛力。作為基礎技術核心之一，阿里巴巴中介軟體也會在每年 雙11 迎來一次技術的全面演進和升級。
阿里在開源社群中推出了 Dubbo、RocketMQ、Nacos、Seata 等多個為人熟知的開源專案，鼓勵廣大開發者共建中介軟體生態體系，也包括了 ServiceMesh 相關技術。
擁抱服務網格開源技術
阿里雲內部很早就開始調研並實踐 ServiceMesh 技術 。2018 年，Istio 正式釋出 1.0 版本，進入大眾視野。在這更早時期，阿里巴巴內部已經開始參與相關生態開源產品的貢獻。
阿里雲在微服務生態領域，也有一些開源的服務化框架，比如 Dubbo 、Spring Cloud Alibaba，可以說微服務領域，因為電商這層試驗大平臺，阿里雲在這方面是妥妥滴“技術專家”，我們會進行橫向功能對比，對比 Sidecar 模式和原有模式的優缺點；在這過程中，我們也積極參與 Istio 微服務相關生態專案的開源貢獻；例如 Envoy、 Dubbo Filter 、RocketMQ Filter 、Nacos Mcp 功能、Spring Cloud Alibaba、Sentinel 等。
目前流行著各種各樣的服務框架，如何基於不同的框架開發的可互通的業務？服務框架就像鐵路的鐵軌一樣，是互通的基礎，只有解決了服務框架的互通，才有可能完成更高層的業務互通，所以用相同的標準統一，合二為一併共建新一代的服務框架是必然趨勢。
Dubbo 和 HSF 都是阿里巴巴內部在使用的微服務 RPC 框架。這些框架在阿里業務不斷迭代開發的過程提供了堅實的底層微服務能力支援，保障了一個又一個 雙11 大促。
伴隨著雲原生的浪潮，以及整體資源成本優化、DevOps 等大背景下，原有微服務框架 Dubbo 、HSF 的一些缺點也在慢慢暴露出來，比如多語言的支援，配置和程式碼邏輯分離等，SDK 版本升級需要推動業務方，收購的業務採用不同框架互通的問題等。
阿里集團內部部分業務開始嘗試使用服務網格技術來改造底層微服務框架，Dubbo 框架在 Mesh 化的過程中，阿里雲服務網格團隊貢獻了 Envoy Dubbo Filter，就是為了實現原有 Dubbo 業務的 Mesh 化，以獲得服務網格帶來的新的增量價值。
另一方面，Dubbo 社群本身也在朝著雲原生領域往前迭代。Dubbo 從 Dubbo2.7.8 版本開始探討 Dubbo 的雲原生演進方案，為了更好地適配雲原生場景 （基礎設施的變化 Kubernetes 已成為資源排程編排的事實標準），Dubbo 團隊目前在將 Dubbo 2.0 向 Dubbo 3.0 做技術演進，並提出了 Proxyless Mesh 的設計。
隨著業務逐漸上雲，由於上雲路徑的多樣以及從現有架構遷移至雲原生架構的過渡態存在，部署應用的設施靈活異變，雲上的微服務也呈現出多元化的趨勢。跨語言、跨廠商、跨環境的呼叫必然會催生基於開放標準的統一協議和框架，以滿足互通需求，這些場景，正式服務網格擅長的領域，給了服務網格很好的發揮空間；
目前，Dubbo 3.0 社群版本已釋出，核心變化有：
- 應用級服務發現
- Dubbo 2.0 協議演進為 基於 gPRC 的 Triple 協議
- 無 Sidecar 的 ProxylessMesh
Mesh 化不是一蹴而就，對於原有的存量業務類似業務上雲，存在一箇中間過渡階段，傳統微服務框架，例如：Dubbo 、Spring Cloud 等存量業務採用 Nacos、Eureka 、Zookeeper 服務註冊中心，我們需要對它進行相容適配；基於 Istio 控制面開放的 Mcp Over XDS 協議，優先在 Nacos 實現了該協議支援，讓 Istiod 可以直接對接 Nacos 註冊中心。
開源產品在大規模生產環境往往不能直接使用，需要做一些適配和調優，以及一些產品化能力的封裝；例如：Intel 的 mTLS 加速方案。
Intel 提交了 Envoy 側 Upstream 的實現，但 Istiod 還未支援。作為雲產品，我們希望提供給客戶開箱即用的能力，服務網格 ASM 基於 Intel 開源的 mTLS 加速方案，實現了控制面 Istiod 的擴充套件支援，而且因為該 mTLS 加速方案依賴底層資源的實際 CPU 機型（icelake)，ASM 針對使用者業務實際部署做了自適應的加速功能的開啟和關閉，multiBuffer 加速功能在開啟狀態下，採用阿里雲 g7 代 ecs 作為 node 節點，QPS 有接近 80% 的提升。
提到服務網格，經常被提起的一個話題：“它和 Dapr 的區別是什麼？”
Dapr 使用 Sidecar 架構，與應用程式一起作為單獨的程式執行，包括服務呼叫、網路安全和分散式跟蹤等功能。這經常會引發一個問題：Dapr 與 Istio 等服務網格解決方案相比如何？
雖然 Dapr 和服務網格確實存在一些重疊功能，但與專注於網路問題的服務網格不同，Dapr 專注於提供構建基塊，使開發人員更容易將應用程式構建為微服務。Dapr 以開發人員為中心，而服務網格以基礎設施為中心。此外，Dapr 不提供路由或流量分配等關於流量控制的功能。
當然, 兩者可以部署在一起，此時，Dapr 和服務網格的 Sidecar 都在應用環境中執行。
服務網格在阿里巴巴的落地和實踐
前面可以看到阿里針對微服務生態，開源了一些產品，這些產品其實在最開始都是因為有內部業務場景，基於這些內部業務場景的孵化和大規模業務檢驗，內部覺得外部客戶也有類似需求，所以才把這些內部實現全部開源。
對應 Istio Mesh 同樣也是，集團內部業務在很早就開始了 Mesh 的業務探索，我們具體來看：
從整體架構圖可以看到，阿里集團內部提供了一套控制檯供 Mesh 使用者操作，控制檯以應用為視角，整合 CICD、許可權管理、安全生產、SRE 運維繫統等其他平臺，提供應用接入 Mesh 化後的統一 Portal ，讓使用者可以基於 DevOps 的理念，實現對應用的全生命週期管理，並通過 Mesh 方式提供應用服務治理、全鏈路灰度以及安全生產等能力，達到應用 Owner 可以自助和自愈運維的效果。
其中，Mesh 核心能力支援對 Dubbo 、MetaQ(RocketMQ) 、LWP 等 RPC 協議的支援，擴充套件實現了全鏈路染色、路由策略、外掛市場等 Mesh 能力。
同時，阿里集團內部也支援通過 OpenAPI 、Kubernetes API 方式提供給第三方系統整合的能力。
在社群 Istio 架構的基礎上，阿里集團內部和內部中介軟體（Diamond、ConfigServer ） 做了深度整合，相容保留業務的原始使用方式，讓業務無縫接入到 Mesh ，這也是我們考慮到部分 Mesh 業務有需要使用 Nacos ，在 ASM 產品層面支援 Nacos 等多註冊中心的場景；
同時抽象出運維平面，可以通過 UI 控制檯的方式實現服務流量治理規則（virtualservice、destinationrule 等) 的配置，同時通過和 OpenKrusise 的整合，實現 pod 粒度的 Sidecar 的開啟、關閉以及熱升級等功能，通過對集團內部 Prometheus 和 Grafana 以及告警 ARMS 的整合，實現微服務的可觀察和可監控。
阿里集團服務網格的演進路徑
阿里集團服務網格演進分為三個階段：無侵入部分規模化、無侵入全面規模化、雲原生終態，目前叢集業務 Mesh 化處於第二階段。
第一階段：存量業務 Mesh 化存在一個過渡階段，而且需要保障這個過渡階段相對無侵入，讓業務開發者無感知；這是為什麼我們需要採用無侵入方案的背景和前提；並且需要採用 Mesh 覆蓋已有的微服務治理的能力，同時提供 Mesh 的增量價值；
第二階段：全面規模化，同時解決規模化帶來的資源開銷和效能問題，通過 Sidecarcrd 實現服務配置懶載入，達到配置隔離的問題，通過對 Metrics 的優化裁剪，降低 Sidecar 記憶體開銷，同時通過優化 Dubbo/HSFFilter 實現惰性編解碼，提高資料面處理效能降低延遲。
隨著內部業務 Dubbo 2.0/HSF 演進到 Dubbo 3.0 ，最終演進到雲原生終態方案。
第三階段：雲原生終態，隨著基礎設施向 Kubernetes 演進，在雲原生場景下，服務發現、服務治理能力下沉，通過 Mesh 可以解耦業務邏輯和服務治理，實現配置和程式碼邏輯分離，從而更好地 DevOps 化，並享受 Mesh 帶來的豐富的可擴充套件流量排程能力和可觀察性。
Dubbo/HSF RPC 支援多種序列化方式，而 Mesh 針對一些序列化並不能做到很友好的支援，比如 Java 序列化。
因此，業務在 Mesh 化第一階段，針對 Java 序列化，Sidecar 不做編解碼，採用 Passthrough 流量透傳的方式；針對 Hessian2 序列化，Mesh 實現了完整的編解碼支援，並基於效能考慮實現了惰性編解碼。基於此，我們可以實現對這類流量實現流量打標（染色）並通過擴充套件 VirtualService 的方式，實現標籤路由和 Fallback 的能力。還可以實現一些特定的業務場景，如金絲雀釋出、全鏈路灰度等場景；
內部業務 MeshSDK 這層會逐步升級到 Dubbo3.0 SDK，在開啟 Mesh 的場景下，Dubbo3.0 SDK 僅提供 RPC 等能力，對應 ThinSDK 模式，Mesh 化後，Sidecar 的協議支援友好度更好、資源開銷成本有一定的降低；當 Sidecar 故障時，可以快讀切回 FatSDK 模式，業務無感知；
對於叢集內部業務，流量排程存在一些較為複雜的場景，特別是一些規模較大的業務。比如多機房多區域部署， 同時在單個區域下還存在服務多版本、多環境的的路由等
這就涉及到不同維度的路由和後端 cluster 選擇，這些維度可能有：
- 區域化路由
- 機房路由
- 單元化路由
- 環境路由
- 多版本路由
集團電商場景尤為典型，基於此，內部擴充套件 Istio 通過引入新的 CRD：RouteChain、 TrafficLable 以及對 VirtualService 的擴充套件，實現了對流量打標和按標路由的能力。
商業化產品阿里雲服務網格 ASM 也將這些能力進行了不同程度的透出，可以基於此實現比如金絲雀釋出、A/B 測試、全鏈路灰度等場景。
雲產品：阿里雲服務網格 ASM
前面我們介紹了阿里巴巴服務網格在開源和大規模落地方面的實踐，接下來分享下在雲原生三位一體中關於雲產品方面的設計。阿里雲通過總結業務場景落地經驗，持續驅動技術發展，沉澱一系列服務網格核心技術。
在大規模落地方面：比如按需動態推送規則配置，大規模業務無損下 Sidecar 熱升級，支援最全面的異構計算基礎設施，支援多註冊中心與平臺。
在流量治理方面：提供了精細化的流量控制，按需對流量協議、埠動態攔截，零配置實現請求標籤路由以及流量染色，支援多種協議的精細化治理。
在可觀測能力方面：提供了日誌、監控與跟蹤融合的一體化智慧運維，同時基於 eBPF 增強可觀測性，實現無侵入實現全鏈路可觀測，輔助業務快速排障。
在安全能力方面：支援 Spiffe/Spire、實現零信任網路、增強認證鑑權機制, 支援漸進式逐步實現 mTLS。
在效能優化方面：通過 eBPF 技術進行網路加速，實現軟硬一體的效能優化。
阿里雲服務網格 ASM 是業界首個相容 Istio 的託管式服務網格平臺，支援完整的服務網格產品能力：精細化的應用流量管理、端到端的可觀測能力、安全和高可用；支援多語言多環境、多種微服務框架、多協議互聯互通等複雜場景。服務網格 ASM 技術架構已經升全面升級 V2.0， 託管了控制面核心元件，保證了標準版和專業版的架構統一，平滑支援社群各個版本的升級。同時 ASM 在和社群標準統一的基礎上進行各種能力增強。主要包括流量管理和協議增強，支援多種零信任安全能力，支援對接 Nacos、Consul 等多種註冊中心。除此之外通過網格診斷能力快速分析網格的健康狀況，配合控制面告警快速響應。
服務網格 ASM 和各種雲服務能力充分融合，包括鏈路追蹤、Prometheus 監控、日誌服務等可觀測能力。整合 AHAS 支援服務限流、叢集限流和自適應限流，結合微服務引擎 MSE 支援服務治理，並且能夠給跨 VPC 多叢集提供一致的治理體驗。在自定義擴充套件方面支援 OPA 安全引擎，webAssembly 等自定義擴充套件能力。
使用者可以通過 ASM 控制檯、OpenAPI、宣告式雲原生 API、資料面和控制面 Kubeconfig 使用服務網格技術。通過服務網格 ASM 在控制面和管控面的打磨，可以為執行在異構計算基礎設施上的服務提供統一的網格化治理能力（Anywhere Service Mesh），從入口閘道器到資料面 Sidecar 注入，支援容器服務 ACK、Serverless kubernetes、邊緣叢集和外部註冊 Kubernetes 叢集，以及 ECS 虛擬機器等多種基礎設施。
服務網格 ASM 的功能設計
基於 ASM 的流量打標和標籤路由實現全鏈路灰度。微服務軟體架構下，業務新功能上線前搭建完整的一套測試系統進行驗證是相當費人費時的事，隨著所拆分出微服務數量的不斷增大其難度也愈大。基於“流量打標”和“按標路由” 能力是一個通用方案，可以較好地解決測試環境治理、線上全鏈路灰度釋出等相關問題。並且基於服務網格技術可以做到與開發語言無關，該方案適應於不同的 7 層協議，當前服務網格 ASM 已經支援 HTTP/gRpc 和 Dubbo 協議。在 ASM 中引入了全新的 TrafficLabel CRD 用於定義 Sidecar 所需透傳的流量標籤從哪裡獲取，全鏈路流量控制進行邏輯隔離，對流量進行打標（染色）和按標路由，通過使用服務網格 ASM，無需每位技術研發人員部署一整套環境，實現多環境治理，大幅度降低研發成本。
服務網格 ASM 支援實現金絲雀釋出。釋出是整個功能更新到線上的最後一個環節，一些研發過程中累計的問題，在最後釋出環節才會觸發。同時釋出本身也是一個複雜的過程，在釋出過程中，往往容易出現一些錯誤操作或者遺漏關鍵操作。金絲雀釋出配置靈活，策略自定義，可以按照流量或具體的內容進行灰度（比如不同賬號，不同引數），出現問題不會影響全網使用者。圖中給應用打上環境標籤， 通過 TrafficLable 對使用者流量比如對 http-header: user-id % 100 == 20 打上 gray 標籤，同時通過 VirtualService 下發標籤流量路由規則，所以 userId 為 120 的使用者流量會被路由到 gray 灰度環境，userId 為 121 的使用者流量被路由到 normal 正常環境。服務網格 ASM 實現的金絲雀釋出支援按流量百分比路由，按請求特徵（如 http header, 方法引數等）路由，並且和服務網格入口閘道器完美整合，支援 HTTP/gRPC/Dubbo 協議 。
除了使用流量打標和標籤路由得實現全鏈路灰度和金絲雀釋出，服務網格 ASM 也支援和 KubeVela 結合實現漸進式釋出。KubeVela 是一個開箱即用的、現代化的應用交付與管理平臺，能夠簡化面向混合環境的應用交付過程；同時又足夠靈活可以隨時滿足業務不斷高速變化所帶來的迭代壓力。KubeVela 後的應用交付模型 Open Application Model（OAM）是一個從設計與實現上都高度可擴充套件的模型，具有完全以應用為中心、可程式設計式交付工作流、與基礎設施無關的特點。阿里雲服務網格 ASM 支援結合 KubeVela 進行復雜的金絲雀釋出流程可以將 KubeVela 定義的相關配置轉化為流量治理規則下發到資料面。
阿里雲服務網格 ASM 實現了零信任安全能力。在微服務網路中使用 HTTP 通訊的互動並不安全，一旦內部的某個服務被攻陷，攻擊者能夠以該機器為跳板來攻擊內網。服務網格 ASM 能夠減小云原生環境中的被攻擊面積，並提供零信任應用網路所需的基礎框架。通過 ASM 管理服務到服務的安全性，可以確保服務網格的端到端加密、服務級別身份認證和細粒度授權策略。
相比傳統的在應用程式程式碼中構建安全機制，ASM 零信任安全體系具有以下優勢：
- ASM Sidecar 代理的策略生命週期與應用程式保持獨立，因此可以更輕鬆地管理這些 Sidecar 代理。
- ASM 支援動態配置策略，更新策略變得更加容易，更新立即生效而無需重新部署應用程式。
- ASM 提供了對附加到請求的終端使用者憑據進行身份驗證的能力，例如 JWT。
- ASM 的集中控制架構使企業的安全團隊可以構建、管理和部署適用於整個企業的安全策略。
將身份驗證和授權系統作為服務部署在網格中，如同網格中的其他服務一樣，這些安全系統從網格中本身也可以得到安全保證，包括傳輸中的加密、身份識別、策略執行點、終端使用者憑據的身份驗證和授權等。策略控制面定義並管理多種型別的認證策略；網格控制面賦予網格中工作負載身份，並自動輪轉證照；資料面的 Sidecar 程式碼執行策略。圖中使用者配置規則只允許交易服務發起呼叫訂單服務，拒絕購物車服務呼叫訂單服務。
由於服務網格 ASM 是控制平面託管，支援管控多個資料面叢集，流量治理 CR 存在控制平面，支援使用者通過控制平面的 KubeAPI 操作治理規則。在服務網格新版本中，為了：
1、支援使用者在非託管模式下的操作習慣，能夠在資料面 Kubernetes 叢集中讀寫 Istio 資源 ；
2、支援 Helm 常用命令工具；
3、相容其他開源軟體在單叢集 addon 模式下的 API 操作，阿里雲服務網格 ASM 實現了支援資料面叢集 Kube API 訪問 Istio 資源。兩者同時對外提供，使用者可以根據實際場景按需使用。
ASM 相容社群標準，提供了控制平面的平滑升級，那麼資料面的升級可以升級兩種方式：滾動升級和熱升級能力，關於滾動升級能力需要設定升級 Strategy 為 RollingUpdate ，注入 Sidecar 的 Pod 在釋出時，Envoy 映象會自動升級到新版本。圖中主要介紹第二種方式阿里雲服務網格 ASM 結合 OpenKruise 專案實現的熱升級功能，在升級資料平面時不會中斷服務，使資料平面在應用無感知的情況下完成升級。應用釋出和更新自動生成 SidecarSet 配置，更新 SidecarSet 配置完成資料面的升級，目前這項能力在新版本灰度中。
服務網格 ASM 配合阿里雲應用高可用服務 AHAS 可以對部署在服務網格內的應用進行流量控制，目前已經支援單機限流，叢集限流，自適應限流。同時服務網格 ASM 也原生支援 Istio 的全侷限流和本地限流，全侷限流使用全域性 gRPC 服務為整個網格提供速率限制，本地限流用於限制每個服務例項的請求速率，本地限流可以與全侷限流結合使用。
服務網格 ASM 也支援通過 MCP over XDS 協議對接微服務引擎 MSE 的註冊中心，同步服務資訊到網格。MSE 的 Nacos 原生支援 MCP 協議，使用者只需要在建立或更新 ASM 例項時開啟 Nacos 註冊中心對接功能，實現註冊中心的服務同步到服務網格，可以很方便地支援 Dubbo、Spring Cloud 服務的網格化，使用者側無需做任何業務程式碼修改。
最後分享幾個客戶案例，客戶如何使用服務網格 ASM 縮短服務網格技術落地週期、減輕異常排錯成本，節省控制面資源成本。
1、東風日產隨著業務的發展，早前打造的「十二生肖」（十二套完整的測試環境）已無法滿足眾多併發需求，甚至需要搖號分配環境。通過引入阿里雲服務網格 ASM，構建了基於流量管理的「無限生肖」系統，滿足了自動按需提供環境的訴求。基於 ASM 提供的免運維、易升級以及產品豐富支援能力，讓產研團隊集中享受 ServiceMesh 帶來的價值。
2、職優你為了應對業務的全球化擴張與一體化運營，基於阿里雲服務網格 ASM 和容器服務 ACK 將業務應用跨區域部署，通過服務按地域就近訪問的策略，優化了客戶訪問體驗，有效降低業務訪問時延，提升業務響應速度。
3、商米科技引入阿里雲服務網格 ASM，構建智慧的數字化商業智慧 POS 軟硬體一體化系統解決方案，使用服務網格 ASM 解決 gRPC 服務負載均衡、鏈路追蹤以及流量統一管理等核心問題。
本文分享了阿里巴巴服務網格技術三位一體戰略背後的思考和實踐，關於阿里雲服務網格 ASM 的一些產品功能，包括最近釋出的一些功能，例如 Istio 資源歷史版本管理功能、支援資料面叢集 Kubernetes API 訪問 Istio 資源、支援跨地域故障轉移和跨地域流量分佈、支援控制平面日誌採集和日誌告警以及支援基於 KubeVela 實現漸進式釋出等詳細資訊，以及更多關於流量管理，可觀測，零信任安全，解決方案等產品功能，歡迎點選閱讀原文訪問阿里雲服務網格 ASM 的產品文件。如果對服務網格 ASM 感興趣，歡迎釘釘掃描下方二維碼或搜尋群號（30421250）加入服務網格ASM 使用者交流群，一起探索服務網格技術。
點選此處，檢視更多服務網格 ASM 相關資訊～
版權宣告：本文內容由阿里雲實名註冊使用者自發貢獻，版權歸原作者所有，阿里雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協議》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社群將立刻刪除涉嫌侵權內容。