網易嚴選ServiceMesh實踐

​

本文做者：國雲（網易嚴選中臺技術團隊負責人，容器化負責人）

2008年加入網易，長期從事一線的研發與管理工做，擅長技術架構及技術體系建設，曾參與或負責過網易博客、網易郵箱、網易有錢等多個核心產品的研發工做，現任嚴選中臺技術團隊負責人，負責嚴選的容器化及Service Mesh演進。

背景

Service Mesh在嚴選的探索與實踐大體分了如下幾個階段：

第一個階段：探索期（2015年末~2016年4月）

網易嚴選從2015年末開始內部孵化到2016年4月正式面世，這個階段嚴選的技術團隊規模很是小，差很少10人左右，核心業務採用的是單體架構，同時會依賴少許業務基礎服務，如推送服務、文件存儲服務、消息中心等等。

在這個時期，若是咱們將視野擴大到孵化嚴選的網易郵件事業部，當時採用的主流架構是面向服務的架構(SOA)，但實現上並不統一，有使用中心化的ESB技術提供的服務、也有使用去中心化的Spring Cloud框架提供的服務。

無論是ESB仍是以Spring Cloud爲表明的分佈式服務框架，都有一些典型的問題須要解決，而嚴選做爲一個現象級的電商產品，其能夠預見的業務複雜度使得咱們不得不重視此次關鍵的選型，稍有不慎，就有可能會帶來很是大的技術負債。

此次基礎架構選型過程當中，咱們主要從三個維度進行了思考：

• ****服務治理：****RPC框架 vs 服務治理平臺

  經過RPC框架提供服務治理能力仍是將服務治理能力平臺化？
  經過框架將服務治理能力集成到業務在當時還是主流，但從內外部諸多的實踐結果來看，這種思路扔須要解決大量的問題，其中尤其顯著是框架升級問題，業務團隊和中間件團隊訴求不一樣，每每推進起來費時費力，一方面影響業務的迭代節奏甚至業務服務質量，另外一方面也嚴重製約中間件的演進效率。

• ****服務治理：****RPC框架 vs 服務治理平臺

  服務治理能力建設是否應該考慮非Java技術棧？
  嚴選核心業務採用的是Java技術棧，但仍然存在很多非Java的應用系統，好比使用Python技術棧的推薦服務、使用C++技術棧的接入服務以及大量的NodeJS應用，相對而言，Java技術棧的生態更爲豐富，若是要拉齊各語言棧的服務治理能力，須要投入大量的研發成本，若是不投入，這些語言棧的服務治理短板將來頗有可能成爲整個系統的短板。

• 開源 vs 自研

  無論採用哪一種基礎架構，都須要問兩個問題：
  1）是從0開始建設仍是基於成熟的開源項目進行擴展？
  2）若是從0開始建設，是否屬於重複造輪子？能額外外社區爲公司帶來哪些價值？

第二個階段：小規模試驗期（2016年4月~2017年初）

2016年7月份，咱們發佈了第一代Service Mesh架構，並陸續在網易郵箱、網易有錢以及網易嚴選的部分業務進行試點，得到了不錯的落地效果，也積累了寶貴的運維經驗，同時管控平臺也基本成型。

第三個階段：全面落地期

伴隨着嚴選業務規模的不斷增加，業務的複雜度不斷提高，團隊規模也迅速增加，從最初的10餘人，到2016年增加到了50人，到2017年迅速突破200人。

從2017年初開始，嚴選第一代Service Mesh架構在嚴選逐步鋪開並最終全面落地。2019年，基於容器雲的網易輕舟微服務平臺逐漸成熟，嚴選也正式啓動雲化戰略，Service Mesh架構做爲應用系統雲化的核心技術，也進入了全面升級階段。

今天爲你們帶來的分享主要包括三個部分：

• 嚴選Service Mesh架構演進

• 混合雲架構落地實踐

• 規劃與展望

嚴選Service Mesh演進

嚴選第一代Service Mesh架構

嚴選的第一代Service Mesh架構是基於Consul和Nginx進行擴展：

• Consul

  一種基於服務的網絡解決方案
  提供了服務發現、服務註冊、服務路由等基本服務治理能力

• Nginx

  一種高性能反向代理服務器，具有負載均衡、限流、容錯等特性
  具有良好的擴展性

因爲Consul和Nginx自帶的特性基本能知足咱們的服務治理需求，所以，咱們的主要工做是將Consul和Nginx融合成一個Local Proxy（代號：cNginx），同時開發一個管控平臺將這些能力提供出去。

來看下總體架構：

​

• 數據面

  cNginx與Consul Client組成咱們的Sidecar, 使用Client Sidecar模式

• 控制面

  控制面咱們提供了服務註冊/發現、調用控制、治理控制這三大塊能力

服務治理能力

從功能視角來看，Service Mesh架構爲咱們提供了服務註冊/發現、健康檢查、路由控制、負載均衡、故障轉移、服務調用方限流、超時控制、重試等基本的服務治理能力，其餘的服務治理能力如訪問控制、資源隔離、監控及故障診斷則經過中間件或日誌平臺完成（以下圖所示）。

​

服務治理能力的完善過程也反應了嚴選現階段技術平臺建設的核心思路：由點帶面，小步快跑，完善能力矩陣。

Service Mesh爲嚴選帶來的架構收益

那麼Service Mesh架構的實踐與落地爲嚴選帶來了哪些架構收益，相信也是你們比較關心的問題。

首先是解決了嚴選的歷史包袱，Service Mesh架構使現有的服務能夠在不改造的狀況下引入了服務治理能力

嚴選在2016年推出後業務和團隊規模增加都很是快，技術基建出現明顯的滯後，這也形成了一個局面：

• 因爲嚴選技術團隊內部沒有徹底融合，技術棧選擇上會有明顯的差別

• 同時，每一個技術團隊對服務治理能力的理解也是不一致的，一方面形成了服務質量良莠不齊，另外一方面也致使了一些重複造輪子的狀況，無形中加大了技術團隊橫向協做的成本

而Service Mesh做爲一個基礎設施層，能夠處理並管理服務間的通訊，這種對應用無侵入的特性，使落地過程以及後續的升級過程都無需業務研發團隊對服務進行改造，極大的下降了落地阻力，釋放了研發團隊的生產力。

其次，大大下降了中間件的研發投入和演進成本，也下降了業務和中間件的耦合成本

因爲嚴選採用了Service Mesh架構，不少依賴傳統中間件（如RPC框架）的服務治理能力從業務中解耦出來，下沉到Sidecar中，從而使中間件變得更加「輕量」。

因爲這種能力的下沉，業務須要依賴的中間件的數量及重量都大大下降：

• 對基礎技術研發團隊來說，大大下降了中間件的研發投入和演進成本

• 對業務研發團隊來說，也無需把大量的精力投入到中間件的學習與使用，下降了業務和中間件的耦合成本

再次，基礎架構與業務架構能夠獨立演進

在中間件大行其道時，令基礎技術研發團隊比較頭疼的事情是推進中間件的持續演進，每每一次很小的迭代，即便基礎技術研發團隊認爲通過充分的測試，要推進業務研發團隊升級也須要投入極大的心力與體力，同時消耗大量的開發和測試資源，這種與演進價值不對等的投入致使了中間件演進速度慢、效果差、歷史包袱愈來愈重。

Service Mesh架構能夠很完美的解決這個痛點，使應用與基礎設施層解耦開來，帶來巨大的工程價值：

• 使業務研發團隊能夠專一於業務領域與業務架構自己

• 使基礎技術研發團隊也能夠專一於技術領域，因爲Service Mesh架構與應用自然隔離，其演進價值更容易被量化，而有了量化數據的支撐，基礎架構的演進速度纔會更快、演進效果也會更好

最後，Service Mesh架構爲多語言棧提供了服務治理能力

Service Mesh架構出現以前，因爲相同的語言棧有明顯的協同優點，這顯然會致使研發團隊在選擇語言棧時會有所顧慮，甚至不是按照適用的場景選擇語言，好比初創團隊一開始選擇使用了Java、PHP、Golang，通常後續大部分項目都會採用相同的語言，但每種編程語言都有本身的優點和適用場景，隨着業務規模的擴大、業務場景的豐富或者多團隊業務的整合，就會出現多語言棧的協同與服務治理問題。

Service Mesh架構自然能夠解決多語言棧的問題，使得非Java語言棧，尤爲是新興的語言，優點更容易被挖掘，技術生態的劣勢不至於被放大。

持續演進的訴求

雖然嚴選第一代Service Mesh架構爲嚴選帶來了很是大的工程價值和架構收益，但仍不完美，須要持續演進。

一方面，咱們須要更豐富和更高質量的服務治理能力，好比：

• 加強流量管理能力，好比流量染色、分流控制等

• 將更多治理特性（如限流、熔斷、故障注入）與業務架構解耦

• 支持更多的協議

• 加強控制面能力

另外一方面，咱們也須要支持應用系統全面雲化戰略以及混合雲或多雲架構。

行業技術演進——通用型Service Mesh出現

在嚴選實踐Service Mesh架構的時候，咱們注意到，伴隨着雲原生浪潮和微服務浪潮，通用型Service Mesh開始出現。

2016年9月29日，Service Mesh的概念被第一次公開提出，這要感謝Linkerd的CEO William及Buoyant公司，他們提出並定義了Service Mesh，並將Service Mesh的第一個開源項目Linkerd貢獻給了CNCF。
這以後出現了多個開源項目，比較知名的如Lyft公司的Envoy和Nginx的nginmesh，其中Envoy在2017年9月也加入了CNCF。

早期的Service Mesh主要聚焦在數據面能力，同時附帶簡單的控制面，與沉澱多年的中間件相比並無明顯的功能優點與性能優點（甚至性能上還有劣勢），所以在業內並無引發太大的反響。但這一切，隨着Istio的出現發生了扭轉，Istio爲Service Mesh帶來了史無前例的控制力，並迅速成爲了Service Mesh領域的事實標準，Linkerd、Envoy、nginmesh都已經主動擁抱了Istio。咱們的輕舟微服務團隊也迅速跟進了Istio和Envoy，成爲社區的早期參與者之一。

雲原生Service Mesh框架——Istio

Istio由Google，IBM和Lyft聯合開發，與 Kubernetes 一脈相承且深度融合：

• Kubernetes 提供了部署、升級和有限的運行流量管理能力

• Istio 補齊了 Kubernetes 在微服務治理能力上的短板（如限流、熔斷、降級、分流等）

• Istio 以 Sidecar 的形式運行在 Pod 中，自動注入，自動接管流量，部署過程對業務透明

Istio提供了完整的Service Mesh解決方案：

• 數據面

  • 數據面支持多種協議（如HTTP 1.X/2.X，GRPC等），控制服務全部進出流量，同時負責控制面制定的策略執行，並上報遙感數據

  • Istio默認的Sidecar是Envoy，它是基於C++開發的L4/L7高性能代理（對標NGINX）

  • 具備強大的流量管理能力、治理能力與擴展能力

• 控制面

  • Pilot：提供服務發現與抽象能力，負責配置轉換與分發（如動態路由等）

  • Mixer：訪問控制、接收遙感數據等

  • Citadel：提供安全證書與祕鑰的下發和管理能力。

  • Galley：提供配置校驗能力

​

接下來咱們將從功能和性能兩個視角來看下基於Istio的Service Mesh解決方案。

功能視角——服務治理能力（基於Istio+Envoy）

從功能視角來看，相比於嚴選第一代Service Mesh架構，在流量管理能力方面（如流量染色、路由控制、流量複製等）有明顯的加強，在治理控制方面的能力也更爲豐富，提供瞭如熔斷降級、資源隔離、故障注入等能力，在訪問控制方面也提供了更多選擇。

​

性能視角——cNginx vs Envoy（優化前）

在Service Mesh架構實踐和落地過程當中，你們最關心的問題是性能問題，Service Mesh架構雖然解決了不少基礎架構的痛點，但相比於原來的一次遠程調用，會額外增長1~2跳，直覺告訴咱們這會帶來額外的延時。

根據咱們的壓測數據，主機配置爲8C16G（嚴選應用服務器的規格，與cNginx共享），在40併發、1600RPS的狀況下，與直連相比，cNginx的延時增長0.4ms（相比直連），Envoy（社區版本，優化前）Client Sidecar模式延時增長0.6ms（相比直連）。

cNginx和Envoy Client模式對性能的影響都比較小，在可接受範圍以內。另外，傳統的帶服務治理能力的中間件（如Spring Cloud/Dubbo等）一樣會帶來性能開銷和資源開銷，所以，實際的性能影響其實更小（從前面螞蟻和酷家樂分享的性能數據來看，Sidecar模式與SDK模式相比，螞蟻應用場景的平均延時增長約0.2ms，而酷家樂應用場景的延時甚至還有下降）。

性能視角——cNginx vs Envoy（優化後）

因爲Service Mesh架構的Sidecar和應用不在一個進程中，所以針對Service Mesh數據面的優化路徑會更豐富，優化的可持續性也更強，同時因爲優化效果的干擾因素更小，優化數據會更有說服力。

咱們的輕舟微服務團隊對容器網絡和Envoy作了初步的優化：

• 採用 SRIOV 容器網絡

• Envoy：將1.13版本中 connection loadbalancer 特性移植到 1.10.x 版本

根據咱們的壓測數據

• 在併發較低（<64）、1000RPS的狀況下，Envoy優化後的版本在容器網絡下開啓Client Sidecar表現要優於虛擬機網絡的直連，相較於容器網絡直連開銷增長0.2~0.6ms

• 在併發較高（>=64）、1000RPS的狀況下，Envoy優化後的版本在容器網絡下開啓Client Sidecar表現要遠遠優於虛擬機網絡cNginx的性能，與虛擬機網絡的直連性能幾乎至關；但相較於容器網絡直連1~5ms左右的延時

​

因爲嚴選絕大部分應用的併發在40如下，這個性能表現可謂是至關不錯，也極大提高了咱們對Service Mesh架構進行升級的信心。

當前演進方向

所以，嚴選當前Service Mesh架構的演進方向是基於 Istio+Envoy 的方案：

• 數據面以 Envoy Proxy 做爲代理組件

• 控制面以 Pilot 爲核心組件

• 平臺開放與擴展主要經過 Kubernetes CRD與Mesh Configuration Protocol（簡稱爲 MCP，一套標準 GRPC 協議）

• 高可用設計主要基於 Kubernetes 及 Istio 機制實現

​

混合雲架構落地實踐

2019年，嚴選正式啓動雲化戰略，並明確使用容器化和Service Mesh技術對嚴選應用系統進行雲化，因爲嚴選當前虛擬機集羣採用的是Service Mesh架構，所以，在應用系統雲化過程當中，咱們也充分體會到了與業務解耦的基礎設施層帶來的工程價值，目前嚴選已經有超過90%的B端業務完成了容器化改造及Service Mesh架構升級。

嚴選上雲Roadmap

來看下嚴選上雲 Roadmap，主要分紅三個階段：

• IDC（私有云）時期：應用系統部署在虛擬機集羣

• 混合雲時期：部分應用系統部署在容器環境，部分部署在虛擬機環境，且存在同一個服務部署在多個運行環境的狀況；這也是目前嚴選所處的階段

• 雲化/多雲時期：應用系統徹底雲化，部署在多個容器環境，甚至部署在多個雲服務商

​

落地關鍵步驟

根據咱們的實踐，混合雲架構的落地須要處理好四個關鍵步驟：

首先是要堅決的擁抱雲原生

• 應用全面雲原生化能夠最大化的發揮雲的優點，已是大勢所趨，所以，不管企業仍是我的都不該該忽視這種趨勢

• 以容器、Service Mesh、微服務、Serverless爲表明的雲原生技術相輔相成

  • 容器化是雲原生的重要基石，是微服務的最佳載體，同時也使Service Mesh高效落地的基石

  • Service Mesh架構能夠從流量管控層面消除虛擬機和容器這兩種運行環境的差別性，能夠很好的支持混合雲或者多雲模式，是混合雲或者多雲架構能夠高效落地的關鍵步驟

其次是要建設好服務治理平臺

• 藉助服務治理平臺，能夠無縫銜接虛擬機環境和容器環境的服務治理能力，整合Service Mesh的控制面能力，最大化的發揮Service Mesh的優點

• 藉助服務治理平臺提供的流量管控和路由控制能力，能夠透明的控制應用系統在混合雲架構下的服務形態，使應用系統能夠平滑的從私有云遷移到混合雲或者多雲

• 藉助服務治理平臺整合混合雲架構的監控和告警事件，使Service Mesh的可用性被實時的監控起來，可運維性也更好

再次是建設統一的部署平臺

• 統一的部署平臺能夠從部署層面消除虛擬機和容器這兩種運行環境的差別性，從而向業務研發團隊屏蔽混合雲架構的底層複雜性

• 統一的部署平臺能夠自動注入Service Mesh的Sidecar，使業務無需感知基礎架構

• 統一的部署平臺能夠整合Service Mesh的控制面能力以達到混合雲架構下部署過程的平滑以及部署完成後的灰度引流能力，從而加速應用系統的雲化進程

最後是要作好灰度引流

灰度引流包括服務間調用的灰度引流和外域調用（用戶流量）的灰度引流，經過灰度引流，能夠從私有云架構平滑遷移到混合雲架構，而平滑遷移的能力也是Service Mesh在混合雲架構落地的關鍵。

平滑遷移

這裏重點講下咱們如何作到私有云架構向混合雲架構平滑遷移：

• 經過邊緣網關實現各個LDC（LDC是一組應用、數據和網絡的邏輯單元）相互聯通

  • 邊緣網關屏蔽了每一個LDC不一樣的基礎架構，能夠簡化遷移的流程

  • 邊緣網關同時也能夠用於流量認證鑑權，在混合雲架構中跨LDC的訪問場景發揮重要做用

• 兜底路由設計

  • 兜底路由使流量在儘量不從當前AZ逃逸的狀況下，提供了一種高可用的解決方案，使同環境的LDC能夠互相備份

• 訪問控制：從私有云架構遷移到混合雲架構的過程當中，訪問控制的平滑遷移是個難點，嚴選目前主要採用兩種手段

  • IP池化技術：主要面向數據庫等依賴IP管控權限的基礎服務

  • 經過Service Mesh的能力實現基於服務的權限管控

• 提供灰度引流能力，使基礎架構及業務的遷移狀態對調用方透明；這個過程須要處理好內部流量和外域流量

​

API網關

外域流量的灰度引流能力須要API網關作好能力支持，混合雲架構下的API網關須要在控制面融合虛擬機環境和容器環境的API網關管控能力。

• 總體基於 Envoy+Pilot 方案

• 數據面

  • 容器環境以 Envoy Proxy 做爲代理組件

  • 虛擬機環境以Kong做爲代理組件

• 控制面以 Pilot 爲核心組件

• 平臺開放與擴展主要經過 Kubernetes CRD與Mesh Configuration Protocol（簡稱爲 MCP，一套標準 GRPC 協議）

如圖所示，具體的技術細節這裏不作展開

​

質量保障體系

Service Mesh做爲基礎架構，其自身的交付質量也很是重要。

要提升Service Mesh架構的交付質量和運維質量，主要從如下幾個方面入手：

• 創建CICD流程，完善單元測試和集成測試

• 完善性能基準自動測試，並持續跟蹤性能數據

• 完善監控報警，使基礎架構的運行狀態是被監控的

• 完善版本升級機制

  • 支持Envoy熱更新

  • 提供灰度發佈機制，作到業務可灰度和流量可灰度

  • 提供多級環境，建設基礎架構的演練、測試、灰度及發佈的規範流程

• 引入業務迴歸驗證流程

踩過的坑

固然Service Mesh架構的落地過程也並不是一路順風，仍是有些坑須要繞過去，好比：

• Envoy 目前編譯版本存在 Bug

  • 在 Istio Pilot 升級到加入 accesslog 相關配置下發功能版本後，Envoy 在必定壓力訪問或有客戶端主動斷開請求時，會進入一段存在問題的斷言（assert）邏輯，致使 envoy crash，此時請求方表現爲 502 異常

  • 社區將在新版本中清理這段問題斷言邏輯（github.com/envoyproxy/… envoy 編譯選項使用 -opt（默認爲 -dbg）

• Mixer 性能陷阱

  • Mixer的性能問題一直被詬病，好比打開 Mixer 的策略執行功能，每一次調用 Envoy 都會同步調用 Mixer 進行一次策略檢查，致使性能衰減很是迅速，固然社區也已經意識到這個問題並在着手進行優化

  • 做爲 Mixer 策略執行的替代品， Istio 的 RBAC 也是能夠知足一部分功能的，好比服務白名單咱們就是經過 RBAC 來實現

規劃與展望

Service Mesh架構發展到如今仍有較大的發展空間，嚴選和輕舟微服務團隊後續將主要從性能和功能兩個維度進行持續的探索與演進。

性能優化方向

性能方面，目前主要有兩個研究方向

• 方案1: 採用 eBPF/xDP(sockops)，優化路徑爲 SVC <-> Envoy，保守預計，延遲性能提高10-20%。Envoy 部署方式 per-pod，跟社區方向一致，也是目前嚴選採用的部署方案。

• 方案2: 採用 DPDK+Fstack 用戶態協議棧，優化路徑爲 Envoy <-> Envoy，延遲性能提高0.8-1 倍。Envoy 部署方式爲 per-node，功能和運維層面的限制還在評估當中。

結論：Sidecar 模式採用方案1進行優化，gateway 模式採用方案2進行優化。

服務治理平臺——升級嚴選服務治理能力

功能方面，咱們主要經過輕舟微服務治理平臺來提供更豐富、更高質量的服務治理能力。

• 加強調用控制和治理控制能力

  • 好比經過平臺化能力爲業務提供限流、熔斷和故障注入能力，下降業務研發團隊的學習成本

• 提供平臺化的訪問控制能力，使訪問控制不是做爲一個技術需求，而是做爲服務的產品化運營能力

• 根據精細化的運維能力

總結

今天的分享首先爲你們介紹了Service Mesh架構在嚴選的演進歷程，而後分享了Service Mesh在嚴選混合雲架構落地過程當中發揮的關鍵做用、遇到的一些問題及咱們的經驗，最後概述了一下目前咱們正在作的兩塊工做：Service Mesh性能持續優化以及服務治理平臺能力持續加強。

嚴選的實踐說明目前Service Mesh架構成熟度已經具有了大規模落地的條件，但願咱們的工做能夠爲社區帶來借鑑意義。

網易技術熱愛者隊伍持續招募隊友中！網易嚴選，由於熱愛因此選擇， 期待志同道合的你加入咱們， Java開發簡歷可發送至郵箱：lizhuo01@corp.netease.com