阿里巴巴 Service Mesh 落地的架構與挑戰

點擊下載《不同的 雙11 技術：阿里巴巴經濟體雲原生實踐》 本文節選自《不同的 雙11 技術：阿里巴巴經濟體雲原生實踐》一書，點擊上方圖片便可下載！

做者 | 方克明（溪翁）阿里雲中間件技術部技術專家

導讀：雲原生已成爲整個阿里巴巴經濟體構建面向將來的技術基礎設施，Service Mesh 做爲雲原生的關鍵技術之一，順利完成在 雙11 核心應用嚴苛而複雜場景下的落地驗證。本文做者將與你們分享在完成這一目標過程當中咱們所面臨和克服的挑戰。

部署架構

切入主題前，須要交代一下在 雙11 核心應用上落地的部署架構，以下圖所示。在這篇文章中，咱們主要聚焦於 Service A 和 Service B 之間 RPC 協議的 Mesh 化。

圖中示例說明了 Service Mesh 所包含的三大平面：即數據平面（Data Plane）、控制平面（Control Plane）和運維平面（Operation Plane）。數據平面咱們採用的是開源的 Envoy（上圖中的 Sidecar，請讀者注意這兩個詞在本文中能夠互換使用），控制平面採用的是開源的 Istio（目前只使用了其中的 Pilot 組件），運維平面則徹底自研。

與半年前落地時不一樣，此次 雙11 核心應用上落地咱們採用了 Pilot 集羣化部署的模式，即 Pilot 再也不與 Envoy 一塊兒部署到業務容器中，而是搭建了一個獨立的集羣。這一變化使得控制平面的部署方式演進到了 Service Mesh 應有的終態。

挑戰

落地所選擇的 雙11 核心應用都是採用 Java 編程語言實現的，在落地的過程當中咱們面臨瞭如下挑戰。

1. 在 SDK 沒法升級的情形下如何實現應用的 Mesh 化

在決定要在 雙11 的核心應用上落地 Mesh 時，Java 應用依賴的 RPC SDK 版本已經定稿，爲了 Mesh 化徹底沒有時間去開發一個適用於 Mesh 的 RPC SDK 並作升級。那時，擺在團隊面前的技術問題是：如何在不升級 SDK 的情形下，實現 RPC 協議的 Mesh 化？

熟悉 Istio 的讀者想必清楚，Istio 是經過 iptables 的 NAT 表去作流量透明攔截的，經過流量透明攔截可在應用無感的情形下將流量劫持到 Envoy 中從而實現 Mesh 化。但很不幸，NAT 表所使用到的 nf_contrack 內核模塊由於效率很低，在阿里巴巴的線上生產機器中被去除了，所以沒法直接使用社區的方案。好在年初開始不久咱們與阿里巴巴 OS 團隊達成了合做共建，由他們負責承擔 Service Mesh 所需的流量透明攔截和網絡加速這兩塊基礎能力的建設。通過兩個團隊的緊密合做，OS 團隊探索了經過基於 userid 和 mark 標識流量的透明攔截方案，基於 iptables 的 mangle 表實現了一個全新的透明攔截組件。

下圖示例說明了存在透明攔截組件的情形下，RPC 服務調用的流量走向。其中，Inbound 流量是指調進來的流量（流量的接受者是 Provider 角色），而 Outbound 是指調出去的流量（流量的發出者是 Consumer 角色）。一般一個應用會同時承擔兩個角色，因此有 Inbound 和 Outbound 兩股流量並存。

有了透明攔截組件以後，應用的 Mesh 化徹底能作到無感，這將極大地改善 Mesh 落地的便利性。固然，因爲 RPC 的 SDK 仍存在之前的服務發現和路由邏輯，而該流量被劫持到 Envoy 以後又會再作一次，這將致使 Outbound 的流量會由於存在兩次服務發現和路由而增長 RT，這在後面的數據部分也將有所體現。顯然，以終態落地 Service Mesh 時，須要去除 RPC SDK 中的服務發現與路由邏輯，將相應的 CPU 和內存開銷給節約下來。

2.短期內支持電商業務複雜的服務治理功能

路由

在阿里巴巴電商業務場景下的路由特性豐富多樣，除了要支持單元化、環境隔離等路由策略，還得根據 RPC 請求的方法名、調用參數、應用名等完成服務路由。阿里巴巴內部的 Java RPC 框架是經過嵌入 Groovy 腳原本支持這些路由策略的，業務方在運維控制檯上配置 Groovy 路由模板，SDK 發起調用時會執行該腳本完成路由策略的運用。

將來的 Service Mesh 並不打算提供 Groovy 腳本那麼靈活的路由策略定製方案，避免由於過於靈活而給 Service Mesh 自身的演進帶去掣肘。所以，咱們決定借 Mesh 化的機會去除 Groovy 腳本。經過落地應用所使用 Groovy 腳本的場景分析，咱們抽象出了一套符合雲原生的解決方案：擴展 Istio 原生的 CRD 中的 VirtualService 和 DestinationRule，增長 RPC 協議所需的路由配置段去表達路由策略。

目前阿里巴巴環境下的單元化、環境隔離等策略都是在 Istio/Envoy 的標準路由模塊內作了定製開發，不可避免地存在一些 hack 邏輯。將來計劃在 Istio/Envoy 的標準路由策略以外，設計一套基於 Wasm 的路由插件方案，讓那些簡單的路由策略以插件的形式存在。如此一來，既減小了對標準路由模塊的侵入，也在必定程度上知足了業務方對服務路由定製的須要。設想的架構以下圖所示：

限流

出於性能考慮，阿里巴巴內部落地的 Service Mesh 方案並無採用 Istio 中的 Mixer 組件，限流這塊功能借助阿里巴巴內部普遍使用的 Sentinel 組件來實現，不只能夠與已經開源的 Sentinel 造成協力，還能夠減小阿里巴巴內部用戶的遷移成本（直接兼容業務的現有配置來限流）。爲了方便 Mesh 集成，內部多個團隊合做開發了 Sentinel 的 C++版本，整個限流的功能是經過 Envoy 的 Filter 機制來實現的，咱們在 Dubbo 協議之上構建了相應的 Filter（Envoy 中的術語，表明處理請求的一個獨立功能模塊），每一個請求都會通過 Sentinel Filter 作處理。限流所需的配置信息則是經過 Pilot 從 Nacos 中獲取，並經過 xDS 協議下發到 Envoy 中。

3. Envoy 的資源開銷過大

Envoy 誕生之初要解決的一個核心問題就是服務的可觀測性，所以 Envoy 一開始就內置了大量的 stats（即統計信息），以便更好地對服務進行觀測。

Envoy 的 stats 粒度很細，甚至細到整個集羣的 IP 級別，在阿里巴巴環境下，某些電商應用的 Consumer 和 Provider 服務加起來達到了幾十萬之多的 IP（每一個 IP 在不一樣的服務下攜帶的元信息不一樣，因此不一樣的服務下的相同 IP 是各自獨立的）。如此一來，Envoy 在這塊的內存開銷甚是巨大。爲此，咱們給 Envoy 增長了 stats 開關，用於關閉或打開 IP 級別的 stats，關閉 IP 級別的 stats 直接帶來了內存節約 30% 成果。下一步咱們將跟進社區的 stats symbol table 的方案來解決 stats 指標字符串重複的問題，那時的內存開銷將進一步減小。

4. 解耦業務與基礎設施，實現基礎設施升級對業務無感

Service Mesh 落地的一項核心價值就是讓基礎設施與業務邏輯徹底解耦，二者能夠獨立演進。爲了實現這個核心價值，Sidecar 須要具有熱升級能力，以便升級時不會形成業務流量中斷，這對方案設計和技術實現的挑戰仍是蠻大的。

咱們的熱升級採用雙進程方案，先拉起新的 Sidecar 容器，由它與舊的 Sidecar 進行運行時數據交接，在新的 Sidecar 準備發接管流量後，讓舊的 Sidecar 等待必定時間後退出，最終實現業務流量無損。核心技術主要是運用了 Unix Domain Socket 和 RPC 的節點優雅下線功能。下圖大體示例了關鍵過程。

數據表現

公佈性能數據一不當心就會引起爭議和誤解，由於性能數據的場景存在不少變量。好比，併發度、QPS、payload 大小等對最終的數據表現將產生關鍵影響。也正因如此，Envoy 官方歷來沒有提供過本文所列出的這些數據，背後的緣由正是其做者 Matt Klein 擔憂引起誤解。值得強調的是，在時間很是緊迫的情形下，咱們所落地的 Service Mesh 並不是處於最優狀態，甚至不是最終方案（好比 Consumer 側存在兩次路由的問題）。咱們之因此選擇分享出來，是但願讓更多的同行瞭解咱們的進展和狀態。

本文只列出了 雙11 所上線核心應用中某一個的數據。從單機 RT 抽樣的角度，部署了 Service Mesh 的某臺機器，其 Provider 側的 RT 均值是 5.6ms，Consumer 側的是 10.36ms。該機器在 雙11 零點附近的 RT 表現以下圖所示：

沒有部署 Service Mesh 的某臺機器，Provider 側的均值爲 5.34ms，Consumer 側的則是 9.31ms。下圖示例了該機器在 雙11 零點附件的 RT 表現。

相比之下，Provider 側的 RT 在 Mesh 化先後增長了 0.26ms，Consumer 側則增長了 1.05ms。注意，這個 RT 差是包含了業務應用到 Sidecar，以及 Sidecar 處理的全部時間在內的，下圖示例說明了帶來時延增長的鏈路。

總體上，該核心應用全部上線了 Service Mesh 的機器和沒有上線 Service Mesh 的機器在某個時間段的總體均值數據作了對比。Provider 側 Mesh 化後的 RT 增長了 0.52ms，而 Consumer 側增長了 1.63ms。

在 CPU 和內存開銷方面，Mesh 化以後，Envoy 所消耗的 CPU 在全部核心應用上都維持在 0.1 核左右，會隨着 Pilot 推送數據而產生毛刺。將來須要藉助 Pilot 和 Envoy 之間的增量推送去對毛刺作優化。內存的開銷隨着應用的服務和集羣規模不一樣而存在巨大差別，目前看來 Envoy 在內存的使用上仍存在很大的優化空間。

從全部雙11 上線的核心應用的數據表現來看，Service Mesh 的引入對於 RT 的影響和帶來的 CPU 開銷是基本同樣的，而內存開銷則由於依賴服務和集羣規模的不一樣而有至關大的差別。

展望

在雲原生的浪潮下，阿里巴巴借這波技術浪潮致力於打造面向將來的技術基礎設施。在發展的道路上將貫徹「借力開源，反哺開源」的發展思路，經過開源實現技術普惠，爲將來的雲原生技術在更大範圍的普及作出本身的貢獻。

接下來，咱們的總體技術着力點在於：

• 與 Istio 開源社區共同加強 Pilot 的數據推送能力。在阿里巴巴具有 雙11 這種超大規模的應用場景下，咱們對於Pilot 的數據推送能力有着極致的要求，相信在追求極致的過程當中，能與開源社區一道加速全球事實標準的共建。從阿里巴巴內部來看，咱們目前拉通了與 Nacos 團隊的共建，將經過社區的 MCP 協議與 Nacos 對接，讓阿里巴巴所開源的各類技術組件能體系化地協同工做；

• 以 Istio 和 Envoy 爲一體，進一步優化二者的協議以及各自的管理數據結構，經過更加精煉、更加合理的數據結構去減小各自的內存開銷；

• 着力解決大規模 Sidecar 的運維能力建設。讓 Sidecar 的升級作到可灰度、可監控和可回滾；

• 兌現 Service Mesh 的價值，讓業務與技術設施能以更高的效率彼此獨立演進。

本書亮點

• 雙11 超大規模 K8s 集羣實踐中，遇到的問題及解決方法詳述
• 雲原生化最佳組合：Kubernetes+容器+神龍，實現核心系統 100% 上雲的技術細節
• 雙 11 Service Mesh 超大規模落地解決方案

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