背景
Service Mesh在嚴選的探索與實踐大致分了以下幾個階段。
第一個階段是探索期（2015年底~2016年4月）
網易嚴選從2015年底開始內部孵化到2016年4月正式面世，這個階段嚴選的技術團隊規模非常小，差不多10人左右，核心業務採用的是單體架構，同時會依賴少量業務基礎服務，如推送服務、文件存儲服務、消息中心等等。
在這個時期，如果我們將視野擴大到孵化嚴選的網易郵件事業部，當時採用的主流架構是面向服務的架構(SOA)，但實現上並不統一，有使用中心化的ESB技術提供的服務、也有使用去中心化的Spring Cloud框架提供的服務。
不管是ESB還是以Spring Cloud爲代表的分佈式服務框架，都有一些典型的問題需要解決，而嚴選作爲一個現象級的電商產品，其可以預見的業務複雜度使得我們不得不重視這次關鍵的選型，稍有不慎，就有可能會帶來非常大的技術負債。
這次基礎架構選型過程中，我們主要從三個維度進行了思考：
服務治理：RPC 框架 vs 服務治理平臺
通過RPC框架提供服務治理能力還是將服務治理能力平臺化？
通過框架將服務治理能力集成到業務在當時仍是主流，但從內外部諸多的實踐結果來看，這種思路仍需要解決大量的問題，其中尤爲顯著是框架升級問題，業務團隊和中間件團隊訴求不同，往往推動起來費時費力，一方面影響業務的迭代節奏甚至業務服務質量，另一方面也嚴重製約中間件的演進效率。
多語言 vs Java
服務治理能力建設是否應該考慮非Java技術棧？
嚴選核心業務採用的是Java技術棧，但仍然存在不少非Java的應用系統，比如使用Python技術棧的推薦服務、使用C++技術棧的接入服務以及大量的NodeJS應用，相對而言，Java技術棧的生態更爲豐富，如果要拉齊各語言棧的服務治理能力，需要投入大量的研發成本，如果不投入，這些語言棧的服務治理短板未來很有可能成爲整個系統的短板。
開源 vs 自研
不管採用哪種基礎架構，都需要問兩個問題：
- 是從0開始建設還是基於成熟的開源項目進行擴展？
- 如果從0開始建設，是否屬於重複造輪子？能額外爲社區爲公司帶來哪些價值？
最後我們決定嘗試服務網格（Service Mesh）的理念，並基於Consul和Nginx進行擴展。
第二個階段是小規模試驗期（2016年4月~2017年初）
2016年7月份，我們發佈了第一代Service Mesh架構，並陸續在網易郵箱、網易有錢以及網易嚴選的部分業務進行試點，獲得了不錯的落地效果，也積累了寶貴的運維經驗，同時管控平臺也基本成型。
第三個階段是全面落地期（2017年）
伴隨着嚴選業務規模的不斷增長，業務的複雜度不斷提升，團隊規模也迅速增長，從最初的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 異常
- 社區將在新版本中清理這段問題斷言邏輯（https://github.com/envoyproxy/envoy/issues/9083），對於舊版本，社區目前給出的優化建議是在 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架構成熟度已經具備了大規模落地的條件，希望我們的工作可以爲社區帶來借鑑意義。
最後感謝Service Mesh Meetup組委會邀請，感謝大家聆聽。
視頻回放和 PPT 下載
