![1.png](https://ucc.alicdn.com/pic/developer-ecology/0c0714b471f34168b048a7ebcb6d8077.png)

作者 | 至簡  阿里雲高階技術專家

隨著微服務軟體架構在網際網路企業的廣泛實踐，新一代微服務軟體架構技術悄然興起，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 的流量無損熱升級能力讓業務對中介軟體升級完全無感。

# Service Mesh 面臨的挑戰

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

Service Mesh 在大規模場景下的落地在業界的案例還相當 少，根源在於該技術本身還沒有完全成熟。在技術走向成熟的持續迭代過程中，如何平滑演進是一個很有挑戰的任務。挑戰在於需要以終為始地規範技術架構的演進，一步一步地向終態架構演進。

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

技術團隊希望快速迭代向前發展兌現價值，而業務團隊每年有自己的業務目標，如何協調好兩者的發展關係是個不小的挑戰。代表新技術的團隊其發展思路通常會更激進，而業務團隊會因為“穩定壓倒一切”而偏保守，短期內調和好這一矛盾或許需要自頂向下的決策力量，否則業務挑戰年年有而可能擠壓技術的發展空間，導致技術發展緩慢而無法更好地服務於業務的發展。

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

每一次技術的演進都意味著對原有技術體系的升級，這就不可避免地需要處置過往累積下來的技術債。新技術發展的難點往往不在於其“新”，而在於包袱太重而導致新技術演進困難，很可能因為演進太慢而嚴重影響了新技術的發展。

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

前面講到的 Dubbo 因為是介面級服務發現，使得服務發現的資料規模非常大，給控制平面的端點資料推送能力帶去了巨大挑戰。

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

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

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

![2.png](https://ucc.alicdn.com/pic/developer-ecology/3279bda1a96b44f29a1da12c97268ebe.png)

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

在起步階段，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 設施的多雲和混合雲戰略，加速中國社會乃至全球的數字化轉型。

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

![3.png](https://ucc.alicdn.com/pic/developer-ecology/ab2ab6ea16e541a8b36c2e1a335ccb32.png)

為了應用 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 中應用流量的操作。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/79cac7408b3243098e82935dcae1d0b1.png)

為了保證開啟和關閉透明攔截功能時無業務流量的呼叫損失，請注意圖中紅色標識出的二大塊流程。開啟流量攔截時：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）發起熱升級流程。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/56547a49015d42c496c0bc884d43f327.png)

熱升級大致包含如下幾個流程：老版本程式中所有的偵聽 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 兩種角色。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/36a0171f77894c2c96b41b3a51bd4b07.png)

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

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

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

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

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

我們認為，平臺思維下構建的 Service Mesh 得限制過於靈活的定製能力，避免平臺出現“窟窿”而無法有效、有力地完成全域性最優的治理。為此，我們將去除 Groovy 指令碼當作是一項技術債加以償還。Groovy 指令碼帶來的問題主要有兩個：

- 過於靈活且導致了開發框架與應用程式碼的耦合；

- 給流量治理能力下沉留下了潛在隱患。

為了去除 Groovy 指令碼，我們擴充套件了 Istio 的 VirtualService 和 DestinationRule，抽象出按應用名、方法和引數路由的能力。下圖示例說明了某應用基於應用名做路由在 Groovy 指令碼和 Service Mesh 下的具體實現。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/db54235cdcf9422bb8127f3a2cbe12f4.png)

由於單個應用的 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 開銷資料比較。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/68c2f108b1a540b5b5a3ca2f817e1d05.png)

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

進一步地，我們比對了非 mesh 方案和規模化落地 mesh 方案因服務後設資料推送所導致的 CPU 開銷（如下圖所示）。資料表明，非 mesh 方案（圖中橙色表示）因 Java 程式在資料推送場景下存在 GC 而使得 CPU 開銷要顯著地高於規模化落地 mesh 方案（圖中深藍色表示），這是因 Envoy 採用 C++ 程式語言而獲得的優勢。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/71232033b8ae4f658696520ca10704d1.png)

後續我們會考慮參與共建 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/](https://servicemesh.console.aliyun.com/)**

### 課程推薦

去年，CNCF 與 阿里雲聯合釋出了《雲原生技術公開課》已經成為了 Kubernetes 開發者的一門“必修課”。

今天，阿里雲再次集結多位具有豐富雲原生實踐經驗的技術專家，正式推出《雲原生技術實踐公開課》。課程內容由淺入深，專注講解“ 落地實踐”。還為學習者打造了真實、可操作的實驗場景，方便驗證學習成果，也為之後的實踐應用打下堅實基礎。點選連結檢視課程：[https://developer.aliyun.com/learning/roadmap/cloudnative2020](https://developer.aliyun.com/learning/roadmap/cloudnative2020)

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247494609&idx=1&sn=1e97a4e008a5180099f8260bb67c6dfb&chksm=fae6e01ecd91690847a57877f8f14774d833b882536f64d8ecb97221c0e4013a300677481c12&token=2047413486&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

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

相關文章