導讀:百度過去基於rpc框架的服務治理存在各類框架能力層次不齊、業務自身服務治理效率低、全局可觀測性不足等諸多問題。本文介紹了百度內部落地service mesh的實踐過程,以基礎穩定性能力治理和流量調度治理能力爲業務落地點,詳細闡述了內部落地的service mesh總體技術方案以及一系列關鍵技術,如性能的極致優化、擴展的高級策略、周邊服務治理系統等。php
全文6835字,預計閱讀時間13分鐘。前端
1、背景
========c++
百度大部分產品線已完成微服務的改造, 數萬個微服務對架構服務治理能力提出了更高的要求。傳統的服務治理通常經過rpc框架去解決,多年以來百度內部也衍生出多種語言的rpc框架,好比c++、go、php等等框架,基礎服務治理能力和rpc框架耦合,rpc框架能力良莠不齊,給公司總體服務治理能力和效率提高帶來較多的痛點及挑戰:golang
1.高級架構能力沒法多語言、多框架複用算法
如某產品線近2年發生數次雪崩case,底層依賴的php、golang等框架須要重複建設來定製動態熔斷、動態超時等高級能力,而這些能力在其餘rpc框架已支持;後端
如經常使用架構降級、止損能力各個產品線重複建設,接口方案差別大,從運維層面,運維同窗指望基礎的架構止損能力在不一樣產品線之間可以通用化,接口標準化,下降運維成本;性能優化
2.架構容錯能力治理週期長,基礎能力覆蓋度低網絡
隨着混沌工程全面落地,對架構能力有了更高要求。多數模塊對單點異常,慢節點等異常缺少基礎容忍能力,推進每一個模塊獨立修復,成本高,上線週期長。多線程
如某產品線治理改造花了2個季度完成;推薦某類召回服務常常出現超時、重試配置等不合理的問題,集中管理調整成本比較高。架構
3.可觀測性不足,是否有通用機制提高產品線可觀測性?
好比某推薦業務缺乏總體模塊調用關係鏈和流量視圖,線上故障靠人肉經驗定位、新機房搭建週期長,效率低。
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接入平臺,爲各業務線提供低侵入、低成本、標準化的服務治理解決方案,系統性解決各個產品線的基礎可用性問題,大幅下降治理迭代成本&週期,促進體系總體穩定性能力的提高。
招聘信息
若是你對微服務感興趣,請你聯繫我,咱們當面聊聊將來的N種可能性。不管你是後端,前端 ,大數據仍是算法,這裏有若干職位在等你,歡迎投遞簡歷,關注同名公衆號百度Geek說,輸入內推便可,咱們期待你的加入!
推薦閱讀
---------- END ----------
百度Geek說
百度官方技術公衆號上線啦!
技術乾貨 · 行業資訊 · 線上沙龍 · 行業大會
招聘信息 · 內推信息 · 技術書籍 · 百度周邊
歡迎各位同窗關注