本文分享了阿裡巴巴服務網格技術三位一體戰略背後的思考和實踐，關于阿裡雲服務網格 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 測試、全鍊路灰階等場景。
前面我們介紹了阿裡巴巴服務網格在開源和大規模落地方面的實踐，接下來分享下在雲原生三位一體中關于雲産品方面的設計。阿裡雲通過總結業務場景落地經驗，持續驅動技術發展，沉澱一系列服務網格核心技術。
在大規模落地方面： 比如按需動态推送規則配置，大規模業務無損下 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 的流量打标和标簽路由實作全鍊路灰階。微服務軟體架構下，業務新功能上線前搭建完整的一套測試系統進行驗證是相當費人費時的事，随着所拆分出微服務數量的不斷增大其難度也愈大。基于“流量打标”和“按标路由” 能力是一個通用方案，可以較好地解決測試環境治理、線上全鍊路灰階釋出等相關問題。并且基于服務網格技術可以做到與開發語言無關，該方案适應于不同的 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 相關資訊～