服務網格在百度核心業務大規模落地實踐

【百度雲原生導讀】服務網格（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迫在眉睫！

在升級之前，有一些重點問題需要綜合考慮：

1. 改造成本

各種各樣的微服務框架網格化改造和適配
各種各樣的通信協議支持

2. 性能問題和資源問題

因爲Sidecar的引入，微服務間的通信鏈路變長，業務延遲增加，甚至某些敏感業務無法接受Sidecar帶來的額外損耗。
Sidecar自身會消耗資源，增加業務的成本。

3. 規模問題
隨着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使用率上都有很好的優化。