服務網格在百度核心業務大(dà)規模落地實踐
從微服務到服務網格
何謂微服務？據維基百科的定義：微服務是一(yī)種軟件架構風格，它是以專注于麗山單一(yī)責任與功能的小(xiǎo)型功能區塊爲基礎，利用模塊睡器化的方式組合出複雜(zá)的大(dà)型應用程序，各功能區塊使用與語言無關的 票他API 集相互通信。
Service Mesh 最早在 2016 年 9 子跳月 29 日由開(kāi)發 Linkerd 的子區 Buoyant 公司首次提出，Service Mesh 是多上用于處理服務間通信的基礎設施層，它負責通過構成現資技代雲原生(shēng)應用程序的複雜(zá)拓撲到就結構來可靠地傳遞請求。
因此 Service Mesh 也被稱爲微服務時代的 TCP 中我協議。
第一(yī)代微服務的常見架構如下(xi子農à)圖所示：
在黃色的容器内有服務 A、服務 B。A 和 B 都包含自己的裡信業務邏輯，如果想要 A 調用 B，同時試圖對這個服務進行治雜的理，通常會在業務的内部集成一(yī)個 SDK，來實現服務發市用現、負載均衡、服務路由、重試、熔斷限流等功能。
但是，這個架構存在三個主要問題：
第一(yī)，開(kāi)發成本。因爲 A資西 和 B 的服務已經是微服務了，它們可能是由不同語言開(kāi)發窗得的而且各自的框架可能也不同，如果希望把綠色的部畫機分(fēn)進行升級或者提供新的功能，就需要重複的叠代和開(kāi)發林房。
第二，升級成本。因爲 SDK 的部分(fēn秒從)跟業務耦合在一(yī)起，在新增一(yī)些能力好鐘時需要重新部署業務的模塊。
第三，部署成本。由于相關治理的功能需要耦合在業務鄉歌的配置裏面，所以很難做到實時的下(xià)發配置，服務間拓撲關系和治理配置無服計法統一(yī)管理。
Service Mesh 是如何解決這些問題的?
如下(xià)圖左側所示，它通過将 SDK自音 、開(kāi)發框架提供的服務治理能力下(xià)沉到一(yī)個和業務可如進程獨立的輕量級網絡代理中(zhōng)，理分由這個網絡代理作爲微服務通信的基礎設施層，大飛它可以提供業務無關、語言無關、獨立演進，透明升級的特性。這個輕量舊分級的網絡進程被稱作 Sidecar 代理，是服務網格的數據面。
同時如右側所示，通過一(yī)個對 Sidecar 進行統一(yī)控笑畫制和管理的服務控制平面，來提供對微服務治理和運維的統一(yī)入口。
這種架構實現了服務治理技術和業務邏輯的解耦，是雲原生些關(shēng)時代微服務治理技術的發展方但吧向，也得到了越來越多的公司的關注。
百度微服務治理的現狀和痛點
百度在服務網格以及微服務相關的探索大(d得話à)概可以追溯到 2013 年，當時在内部獨立部署站算了流量轉發系統，同時在一(yī)些業務有所推廣實施；2016 年 Servi們謝ce Mesh 這個概念被首次提出，因爲百度本下理身有相關需求，便嘗試引入 Mesh 的概朋了念，于是内部自研了一(yī)套遵循社區 Mes醫影h 概念的通過 Golang 開(kāi)發的包含控計水制面和數據面的 BMesh 系統，在搜索服務前端服務上線，不過沒有在特别多業務間近推廣；直到 2019 年，百度内部做了擁抱開(kāi)源的決定，城用希望基于社區方案：Istio + Envoy 進行深度定制開(木又kāi)發。
目前，百度核心業務線已全面完成了微服務架構改造，基于微服務構建了包括百度和好信息流、百度 App、百度地圖、百度小(xiǎo)程序等核心業務的應吃綠用架構；微服務模塊大(dà)量采用 C++、Golang、PHP鐘唱、Java 等語言來開(kāi)發和快速叠代；而且百度長期積澱了許門放多自研和二次開(kāi)發的開(kāi)源微服務框分訊架：bRPC、GDP、ODP、SpringCloud器海 等， 這些微服務間通信除了标準的 HTTP、GRPC 協議外(wài)，筆厭廣泛地采用了大(dà)量的私有協議，比如 baidu-st對月d、Nshead 等。
所以百度的核心業務線形成了多開(kāi)發語言、多開(kāi)一校發框架和多通信協議構成的複雜(zá)的異構系統，傳統子月的基于入侵的微服務框架已經不能滿足這種複雜(zá)系統的服務治理要答家求——升級 Mesh 迫在眉睫！
在升級之前，有一(yī)些重點問題需要綜合考慮：
改造成本 各種各樣的微服務框架網格化改造和适配 各種各樣的通明司信協議支持
性能問題和資(zī)源問題 因爲 Sidecar 的引入，微服務農懂間的通信鏈路變長，業務延遲增加，甚至某些敏感業務無法接兒公受 Sidecar 帶來的額外(wài)損耗。 Sidecar 自身會煙好消耗資(zī)源，增加業務的成本。
規模問題 随着 Sidecar 規模的增長，開(kāi)源煙如的控制平面計算開(kāi)銷變大(dà)，導緻 Mesh 配置下(xià)發匠門時間變長，甚至無法工(gōng)作。
百度服務網格整體(tǐ)方案
如何解決這些問題？
在服務網格的技術選型問題上，百度選擇了開(kāi)源的 Isti頻音o + Envoy 作爲網格控制面和數據面，在其上進議低行深度的定制和開(kāi)發。
但是 Istio + Envoy 的社區方案和 K8S 的微你技術生(shēng)态進行了深度綁定。而在百度内部有自研的基礎技術平台，好新包括對标 K8S 的 PaaS 部署系統、Trace 系統、監控市件系統和 Naming 系統等，這些都是業務模塊包括 Istio + En時日voy 部署運行的依賴系統。所以，将 Isti玩短o + Envoy 和内部依賴系統進行了深度的還外技術融合，打通了公司基礎技術平台，降低了業務接入成本。制睡
在數據面和控制面之上，又(yòu)建設了 Mesh 控制中(zh鐘腦ōng)心，即微服務的配置管理中(zhōng做子)心，提供服務治理和運維的統一(yī)入口；基于底層架構的建設，向上著會提供了流量複制、負載均衡、過載保護、流量鏡像等系統能力。
這些系統能力在核心業務的服務治理、運維止損、容量管理、混沌工線白(gōng)程和服務可觀測等場景中(zh司街ōng)得到了應用，并且取得了不錯的業務收益和使用效果。
那麽，實現這樣一(yī)套系統，我(wǒ)(現用wǒ)們需要解決哪些問題呢？
網格接入優化方案
首先是流量劫持方案的問題，在社區方案中(zhōng)，一(yī車了)般是通過 Naming Service（如：DNS 服務）獲取到目标 S那了erver 的真實地址。同時，通過配置 iptab小樂les 進行流量劫持，将客戶端的請求直接轉發給 Side事靜car。但是，當 iptables 配置有大(快劇dà)量匹配規則時有性能的問題，而且無法動态修改客戶端訪問服務端有你的行爲，如：重試、超時等，且沒有辦法平滑的在 M了這esh 和非 Mesh 模式切換。
在百度内部采用了另外(wài)一(yī)種劫持的方案，科匠首先 Sidecar 啓動的時候會将自己雪銀注冊給 Naming Service（在百度内部叫 BNS），錯這在框架經過 Naming Service 查詢的時候，框架的内部科區集成了一(yī)個和 Naming Service 對接的小(xiǎo你短)模塊，這個小(xiǎo)模塊從 Naming Serv冷她ice 拿到的就是 Sidecar 的地山可址，動态的改變了目标服務器的地址，直接将目标的 IP 變成 Sidecar 的自綠地址（loopbackIp），同時，還會覆蓋客戶端的重試美快、超時等參數，這一(yī)切對業務來說都金些是無感的。
這樣就可以很便捷的調整客戶端服務治理參數、切換 Mesh 和非 M費要esh 模式。因爲如果 Sidecar 挂掉了，多了會在 Naming 系統裏把自己解除注冊，這在資樣上遊的框架會自然而然的訪問下(xià)遊服務的真實地址了。討自
第二，對自有協議的支持的問題。在社區裏面是支讀業持不同的協議，比如 HTTP、Thrift、Dub照匠bo，但會涉及重複的開(kāi)發。如果要支持一(志年yī)個新協議，可能需要重新實現超時控制、重試、請求路由、流呢快量鏡像等。百度内部将這通用的部分(fēn)單裡就獨剝離(lí)出來：于是支持一(yī)個新的協議變得簡單起來輛微，我(wǒ)(wǒ)們隻需要将下(xià)圖中(zhōng)綠色的部實現簡黑跳單的 Codec，即：将這個協議進行編解碼就可以，大(dà)大(d北說à)降低開(kāi)發支持新協議的成本。
最後是對多框架和協議的支持問題。Mesh 對協議的要求包括具有請求特征信息擴小城展的能力，可以實現請求特征路由；具有元信息擴展能力：能遠匠夠在框架和 Sidecar 間傳遞信息（吧我如：一(yī)緻性哈希的 Code），在上下(xià)遊服務模塊間年和傳遞信息（如：TraceID，SpanID) 内部傳統的老協議美空如何接入 Mesh？通過框架實現協議升級，用可擴展聽跳的 baidu-std 協議封裝老協議進行傳輸，到達下(xià)遊舊花服務之後再由框架拆解開(kāi)報文。
服務網格性能優化
針對代理架構如下(xià)圖所示，社區方案是從 器通APP1 進入 Sidecar 再到下(xià)遊民弟服務的 Sidecar 再到 APP2，這裏面經過了兩次 Sidecar件南，會有兩倍延遲或者兩倍資(zī)源開(kāi)銷，在百度内部可能并月有沒有這麽複雜(zá)，沒有對這個很高要求的錢飛場景，多數情況下(xià)隻經過 Sidecar 一(yī)次。議水比如，APP1 經過 Sidecar 後直接到達了 APP2，并沒有再次經過這飛 Sidecar。
另外(wài)一(yī)種模式，内部很敏感坐山的業務并不希望經過 Sidecar。比如，APP2 通過框架直接訪金兵問到 APP3，并沒有經過任何的 Sidecar。下(xià)圖左是經過一吧黑(yī)次 Sidecar 的模式（在百度内部稱爲一(到多yī)跳）這是通過 NamingService 紅湖注冊再訪問本地 IP。而下(xià)圖右 Proxyless 模式 放舊Sidecar 會将自己服務的參數以及目标又電服務的 IP 通過 NamingService 下(xià)新謝發給框架，框架擁有下(xià)遊服務的 IP 以及服務治理的全部參數，可以動中直接完成訪問。
針對數據面性能方面的優化，社區的 Envoy 在性能方面并木街不是特别優越，所以。百度整合了一(yī)個 bRPC 開(kā員煙i)源框架作爲内核去(qù)轉發流量，在上層 bR用些PC 框架依然兼容了 xDS 協議（服務治理參會劇數的協議），便于同步社區的新設計、新變化，做到了魚和熊掌都可以兼得視很的效果，經過升級内核的版本以後，在各個延時、長尾藍樂以及 CPU 使用率上都有很好的優化。
最後是控制面性能優化，控制面在沒有配置 Sidecar CR音去D 的情況下(xià)，會下(xià)發所有的服務列表，我(wǒ)(裡內wǒ)們通過内部的關鍵路徑優化，實際上隻會下(xià)發 Si兒鄉decar 關注的下(xià)遊，大(dà)大(dà)減少控制面對配置計高船算以及下(xià)發的性能優化。
經過上述改造後，最後就完成了百度内部對 Mes低務h 的整體(tǐ)優化和修改。
業務收益及案例啓示
經過上圖所展示的高級服務治理策略，在 SLA 以及故障恢複時間劇年上都有很高的優化。在此基礎上還有全局的智能容災系統，可內些以優化高級服務策略參數
服務可觀測性方面，可以通過框架傳遞 TraceID、SpanID 等，再通過玩微 Sidecar 再采集到内部的 Trace 信遠平台和監控平台，可以在内部的監控平台上展示 Trace，月村方便監控以及進行故障的排查和追蹤。
自動止損方面，整個系統結合内部的監控平台，監控平台将這些指标器大存儲在自己的平台上，穩定性預案平台根據監控平台的指标異身關常進行實時調參，執行流量降級、切機房、切流等。同時這個什要效果會實時反饋給監控平台，包括穩定性預案平台持續的對系統進行調參，形成閉環不是。
混沌工(gōng)程方面，會通過控制平面下(xià)發給故障任務，然後控制平兵那面将命令下(xià)發給 Sidecar，Sidecar 通過這個命令注入一(市又yī)些延遲，這樣去(qù)影響内部的系統，内部系請什統同樣會産生(shēng)監控的指标，這些指标再林慢上報給監控平台，然後混沌平台再通過這些指标評估系統的彈性以及容錯等。
系統容量評估方面，容量平台可以發起壓測任務，這風哥個任務對接到控制平面。如：由控制平面下(xià)發切我秒 20% 的流量到某下(xià)遊服務，子花對它進行壓測，實時産生(shēng)的指标上報給監月可控平台，容量平台對監控平台的指标進行實時評估費資。
百度内部業務接入情況：
百度 App、信息流、百度地圖、智能小(xiǎo)程序、好看視頻(pí習銀n)等産品線
接入實例十萬級
每天處理請求數千億次
業務接入收益：
大(dà)幅提升核心鏈路的可用性和系統整體照技(tǐ)容災、防雪崩能力
大(dà)大(dà)降低治理叠代成本、服務治理叠代周期從數月縮短到天級爸微别
解鎖服務可觀測，自動止損，容量探測等高級場景能力
最後，喬元才總結了通過接入 Mesh 服近有務網格得到的一(yī)些啓示：
服務網格不是微服務治理的銀彈
完全無入侵的，支持所有協議，所有框架和所有治理策務電略的 Mesh 方案是不存在的
大(dà)規模工(gōng)業化落地的平滑、穩定可控接入方案，涉及到大(dà內森)量對已有服務治理組件的兼容升級和改造
服務網格确實實現了業務邏輯和服務治理架構的解耦就紅，解鎖了很多新能力
服務網格結合可觀測、故障止損、混沌工(gōng)程，容量管理等場景化，才遠刀能發揮出最大(dà)價值
百度智能雲已開(kāi)放(fàng)包括服務網格在内的多項微服務産數信品，歡迎試用：https://cloud.baidu.com/produc草制t/cnap.html
相關内容
觀察行業視覺，用專業的角度，講出你們的心聲。
