【導讀】服務網格（Service Mesh）的概念自2017年初提出之後，受到了業界的廣泛關注，作為微服務的下一代發展架構在社群迅速發酵，並且孵化出了諸如Istio等廣受業界關注的面向於雲原生(Cloud Native)的微服務架構。
那麼，服務網格在百度的落地情況又如何呢？
近日，在百度技術沙龍上，百度服務網格技術負責人喬元才發表了『服務網格在百度核心業務大規模落地實踐』的主題演講。
1. 從微服務到服務網格
何謂微服務？據維基百科的定義：微服務是一種軟體架構風格，它是以專注於單一責任與功能的小型功能區塊為基礎，利用模組化的方式組合出複雜的大型應用程式，各功能區塊使用與語言無關的API集相互通訊。
Service Mesh 最早在2016年9月29日由開發 Linkerd 的 Buoyant 公司首次提出，Service Mesh 是用於處理服務間通訊的基礎設施層，它負責透過構成現代雲原生應用程式的複雜拓撲結構來可靠地傳遞請求。
因此 Service Mesh 也被稱為微服務時代的TCP協議。
第一代微服務的常見架構如下圖所示：
在黃色的容器內有服務A、服務B。A和B都包含自己的業務邏輯，如果想要A呼叫B，同時試圖對這個服務進行治理，通常會在業務的內部整合一個SDK，來實現服務發現、負載均衡、服務路由、重試、熔斷限流等功能。
但是，這個架構存在三個主要問題：
第一，開發成本。因為A和B的服務已經是微服務了，它們可能是由不同語言開發的而且各自的框架可能也不同，如果希望把綠色的部分進行升級或者提供新的功能，就需要重複的迭代和開發。
第二，升級成本。因為SDK的部分跟業務耦合在一起，在新增一些能力時需要重新部署業務的模組。
第三，部署成本。由於相關治理的功能需要耦合在業務的配置裡面，所以很難做到實時的下發配置，服務間拓撲關係和治理配置無法統一管理。
Service Mesh 是如何解決這些問題的?
如下圖左側所示，它透過將SDK 、開發框架提供的服務治理能力下沉到一個和業務程式獨立的輕量級網路代理中，由這個網路代理作為微服務通訊的基礎設施層，它可以提供業務無關、語言無關、獨立演進，透明升級的特性。這個輕量級的網路程式被稱作Sidecar代理，是服務網格的資料面。
同時如右側所示，透過一個對 Sidecar 進行統一控制和管理的服務控制平面，來提供對微服務治理和運維的統一入口。
這種架構實現了服務治理技術和業務邏輯的解耦，是雲原生時代微服務治理技術的發展方向，也得到了越來越多的公司的關注。
2. 百度微服務治理的現狀和痛點
百度在服務網格以及微服務相關的探索大概可以追溯到2013年，當時在內部獨立部署了流量轉發系統，同時在一些業務有所推廣實施；2016年 Service Mesh 這個概念被首次提出，因為百度本身有相關需求，便嘗試引入Mesh的概念，於是內部自研了一套遵循社群 Mesh 概念的透過 Golang 開發的包含控制面和資料面的 BMesh 系統，在搜尋服務前端服務上線，不過沒有在特別多業務推廣；直到2019年，百度內部做了擁抱開源的決定，希望基於社群方案：Istio + Envoy 進行深度定製開發。
目前，百度核心業務線已全面完成了微服務架構改造，基於微服務構建了包括百度資訊流、百度App、百度地圖、百度小程式等核心業務的應用架構；微服務模組大量採用C++、Golang、PHP、Java等語言來開發和快速迭代；而且百度長期積澱了許多自研和二次開發的開源微服務框架：bRPC、GDP、ODP、SpringCloud等， 這些微服務間通訊除了標準的HTTP、GRPC協議外，廣泛地採用了大量的私有協議，比如baidu-std、Nshead等。
所以百度的核心業務線形成了多開發語言、多開發框架和多通訊協議構成的複雜的異構系統，傳統的基於入侵的微服務框架已經不能滿足這種複雜系統的服務治理要求——升級Mesh迫在眉睫！
在升級之前，有一些重點問題需要綜合考慮：
- 改造成本
- 各種各樣的微服務框架網格化改造和適配
- 各種各樣的通訊協議支援
- 效能問題和資源問題
- 因為Sidecar的引入，微服務間的通訊鏈路變長，業務延遲增加，甚至某些敏感業務無法接受Sidecar帶來的額外損耗。
- Sidecar自身會消耗資源，增加業務的成本。
- 規模問題
隨著Sidecar規模的增長，開源的控制平面計算開銷變大，導致Mesh配置下發時間變長，甚至無法工作。
3. 百度服務網格整體方案
如何解決這些問題？
在服務網格的技術選型問題上，百度選擇了開源的 Istio + Envoy 作為網格控制面和資料面，在其上進行深度的定製和開發。
但是 Istio + Envoy 的社群方案和K8S的技術生態進行了深度繫結。而在百度內部有自研的基礎技術平臺，包括對標 K8S 的 PaaS部署系統、Trace系統、監控系統和Naming系統等，這些都是業務模組包括 Istio + Envoy 部署執行的依賴系統。所以，將 Istio + Envoy 和內部依賴系統進行了深度的技術融合，打通了公司基礎技術平臺，降低了業務接入成本。
在資料面和控制面之上，又建設了 Mesh 控制中心，即微服務的配置管理中心，提供服務治理和運維的統一入口；基於底層架構的建設，向上提供了流量複製、負載均衡、過載保護、流量映象等系統能力。
這些系統能力在核心業務的服務治理、運維止損、容量管理、混沌工程和服務可觀測等場景中得到了應用，並且取得了不錯的業務收益和使用效果。
那麼，實現這樣一套系統，我們需要解決哪些問題呢？
3.1 網格接入最佳化方案
首先是流量劫持方案的問題，在社群方案中，一般是透過Naming Service（如：DNS服務）獲取到目標 Server 的真實地址。同時，透過配置 iptables 進行流量劫持，將客戶端的請求直接轉發給 Sidecar。但是，當 iptables 配置有大量匹配規則時有效能的問題，而且無法動態修改客戶端訪問服務端的行為，如：重試、超時等，且沒有辦法平滑的在 Mesh 和非Mesh 模式切換。
在百度內部採用了另外一種劫持的方案，首先 Sidecar 啟動的時候會將自己註冊給Naming Service（在百度內部叫BNS），在框架經過 Naming Service 查詢的時候，框架的內部整合了一個和 Naming Service 對接的小模組，這個小模組從 Naming Service 拿到的就是 Sidecar 的地址，動態的改變了目標伺服器的地址，直接將目標的IP變成 Sidecar 的地址（loopbackIp），同時，還會覆蓋客戶端的重試、超時等引數，這一切對業務來說都是無感的。
這樣就可以很便捷的調整客戶端服務治理引數、切換Mesh和非Mesh模式。因為如果Sidecar掛掉了，會在Naming系統裡把自己解除註冊，這樣上游的框架會自然而然的訪問下游服務的真實地址了。
第二，對自有協議的支援的問題。在社群裡面是支援不同的協議，比如HTTP、Thrift、Dubbo，但會涉及重複的開發。如果要支援一個新協議，可能需要重新實現超時控制、重試、請求路由、流量映象等。百度內部將這通用的部分單獨剝離出來：於是支援一個新的協議變得簡單起來，我們只需要將下圖中綠色的部實現簡單的Codec，即：將這個協議進行編解碼就可以，大大降低開發支援新協議的成本。
最後是對多框架和協議的支援問題。Mesh 對協議的要求包括具有請求特徵資訊擴充套件的能力，可以實現請求特徵路由；具有元資訊擴充套件能力：能夠在框架和 Sidecar 間傳遞資訊（如：一致性雜湊的Code），在上下游服務模組間傳遞資訊（如：TraceID，SpanID)
內部傳統的老協議如何接入 Mesh？透過框架實現協議升級，用可擴充套件的 baidu-std 協議封裝老協議進行傳輸，到達下游服務之後再由框架拆解開報文。
3.2 服務網格效能最佳化
針對代理架構如下圖所示，社群方案是從APP1進入 Sidecar 再到下游服務的 Sidecar再到APP2，這裡面經過了兩次 Sidecar，會有兩倍延遲或者兩倍資源開銷，在百度內部可能並沒有這麼複雜，沒有對這個很高要求的場景，多數情況下只經過 Sidecar一次。比如，APP1經過Sidecar後直接到達了APP2，並沒有再次經過 Sidecar。
另外一種模式，內部很敏感的業務並不希望經過 Sidecar。比如，APP2透過框架直接訪問到APP3，並沒有經過任何的 Sidecar。下圖左是經過一次 Sidecar 的模式（在百度內部稱為一跳）這是透過 NamingService 註冊再訪問本地IP。而下圖右 Proxyless 模式 Sidecar 會將自己服務的引數以及目標服務的IP透過 NamingService 下發給框架，框架擁有下游服務的IP以及服務治理的全部引數，可以直接完成訪問。
針對資料面效能方面的最佳化，社群的 Envoy 在效能方面並不是特別優越，所以。百度整合了一個 bRPC 開源框架作為核心去轉發流量，在上層 bRPC 框架依然相容了xDS協議（服務治理引數的協議），便於同步社群的新設計、新變化，做到了魚和熊掌都可以兼得的效果，經過升級核心的版本以後，在各個延時、長尾以及CPU使用率上都有很好的最佳化。
最後是控制面效能最佳化，控制面在沒有配置 Sidecar CRD 的情況下，會下發所有的服務列表，我們透過內部的關鍵路徑最佳化，實際上只會下發 Sidecar 關注的下游，大大減少控制面對配置計算以及下發的效能最佳化。
經過上述改造後，最後就完成了百度內部對 Mesh 的整體最佳化和修改。
4. 業務收益及案例啟示
經過上圖所展示的高階服務治理策略，在 SLA 以及故障恢復時間上都有很高的最佳化。在此基礎上還有全域性的智慧容災系統，可以最佳化高階服務策略引數。
服務可觀測性方面，可以透過框架傳遞 TraceID、SpanID 等，再透過 Sidecar 再採集到內部的 Trace平臺和監控平臺，可以在內部的監控平臺上展示 Trace，方便監控以及進行故障的排查和追蹤。
自動止損方面，整個系統結合內部的監控平臺，監控平臺將這些指標儲存在自己的平臺上，穩定性預案平臺根據監控平臺的指標異常進行實時調參，執行流量降級、切機房、切流等。同時這個效果會實時反饋給監控平臺，包括穩定性預案平臺持續的對系統進行調參，形成閉環。
混沌工程方面，會透過控制平面下發給故障任務，然後控制平面將命令下發給Sidecar，Sidecar 透過這個命令注入一些延遲，這樣去影響內部的系統，內部系統同樣會產生監控的指標，這些指標再上報給監控平臺，然後混沌平臺再透過這些指標評估系統的彈性以及容錯等。
系統容量評估方面，容量平臺可以發起壓測任務，這個任務對接到控制平面。如：由控制平面下發切20%的流量到某下游服務，對它進行壓測，實時產生的指標上報給監控平臺，容量平臺對監控平臺的指標進行實時評估。
百度內部業務接入情況：
- 百度App、資訊流、百度地圖、智慧小程式、好看影片等產品線
- 接入例項十萬級
- 每天處理請求數千億次
業務接入收益：
- 大幅提升核心鏈路的可用性和系統整體容災、防雪崩能力
- 大大降低治理迭代成本、服務治理迭代週期從數月縮短到天級別
- 解鎖服務可觀測，自動止損，容量探測等高階場景能力
最後，喬元才總結了透過接入Mesh服務網格得到的一些啟示：
- 服務網格不是微服務治理的銀彈
- 完全無入侵的，支援所有協議，所有框架和所有治理策略的 Mesh 方案是不存在的
- 大規模工業化落地的平滑、穩定可控接入方案，涉及到大量對已有服務治理元件的相容升級和改造
- 服務網格確實實現了業務邏輯和服務治理架構的解耦，解鎖了很多新能力
- 服務網格結合可觀測、故障止損、混沌工程，容量管理等場景化，才能發揮出最大價值