導讀：百度過去基於 rpc 框架的服務治理存在各類框架能力良莠不齊、業務自身服務治理效率低、全局可觀測性不足等諸多問題。本文介紹了百度內部落地 service mesh 的實踐過程，以基礎穩定性能力治理和流量調度治理能力爲業務落地點，詳細闡述了內部落地的 service mesh 總體技術方案以及一系列關鍵技術，如性能的極致優化、擴展的高級策略、周邊服務治理系統等。php
1、背景
百度大部分產品線已完成微服務的改造， 數萬個微服務對架構服務治理能力提出了更高的要求。傳統的服務治理通常經過 rpc 框架去解決，多年以來百度內部也衍生出多種語言的 rpc 框架，好比 c++、go、php 等等框架，基礎服務治理能力和 rpc 框架耦合，rpc 框架能力良莠不齊，給公司總體服務治理能力和效率提高帶來較多的痛點及挑戰：c++
1.高級架構能力沒法多語言、多框架複用golang
如某產品線近 2 年發生數次雪崩 case，底層依賴的 php、golang 等框架須要重複建設來定製動態熔斷、動態超時等高級能力，而這些能力在其餘 rpc 框架已支持；性能優化
如經常使用架構降級、止損能力各個產品線重複建設，接口方案差別大，從運維層面，運維同窗指望基礎的架構止損能力在不一樣產品線之間可以通用化，接口標準化，下降運維成本；網絡
2.架構容錯能力治理週期長，基礎能力覆蓋度低多線程
隨着混沌工程全面落地，對架構能力有了更高要求。多數模塊對單點異常，慢節點等異常缺少基礎容忍能力，推進每一個模塊獨立修復，成本高，上線週期長。架構
如某產品線治理改造花了 2 個季度完成；推薦某類召回服務常常出現超時、重試配置等不合理的問題，集中管理調整成本比較高。負載均衡
3.可觀測性不足，是否有通用機制提高產品線可觀測性？框架
好比某推薦業務缺乏總體模塊調用關係鏈和流量視圖，線上故障靠人肉經驗定位、新機房搭建週期長，效率低。less
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 實際過程當中，面臨如下幾大挑戰：
· 低侵入：百度大大小小有上百個產品線，模塊數量級達到萬級別，實例數達到百萬級別，如何讓業務在不改代碼前提下無縫遷移，低侵入接入是咱們在設計方案考慮第一要素；
· 高性能：百度核心產品線在線服務對延遲要求極高，好比推薦、搜索等核心產品線，延遲上漲幾毫秒會直接影響用戶的體驗和公司收入，從業務角度不能接受接入 mesh 後帶來的性能退化。所以咱們在落地過程當中，投入很大精力來優化 mesh 的延遲，下降接入 mesh 後的性能損耗；
· 異構系統融合：首先咱們須要解決廠內多語言框架互通問題，其次須要統一接口和協議，打通廠內多個服務治理系統，如服務發現、流量調度、故障止損等系統；
· 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 接入平臺，爲各業務線提供低侵入、低成本、標準化的服務治理解決方案，系統性解決各個產品線的基礎可用性問題，大幅下降治理迭代成本 &週期，促進體系總體穩定性能力的提高。
文章看完，還不過癮？
更多精彩內容歡迎關注百度開發者中心公衆號