Service Mesh 在超大規模場景下的落地挑戰

做者 | 至簡  阿里雲高級技術專家編程

隨着微服務軟件架構在互聯網企業的普遍實踐，新一代微服務軟件架構技術悄然興起，Service Mesh 即是其中之一。安全

根據 Linkerd CEO Willian Morgan 對 Service Mesh 的定義，Service Mesh 是一層處理服務間通訊的基礎設施。雲原生應用有着複雜的服務拓撲，Service Mesh 保證請求能夠在這些拓撲中安全且可靠地穿梭，對整個服務網絡進行觀測和高效查錯，以及經過靈活的流量治理能力爲新功能上線提供高效的驗證手段。在實際應用當中，Service Mesh 一般是由一系列輕量級的網絡代理（又被稱爲 Sidecar）組成的，它們部署在應用進程的邊上且對應用進程徹底無感。性能優化

國內 Service Mesh 早期實踐基本分爲先建設數據層後建設控制層和同時建設兩類，從後續發展看，隨着對服務運營能力要求的提升，控制層會愈來愈重要。在實際落地方面，衆多企業都在積極探索 Service Mesh 在大規模場景下的應用。網絡

阿里巴巴高級技術專家至簡在 KubeCon 2020 阿里巴巴雲原生專場分享了《Service Mesh 在超大規模場景下的落地挑戰》，基於阿里巴巴的落地實踐，分享一些經驗和思路。如下是部份內容整理。數據結構

分佈式應用架構在阿里巴巴的現狀

阿里巴巴圍繞電商業務構建了龐大的微服務軟件架構應用生態，包括了天貓、淘寶、菜鳥、高德等。其次，整個微服務體系是經過 Dubbo RPC 鏈接在一塊兒，MetaQ 用於服務之間的異步解耦。架構

目前阿里巴巴主要的技術棧仍是 Java，圍繞 Java 構建了至關健全的微服務治理能力，其餘技術棧的微服務治理能力相對弱不少。在服務可見性這塊，阿里巴巴是徹底沒有隔離的。Dubbo RPC 還是接口級服務發現，1 個應用若是提供 10 個接口，那麼就會有 10 個服務是能夠被發現的，若是這個應用有 n 臺機器，那麼 10 個服務就會產生 10*n 個服務端點元信息，這種重複數據致使規模問題被放大。框架

另一點值得跟你們分享的是，目前阿里巴巴也正經歷着應用的 SDK 升級之痛，SDK 中包含了中間件和應用層的一些公共模塊，由中間件統一以 Pandora 包的形式交付給業務方使用。在應用數很是龐大的情形下，SDK 升級是一份至關繁重的工做，甚至涉及到集團層面的大協同。爲此，咱們但願經過 Service Mesh 先將中間件的那些能力下沉到 Sidecar，將這塊升級工做從 Pandora 中剝離出來，藉助 Service Mesh 的流量無損熱升級能力讓業務對中間件升級徹底無感。less

Service Mesh 面臨的挑戰

• Service Mesh 面臨的第一個挑戰就是新技術如何平滑演進；

Service Mesh 在大規模場景下的落地在業界的案例還至關 少，根源在於該技術自己尚未徹底成熟。在技術走向成熟的持續迭代過程當中，如何平滑演進是一個頗有挑戰的任務。挑戰在於須要以終爲始地規範技術架構的演進，一步一步地向終態架構演進。運維

• 第二個挑戰是發展的過程當中如何協調好技術和業務的平衡；

技術團隊但願快速迭代向前發展兌現價值，而業務團隊每一年有本身的業務目標，如何協調好二者的發展關係是個不小的挑戰。表明新技術的團隊其發展思路一般會更激進，而業務團隊會由於「穩定壓倒一切」而偏保守，短時間內調和好這一矛盾或許須要自頂向下的決策力量，不然業務挑戰年年有而可能擠壓技術的發展空間，致使技術發展緩慢而沒法更好地服務於業務的發展。異步

• 第三個挑戰是技術向前演進時如何處置歷史包袱；

每一次技術的演進都意味着對原有技術體系的升級，這就不可避免地須要處置過往累積下來的技術債。新技術發展的難點每每不在於其「新」，而在於包袱過重而致使新技術演進困難，極可能由於演進太慢而嚴重影響了新技術的發展。

• 第四個挑戰就是克服超大規模所帶來的問題；

前面講到的 Dubbo 由於是接口級服務發現，使得服務發現的數據規模很是大，給控制平面的端點數據推送能力帶去了巨大挑戰。

• 最後一個挑戰是 Sidecar 的規模化運維。

在超大規模場景下，大量的應用機器意味着有等量的 Sidecar 須要運維，如何在部署、灰度、升級以及保障安全生產是一個很大的挑戰。

新技術在架構上平滑演進是關鍵

新技術的不成熟極可能在至關長的一段時間內是常態，演進的關鍵在於如何實現新技術架構的平滑演進，避免出現推倒重來這種勞命傷財之事。爲此，基於這一考量，咱們一共經歷了「起步」、「三位一體」和「規模化落地」三大階段，而每個階段採用了不一樣的軟件架構或部署方案。

在起步階段，Istio 控制平面的 Pilot 組件放在一個單獨的容器中，同時看成一個獨立的進程和 Sidecar 部署在一個 Pod 裏。採用這樣的方式，使得對開源的 Envoy 和 Pilot 能夠作最小的改動而加速落地，也方便咱們基於開源的版本作能力加強和反哺。這一方案的缺點在於，每一個 Pod 中都包含了一個 Pilot 進程，增大了應用所在機器上的資源消耗，因在服務規模並不大的情形下資源消耗相對小而能夠忽視這一缺點。

在三位一體階段，Pilot 進程從業務 Pod 中抽離了出來變成了一個獨立的集羣，在 Sidecar 和 Pilot 之間還是 xDS 協議。這一架構雖節省了應用所在機器的資源消耗，但必須正視規模化落地的問題。xDS 中有一個叫 EDS（Endpoint Discovery Service）的協議，Pilot 經過 EDS 向 Sidecar 推送服務發現所需使用到的機器 IP（又被稱之爲 Endpoint）信息，在阿里的大規模場景下由於有大量的端點須要經過 Pilot 推送給 Sidecar，致使 Sidecar 的 CPU 消耗至關大，讓人擔憂業務進程由於 Sidecar 對資源的爭搶而受影響。這一規模化問題並不是在起步階段的技術方案中不存在，只不過由於那時落地應用的服務規模小而沒有成爲瓶頸。

爲了解決規模化落地的問題，咱們設計出了規模化落地的技術架構。

在這一架構中，雖然仍是 Sidecar 對接 Pilot 集羣，可是 Pilot 集羣只提供 xDS 中的 LDS/CDS/RDS 這些標準的服務，而 EDS 採用 Sidecar 直接對接服務註冊中心解決。值得強調，雖然Sidecar直接對服務接註冊中心，可是它仍然沿用了 Envoy 裏面對 EDS 所抽象的數據結構和服務模型，只是在數據的獲取上對接註冊中心來實現。之因此 Sidecar 直接對接服務註冊中心能解決走 EDS 所存在的規模化問題，根源在於阿里巴巴的服務註冊中心具有了增量推送的能力。

在這三種架構中，將來的終態必定是採用三位一體的架構，且數據平面和控制平面也必定是並重發展。因爲阿里巴巴今天的服務規模很是龐大而沒辦法一步到位作到三位一體。經過規模化落地這一過渡方案，仍然有助於咱們更好地反哺開源社區，經過儘早大規模落地會讓咱們清楚地知道開源方案仍存在的問題，從而讓咱們能爲開源方案的完善作出更大的貢獻。

業務與技術協同發展 —— 飛行中更換引擎

業務與技術的協同發展首先要回答好一個問題，即新技術帶給業務的價值是什麼。從業務的角度，採納新技術最開始考慮的必定是短時間價值，而後纔是放眼看長遠價值。

Service Mesh 對於業務所帶去的短時間價值是：

• 中間件能力下沉，下沉的過程當中去除歷史包袱輕裝上陣；
• 業務對中間件升級無感，中間件資源消耗可量化、優化可度量。

從長遠來看，徹底解決阿里巴巴面臨的 Pandora/SDK 升級之痛是須要至關長的一段時間，而 Service Mesh 在流量治理這塊的新價值也須要規模化落地達到必定水平後才能兌現，基礎技術對業務的價值須要具有長遠的眼光。Service Mesh 的長遠價值有：

• 業務與基礎技術全面解耦，業務更彙集於自身而加速創新，基礎技術獨立演進而加速迭代；
• 對微服務生態完成標準化、體系化的收口與治理，收斂故障和促進安全生產，加速應用功能正確性的驗證效率；
• 爲多種編程語言的應用提供微服務治理能力，完善並豐富雲原生多編程語言的應用生態；
• 共建全球事實標準，經過阿里雲的產品落實客戶 IT 設施的多雲和混合雲戰略，加速中國社會乃至全球的數字化轉型。

明確了技術的價值以後，業務與技術協同發展接下來的挑戰在於，須要技術演進的過程當中徹底不影響業務，這比如給一架高速運行的飛機換引擎。爲此，新技術的落地方案須要考慮對業務無侵入，換句話說規避業務應用新技術的改形成本。

爲了應用 mesh 化時對業務無感，在以 RPC 流量作 mesh 化爲切入點的背景下，咱們設計了動態流量無損透明攔截的技術方案。上圖示例說明了應用 mesh 化先後的三種狀態。在「過去」，流量是直接經過 RPC SDK 在 Provider 和 Consumer 之間互通的，SDK 直接跟中間件的服務註冊中心、配置中心對接。

到了「如今」，Service Mesh 直接被插入到了應用和中間件之間，SDK 不作任何的變化，但經過 iptables 將 SDK 的流量攔截到 Sidecar 中。因爲 iptables 是否開啓和關閉流量攔截是能夠經過運維控制檯從應用或機器維度進行控制的，這就使得在 mesh 技術自身出現問題的情形下能夠方便禁用，讓應用回退到經過 SDK 直連的方式互通。

面向「將來」，當 Service Mesh 技術徹底成熟時，SDK 須要從「胖」變「瘦」，那時並不須要 SDK 中存在下沉到 Sidecar 的那些能力，從而節約重複功能所致使的資源開銷。

下圖示例說明了打開和關閉流量透明攔截功能的關鍵流程。其中應用進程中包含了 RPC SDK 而沒有區分表達，Traffic Interceptor、Pilot Agent 和 Envoy 三個組件在同一個容器中，全部組件共享同一個 Pod。OneOps Core 是基於 K8s 所構建的中心化 mesh 運維 Operator，收到控制檯（圖中標識爲小人的 Operator 指代）調用開啓或關閉流量透明攔截的接口後，經過調用 Pilot Agent 所提供的接口完成對 Pod 中應用流量的操做。

爲了保證打開和關閉透明攔截功能時無業務流量的調用損失，請注意圖中紅色標識出的二大塊流程。開啓流量攔截時：Pilot Agent 將調用 RPC SDK 的 offline 接口（消息 2.1.1），間接完成從服務註冊中心對本機作去註冊摘除流量；而後調用 Traffic Interceptor 組件所提供的接口開啓流量攔截功能（消息 2.1.2）；最後再調用 RPC SDK 的 online 接口將本機註冊到服務註冊中心（消息 2.1.3）。

關閉流量攔截時：Pilot Agent 將調用 Envoy 的優雅關閉接口（消息 4.1.1），Envoy 會在 RPC SDK 與 Envoy 創建的鏈接上透傳這一消息（即 Envoy 會調用 RPC SDK 的優雅關閉接口，上圖並無表達出），告訴 RPC SDK 不要再向已創建的這一長鏈接上發送任何 RPC 請求；隨後 Pilot Agent 調用 Traffic Interceptor 接口關閉流量攔截功能（消息 4.1.2）；最後，Envoy 的優雅關閉接口被調用時會啓動一個延時 15 秒的定時器，確保 RPC SDK 與 Envoy 間已創建的長鏈接上尚未完成處理的請求有足夠的時間處理完以避免出現流量有損，當定時器到期後 Envoy 會主動關閉與 RPC SDK 所創建的鏈接（消息 6）。

爲了讓 mesh 技術自身的迭代對業務無感，咱們設計了流量無損熱升級方案，確保 Sidecar 能夠隨時對業務無感升級。設計流量無損熱升級方案的核心考量是投入產出比，以最小的工程成本構建一個容易作到穩定的技術方案，下圖示例了站在 Consumer 視角（即 Consumer 側的 Envoy 進行升級，Consumer 表明流量調用的發起方）所觀測到的熱升級流程。

當 Envoy 有一個新版本須要升級時（圖中標識爲 v2），經過運維控制檯能夠設置這個新版本的鏡像信息，經過 OpenKruise 的 SidecarSet 能夠拉到這一鏡像並將鏡像中的新版本 Envoy 二進制程序拉起。隨後，新版本 Envoy 會向老版本 Envoy（路中標識爲v1）發起熱升級流程。

熱升級大體包含以下幾個流程：老版本進程中全部的偵聽 fd 經過進程間通信的方式交給新版本進程（消息 5.1），由新版本進程繼續在之上進行偵聽（消息 5.1.1），換句話說，以後全部在這些被偵聽端口上新建的鏈接都會發生在新版本進程中；老版本進程調用 RPC SDK 的優雅關閉接口（消息 5.3），告訴 RPC SDK 不要再已創建的鏈接上發起新的調用，若是要發起新調用則必須從新創建鏈接，顯然新鏈接將與新版本進程創建，隨後的調用流量將所有進到新版本進程；老版本進程向 RPC SDK 發起優雅關閉接口調用的同時會創建一個時延 15 秒的定時器，確保與 RPC SDK 所創建的鏈接在這 15 秒中都處理完，定時器到期後關閉這一鏈接並退出老版本進程（消息 5.4），從而結束整個熱升級流程。

下圖是從 Provider 視角（即 Provider 側的 Envoy 進行升級，Provider 表明提供相應服務能力的被調用方）所觀察到的升級流程。不難看出，紅色標識出的部分與前一張圖是徹底同樣的，熱升級流程徹底無需基於 Envoy 的 Consumer 或 Provider 身份作特殊的處理。畢竟，現實中每一個應用大多會同時承擔 Consumer 和 Provider 兩種角色。

上圖有一個點值得特別指出，Envoy 須要實現序號爲 5.3 的優雅關閉消息，並將這一消息透傳給 RPC SDK（圖中並無表達）。

發展新技術是償還技術債的重要契機

很多新技術的出現多少會引起咱們的糾結，在新技術所創造的短時間價值不那麼有吸引力的情形下，彷佛舊技術不改變就不會帶來風險。但經驗代表，不改變的後果是包袱會越積越重，由此所帶來的技術債的潛在風險最終都不可忽視。

技術債是軟件的本質屬性，由於沒法作到已有架構能一直百分百優雅實現新需求。換句話說，技術債對於一個長期提供服務的軟件來講是一直存在的，只不過存在大小之別和什麼時候償還的問題。

阿里巴巴對分佈式系統的探索有超過十年的積累，爲了作應用的服務化改造提出了 HSF RPC 開發框架並將之開源爲 Dubbo。基於框架思惟所構建的 RPC 協議爲了更好地知足不一樣業務對服務路由的定製化訴求，提供了經過 Groovy 腳本進行定製的能力。然而，這種靈活的手段在向 Service Mesh 這一平臺技術演進時將帶來流量治理隱患。

咱們認爲，平臺思惟下構建的 Service Mesh 得限制過於靈活的定製能力，避免平臺出現「窟窿」而沒法有效、有力地完成全局最優的治理。爲此，咱們將去除 Groovy 腳本看成是一項技術債加以償還。Groovy 腳本帶來的問題主要有兩個：

• 過於靈活且致使了開發框架與應用代碼的耦合；
• 給流量治理能力下沉留下了潛在隱患。

爲了去除 Groovy 腳本，咱們擴展了 Istio 的 VirtualService 和 DestinationRule，抽象出按應用名、方法和參數路由的能力。下圖示例說明了某應用基於應用名作路由在 Groovy 腳本和 Service Mesh 下的具體實現。

因爲單個應用的 Service Mesh 化並不是一刀切的一次性完成，存在一個應用的部分機器先 mesh 化作灰度的場景。爲此，須要在去 Groovy 腳本這件事上，讓新舊技術方案能同時無縫工做，背後是兩種形式的路由表達如何作好同步，背後就涉及控制檯收口和格式轉化等問題須要妥善解決。

系統性解決超大規模問題

爲了最終解決阿里巴巴在 Service Mesh 落地過程當中所面臨的大規模問題，咱們從三個方面着手：

• Service Mesh 技術自身的持續優化：須要從 CPU 開銷、內存佔用和時延三大維度進行持續優化，經過軟硬件結合等技術手段作到應用 Service Mesh 化先後零新增成本甚至降低；
• Dubbo 實現應用級服務發現而非接口級：經過應用級服務發現將使得控制平面向數據平面推送的服務元數據有數量級降低，讓 Service Mesh 的控制平面向數據平面推送的數據急劇降低。
• 服務註冊數據進行單元封閉並分級治理：動機依然是下降 Service Mesh 控制平面向數據平面推送的數據量，經過單元封閉讓全局服務元數據經過局部化而減小。

這三方面在阿里巴巴分別有相應的團隊在探索解決，這裏主要分享 Service Mesh 技術自己。阿里巴巴對 Service Mesh 技術的探索策略是「借力開源，反哺開源」。

• 「借力」體現於總體技術方案採納的是開源的 Istio（控制平面） + Envoy（數據平面），在工程實踐中特別注意自有代碼與開源代碼作充分的解耦，以及頻繁跟進開源社區發佈的新版本；
• 「反哺」表如今咱們積極將性能優化、bugfix 等代碼提交給開源社區。

至今，在 Istio 開源社區咱們提交了 9 個 PR，解決性能問題和 bugfix；在 Envoy 開源社區咱們提交了 14 個 PR，包含內存開銷降低 50% 的優化、新增對 Dubbo 和 RocketMQ 協議的支持等內容。此外，咱們曾與 Istio 社區共同探索實現了 EGDS (Endpoint Group Discovery Service），做爲 EDS 的加強，但因爲 Envoy 社區擔憂該 feature 通用性不足而最終沒能接受而完成此次反哺。這一「失敗」不僅體現了咱們反哺社區的意願和熱情，也是更好融入開源社區的一次很好的學習機會。

在 EGDS 並不能很好解決在「三位一體」方案下的大規模落地問題的情形下，咱們從新調整了落地方案，造成了本文前面所講到的讓 Envoy 直接對接服務註冊中心的「規模化落地」方案。下圖展現了兩個方案的 CPU 開銷數據比較。

圖中深藍色表明的是規模化落地方案，橙色表明的是三位一體的方案，測試數據代表三位一體方案在設定的越大規模壓測場景下因服務元數據推送給 Envoy 所帶去的 CPU 開銷是規模化落地方案的三倍。

進一步地，咱們比對了非 mesh 方案和規模化落地 mesh 方案因服務元數據推送所致使的 CPU 開銷（以下圖所示）。數據代表，非 mesh 方案（圖中橙色表示）因 Java 進程在數據推送場景下存在 GC 而使得 CPU 開銷要顯著地高於規模化落地 mesh 方案（圖中深藍色表示），這是因 Envoy 採用 C++ 編程語言而得到的優點。

後續咱們會考慮參與共建 Envoy 社區所提出的 LEDS 協議，讓 Istio + Envoy 的三位一體方案自然地能運用於阿里巴巴的大規模場景。

除了 CPU 開銷的優化，咱們在內存優化方面也取得了巨大的進展。一樣服務規模的情形下，Envoy 的內存開銷從以前超過 3G 優化至 500M 左右。此外，壓測數據代表應用 mesh 化完成後總體內存開銷比 mesh 化前更低。

Sidecar 的規模化運維

Sidecar 的規模化運維也是很具挑戰的一件事，內容包含 Sidecar 的部署、灰度、升級，以及須要構建相應的監控和報警設施。

Sidecar 的部署、灰度、升級咱們全面基於由阿里巴巴開源的 OpenKruise 中的 SidecarSet 實現。SidecarSet 提供了對 Sidecar 進行部署、灰度和升級的通用能力，能很好地運用於 Service Mesh 而省去了重複建設。

固然，流量無損熱升級這樣的能力並不是 SidecarSet 原生提供的，須要從 Service Mesh 層面去加強。在 Sidecar 的運維和流量治理這塊，監控和報警全面採用了阿里雲上的 Prometheus 和 ARMS 兩大雲產品，一旦當下服務於阿里巴巴內部的 Service Mesh 技術未來要經過產品化輸送給阿里雲上的客戶時會更加方便。

在運維管控上，咱們全新構建了雲原生 OneOps 運維繫統。OneOps 包含控制檯和 OneOps Core 兩大子系統。後者是基於 K8s 構建的運維 Operator，經過 CRD 的形式暴露給控制檯調用接口。OneOps Core 能夠多區域部署，而控制檯是全局集中部署的，這樣方便運維人員在同一個控制檯上能無縫地管理多個區域的 Service Mesh。目前 OneOps 已具有管理包含了 Sidecar 和 Ingress Gateway在內的東西南北向流量的能力。

總結

本文總結了阿里巴巴大規模落地 Service Mesh 所面臨並克服的技術挑戰，但願這些內容對行業同仁在這一技術的探索和學習有所幫助。現階段，阿里巴巴對於 Service Mesh 的探索更多停留於解決歷史包袱和完成應用與中間件的解耦，仍沒有在服務流量治理方面作出新價值和新體驗，期待將來能儘早給你們分享這方面的內容。

Service Mesh 是雲原生的關鍵技術，對於阿里巴巴來講，咱們篤定這是分佈式應用微服務軟件架構的將來。正因如此，CTO 魯肅也站臺 Service Mesh 技術，並作出了將來整個經濟體全面走 Istio + Envoy 方案的技術決策。在構建阿里巴巴全球商業操做系統的道路上，Service Mesh 是面向將來五年、甚至十年的技術。

期待更多對分佈式應用相關技術挑戰有熱情的志同道合之士加入共建與共創，在創變的道路上咱們共同成長、共同收穫。若是您有意向，請將簡歷發送至 zhijian.ly@alibaba-inc.com，咱們在深圳、上海和杭州都有 Service Mesh 的職位長期開放。

另外，業界首個兼容 Istio 全託管雲產品的阿里雲服務網格（ASM）已對外發布，可免費體驗：https://servicemesh.console.aliyun.com/

課程推薦

去年，CNCF 與 阿里雲聯合發佈了《雲原生技術公開課》已經成爲了 Kubernetes 開發者的一門「必修課」。

今天，阿里雲再次集結多位具備豐富雲原生實踐經驗的技術專家，正式推出《雲原生技術實踐公開課》。課程內容由淺入深，專一講解「 落地實踐」。還爲學習者打造了真實、可操做的實驗場景，方便驗證學習成果，也爲以後的實踐應用打下堅實基礎。點擊連接查看課程：https://developer.aliyun.com/learning/roadmap/cloudnative2020

「 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」