導讀：百度過去基于rpc架構的服務治理存在各種架構能力參差不齊、業務自身服務治理效率低、全局可觀測性不足等諸多問題。本文介紹了百度内部落地service mesh的實踐過程，以基礎穩定性能力治理和流量排程治理能力為業務落地點，詳細闡述了内部落地的service mesh整體技術方案以及一系列關鍵技術，如性能的極緻優化、擴充的進階政策、周邊服務治理系統等。
1. 背景
百度大部分産品線已完成微服務的改造， 數萬個微服務對架構服務治理能力提出了更高的要求。傳統的服務治理一般通過rpc架構去解決，多年以來百度内部也衍生出多種語言的rpc架構，比如c++、go、php等等架構，基礎服務治理能力和rpc架構耦合，rpc架構能力參差不齊，給公司整體服務治理能力和效率提升帶來較多的痛點及挑戰：
- 進階架構能力無法多語言、多架構複用
如某産品線近2年發生數次雪崩case，底層依賴的php、golang等架構需要重複建設來定制動态熔斷、動态逾時等進階能力，而這些能力在其他rpc架構已支援；
如常用架構降級、止損能力各個産品線重複建設，接口方案差異大，從運維層面，運維同學期望基礎的架構止損能力在不同産品線之間能夠通用化，接口标準化，降低運維成本；
- 架構容錯能力治理周期長，基礎能力覆寫度低
随着混沌工程全面落地，對架構能力有了更高要求。多數子產品對單點異常，慢節點等異常缺乏基礎容忍能力，推動每個子產品獨立修複，成本高，上線周期長。
如某産品線治理改造花了2個季度完成；推薦某類召回服務經常出現逾時、重試配置等不合理的問題，集中管理調整成本比較高。
- 可觀測性不足，是否有通用機制提升産品線可觀測性？
比如某推薦業務缺少整體子產品調用關系鍊和流量視圖，線上故障靠人肉經驗定位、新機房搭建周期長，效率低。
2. service mesh解決什麼問題？
為徹底解決目前業務服務治理的痛點和問題，我們引入了service mesh，基本思路解耦治理能力和架構，治理能力下沉到sidecar。内部聯合多個部門通過合作共建方式建設通用的service mesh架構， 提供通用的基礎穩定性能力和統一的流量控制接口。
我們期望service mesh在廠内業務落地解決什麼問題？總結為兩點：
- 基礎穩定性能力的關鍵元件 – 為微服務提供通用的基礎故障容錯能力、基礎故障檢測能力、統一的幹預和控制接口；
- 流量治理的核心系統 – 實作各産品線整體的連接配接托管、全局流量的可觀測、精細排程能力
service mesh定義
Linkerd CEO William Morgan于2016年9月29日公開提出，service mesh是用于處理服務間通信的基礎設施層，用于在雲原生應用複雜的服務拓撲中實作可靠的請求傳遞。在實踐中，service mesh通常是一組與應用一起部署，但對應用透明的輕量級網絡代理。
3. 技術挑戰
我們在落地service mesh實際過程中，面臨以下幾大挑戰：
1. 低侵入：百度大大小小有上百個産品線，子產品數量級達到萬級别，執行個體數達到百萬級别，如何讓業務在不改代碼前提下無縫遷移，低侵入接入是我們在設計方案考慮第一要素；
2. 高性能：百度核心産品線線上服務對延遲要求極高，比如推薦、搜尋等核心産品線，延遲上漲幾毫秒會直接影響使用者的體驗和公司收入，從業務角度不能接受接入mesh後帶來的性能退化。是以我們在落地過程中，投入很大精力來優化mesh的延遲，降低接入mesh後的性能損耗；
3. 異構系統融合：首先我們需要解決廠内多語言架構互通問題，其次需要統一接口和協定，打通廠内多個服務治理系統，如服務發現、流量排程、故障止損等系統；
4. mesh可靠性：線上業務對可靠性要求極高，要求我們在落地過程中，充分考慮自身穩定性，避免出重大case。
總結：我們的需求是實作一套低侵入、高性能、完備的治理能力，能夠解決業務實際問題service mesh架構。
4. 整體架構
技術選型：我們底層以開源istio+envoy元件為基礎，基于廠内實際業務場景，适配廠内元件。選擇基于開源定制的主要原因是相容社群，跟開源保持标準協定，吸收社群的進階feature同時能夠反哺到社群。
我們内部落地的mesh整體架構如下 ，包括以下核心元件：
Mesh控制中心
- 接入中心：sidecar的注入，管理sidecar版本，統一上線入口；
- 配置中心：穩定性治理和流量治理入口，托管連接配接、路由配置、通信等政策；
- 運維中心：mesh的日常運維，如幹預去劫持操作；
- 控制台：istio-pilot元件，負責路由管理、通信政策等功能；
資料面闆：envoy元件，負責流量轉發、負載均衡等功能；
依賴元件：融合廠内服務發現元件naming service、内部各種rpc架構适配、監控系統、底層paas支援；
周邊治理生态：基于mesh統一治理接口衍生出的服務治理生态，如智能調參系統、 故障自動定位&止損系統、故障治愈、混沌工程（基于mesh的精細化故障注入）。
接下來我們從接入方式、性能優化、穩定性治理、流量治理、周邊系統協同、穩定性保障等關鍵技術來解析：
4.1 接入方式
社群采用的iptables流量劫持方案， iptables規則過多會導緻性能問題，尤其在廠内數萬個執行個體轉發下受限iptables線性比對規則，轉發延遲非常大，不能滿足線上低延遲的場景。
我們的解決思路：基于本地lookbackip位址方案，envoy打通内部服務發現元件，劫持服務發現請求，通過回傳lookback位址透明劫持業務流量。同時本地naming agent定期探活envoy，一旦envoy出現異常，自動回退到直連模式，避免envoy故障導緻流量丢失。
同時針對一些不走流量劫持的業務，我們設計了proxyless方案，即通過rpc架構适配istio标準的xds，接入pilot服務治理的通路，托管服務治理政策和參數分發生效。無論業務流量是否被劫持，都通過mesh标準化的幹預入口實作服務治理的統一管控和治理。目前proxyless方案已在内部c++等rpc架構完成适配，在搜尋、推薦等業務線落地。
總結：我們通過基于服務發現流量劫持和proxyless兩種透明遷移的的接入方案，實作業務子產品無需修改代碼即可接入mesh的低侵入方式，降低業務接入mesh的成本。
4.2 性能極緻優化
我們在落地過程發現社群版本envoy延遲、資源消耗較大，在一些大扇出複雜場景下，流量劫持帶來的延遲上漲接近5ms，cpu消耗占比20%以上，無法滿足廠内線上業務高吞吐、低延遲場景。我們分析evnoy底層模型，
本質原因是envoy 是一個單程序多線程的libevent線程模型，一個event-loop隻能使用一個核，一個回調卡住就會卡住整個線程，容易産生高延時，導緻吞吐長尾控制能力比較差。
我們基于envoy擴充接口擴充envoy的網絡模型&線程模型，引入brpc底層高性能的bthread協程模型 。在我們内部簡稱高性能brpc-envoy版本。同時我們打通pilot，實作原始libevent和brpc-thread線上切換，使用者可以非常友善自助選擇開啟高性能模型。
備注：
brpc 百度内部c++ 高性能rpc開源架構，内部數幾十個産品線在使用，執行個體數有數百萬規模，已開源。
測試下來結果，相比開源社群版本和MOSN（螞蟻自研已開源）等業界架構， CPU降低60%+，平均延遲降低70%+，長尾延遲平均降低75%+，性能大幅領先業界，徹底解決社群版envoy無法滿足大規模工業高性能場景的問題，為大規模落地mesh掃清障礙。
同時我們正在調研ebpf、dpdk等新技術，進一步降低延遲和資源消耗。目前測試下來ebpf相比本地lookbackip轉發性能有20%的提升，dpdk相比核心協定棧有30%的性能優化空間（在綁核條件下）。
4.3 穩定性治理
内部線上&離線服務大規模混部，線上混部環境複雜，對子產品的架構穩定性能力要求比較高。我們基于mesh提供通用的故障容錯能力、故障檢測能力、統一的幹預和降級能力來整體提升産品線穩定性能力的baseline：
4.3.1 局部故障容錯能力：
為了提升架構對日常機器故障的容錯能力，我們基于envoy擴充了進階穩定性容錯政策，比如增加動态重試熔斷政策，通過滑動視窗計算分位值耗時，動态控制重試比例，通過重試撈回請求同時也避免大量重試引發雪崩的風險。另外我們引入回報式的進階負載均衡政策，根據下遊傳回定制的錯誤碼，降級&屏蔽故障執行個體，通過熔斷保護機制控制權值，避免正常執行個體被打挂。在我們内部核心産品線上線後，大幅提升子產品在局部故障下的容錯能力，架構韌性能力大大提升。
（參考下圖，某線上核心子產品接入mesh後，可用性從之前2個9提升到4個9）
針對雪崩治理場景（我們統計廠核心心産品線雪崩曆史case，90%以上case都是雪崩治理能力缺失，比如重試風暴、逾時倒挂、降級能力缺失導緻），我們基于mesh定制熔斷能力的進階重試能力來抑制重試風暴，提供動态逾時機制來預防逾時倒挂。在核心産品線的大範圍鋪開後，覆寫近2年内雪崩90%+故障場景， 2020年雪崩case對比2019年雪崩類case損失環比下降了44%
4.3.2 局部故障檢測能力：
過去故障檢測依賴機器粒度的基礎名額，粒度比較粗，針對容器故障執行個體缺乏精細名額檢測，無法及時探測到故障執行個體，通常需要數小時才會檢測到故障執行個體。我們打通了上層故障自愈系統，基于envoy擴充故障檢測政策，提供通用、快速直接的故障發現檢測能力，外部故障自愈系統通過prometheus接口采集故障執行個體，經過彙聚分析，觸發paas遷移故障執行個體。對于已接入mesh的業務線，幾乎零成本代價下即可具備局部異常的快速發現&定位能力，故障執行個體的檢測時效性從原來數小時優化到分鐘級。
4.3.3 統一的幹預和降級能力：
對于一些大規模故障，單靠架構自身容錯解決不了，需要依賴穩定性預案去止損，比如典型的下遊弱依賴摘除預案。過去依賴不同産品線和子產品自身去建設降級能力，不同子產品接口方案差異大，随着系統不斷疊代，降級能力可能出現退化，運維成本和挑戰比較大。我們結合mesh實作通用降級和幹預能力，如支援多協定場景下流量丢棄能力，實作統一的流量降級政策；通過統一的逾時和重試幹預能力，實作秒級的幹預時效性。
通過落地mesh為多産品線提供統一的幹預和控制接口，為穩定性預案提供一緻的操作接口，大大提升了服務治理效率，産品線服務治理疊代周期從過去季度級縮短到月級。
如20年某業務線接入mesh兩周完成4個方向20+子產品架構治理改造，而原來往往需要一個季度周期才能完成改造。
4.4 流量治理能力
流量可觀測性：
過去建構産品線子產品上下遊調用鍊和基礎黃金名額一直缺乏通用的解決方案，大多數都是基于rpc架構或者業務架構定制，子產品調用鍊和黃金名額覆寫率低。比如某重要産品線端到端涉及到2000多個子產品，調用鍊關系十分複雜，具體流量的來源不夠透明，嚴重影響運維效率。如機房搭建不知道上下遊的連接配接關系，靠人肉梳理誤差大，某産品線一次搭建周期将近2個月時間。另外故障定位、容量管理等由于全局的可觀測性不足，往往隻能依賴經驗定位，效率十分低下。
我們整體思路以mesh為中心，結合周邊rpc架構，建構全局servicegraph調用鍊。
- 一方面通過istio内部crd抽象表達出子產品鍊路關系和鍊路屬性，在istio上層自建mesh配置中心，屏蔽底層crd細節。以配置中心作為連接配接托管的唯一入口，托管子產品全鍊路的調用關系，新機房建設基于servicegraph快速建構出新機房的拓撲，很大程度提升機房搭建效率，縮短周期。
- 另一方面同時結合brpc和mesh，制定标準的黃金名額格式，建設統一的黃金名額資料倉庫，支援上遊的服務治理建設，比如容量管理分析、故障定位、性能分析、故障注入等。比如我們正在落地的故障自感覺、止損系統基于servicegraph可自動化、快速、準确實作線上故障的感覺、止損。
流量精細排程：
廠内大部分産品線基于入口整體切流，一直缺乏對子產品鍊路内部流量精細排程控制能力。我們結合mesh的流量排程能力，打通廠内服務發現元件，整合一系列切流平台，統一流量排程入口到mesh控制中心。結合前面servicegraph提供的全局調用鍊，實作子產品精細連接配接關系的流量排程能力；另外我們基于mesh實作子產品執行個體粒度精細流量排程和流量複制能力，典型應用于子產品的精細流量評估、線下壓測、導流場景下。
4.5 周邊生态協同
基于mesh提供統一的控制接口，衍生出周邊服務治理系統，典型場景如治理參數自動調參、故障自動止損、故障自愈等系統。
自動調參系統
服務治理參數依賴使用者手工配置參數(逾時比例、權重比例等)，完全依賴人肉經驗，頻繁出現配置不合理影響治理能力效果，同時線上環境差異比較大，靜态配置無法适應線上複雜環境變化。我們設計出一套動态調參系統，核心思路基于mesh的治理統一接口和結合線上名額實時回報，實時調整治理參數。比如根據下遊CPU使用率，動态調參通路下遊重試分位值比例；根據下遊機器負載差異化，動态調參通路下遊權重。
在廠核心心産品線落地後，通過自動調參完全代替人肉調參，實作服務治理參數自适應調整。
故障自動感覺止損系統
傳統線上故障憑人工經驗定位，産品線深度定制預案能力，強依賴有經驗的工程師，新人上手成本高；并且預案止損操作散落在文檔中，可維護性差，随着業務疊代可能失效或者逐漸退化，不可持續。
我們基于mesh通用的幹預能力和統一控制接口，研發一套故障預案自動止損系統，結合前面提到的service graph提供全局調用鍊和黃金名額，實作常見故障的自動感覺、預案自動止損，降低故障止損的mttr時間。同時打通混沌工程，定期端到端注入故障觸發預案演練，避免預案能力退化。這套系統目前典型應用在強弱依賴降級、精細化流量排程等預案場景，預計到年底，接入mesh的産品線大部分線上故障都能自動化處理。
統一協定，協同周邊系統
基于mesh配置中心提供标準的流量控制和服務治理接口（如流量降級接口），協同周邊系統生态，如自動調參、故障感覺止損、故障自愈、流量排程。
基于開源xds協定，統一資料面協定，對接周邊rpc架構，實作不同rpc架構能夠統一控制。
4.6 自身穩定性保障
廠内業務比如搜尋、推薦等關鍵業務對穩定性要求極高，線上遷移mesh好比”高速公路上換車輪“，必須保證對業務無損。是以穩定性建設是我們在落地mesh過程重點關注點之一。
首先我們通過多級兜底機制保障流量轉發的可靠性。針對局部故障，如個别envoy執行個體配置、程序等異常，envoy自身具備fallback機制，異常可以自動回退直連模式，無需人工介入。但一些大規模故障，比如envoy出現大範圍故障，靠envoy自身機制已經無法保證（可能出現劫持、非劫持模式來回波動），我們通過外部幹預平台一鍵下發轉發黑名單，強制幹預envoy切到直連模式，全産品線止損時效性控制在5分鐘以内；極端情況下，如envoy大範圍hang死，可能導緻對外幹預接口失效，我們準備了兜底預案，關聯paas批量強制殺掉envoy程序，回退到直連模式。
其次在服務治理配置釋出方面，我們核心思路控制故障隔離域，比如打通mesh配置中心，灰階控制配置釋出的百分比；同時建構mesh接入一站式平台，梯度逐漸釋出，控制envoy更新對業務的影響面。我們引入monitor子產品定期做端到端巡檢，如配置一緻性、envoy節點服務異常、版本一緻性等校驗。
最後我們定期通過混沌工程主動注入故障，比如模拟envoy異常、pilot異常、配置中心異常等，進行極限異常case演練，避免自身穩定性架構能力退化。
5. 總結
從19年年底開始立項，不到2年的時候，在内部數十個産品線已完成落地，其中一些核心産品線主幹子產品已覆寫到80%以上，天級托管流量超過千億。新接入子產品幾乎零成本接入，即可具備基礎穩定性治理和流量排程能力。我們結合周邊生态系統，建構一站式mesh接入平台，為各業務線提供低侵入、低成本、标準化的服務治了解決方案，系統性解決各個産品線的基礎可用性問題，大幅降低治理疊代成本&周期，促進體系整體穩定性能力的提升。