百度搜尋展現服務重構：進步與最佳化

來源：百度Geek說

作者 | 瞭東

導讀 

introduction

本文將簡單介紹搜尋展現服務發展過程，以及當前其面臨的三大挑戰：研發難度高、架構能力欠缺、可複用性低，最後提出核心解決思路和具體落地方案，期望大家能有所收貨和借鑑。

全文4736字，預計閱讀時間12分鐘。

GEEK TALK

01

背景

百度搜尋展現服務的主要職責是請求檢索系統獲取結果，並依次進行模板選擇、實時摘要補充、資料適配和結果渲染，將檢索結果能以豐富多樣的形式精準地展示給使用者。在初期，這項服務基於C語言進行開發，迭代效率不盡人意。隨著產品的迅速迭代和業務的不斷擴充，研發效率問題逐漸凸顯，為了解決這一瓶頸，搜尋展現服務進化為由PHP開發、HHVM執行的服務。目前，搜尋展現服務由數十個產品線、上百個研發RD共同參與研發，承載了數百個精細化的業務展現策略。然而，隨著搜尋業務的日益複雜化和生成式大模型的崛起，搜尋展現服務也開始面臨研發難度增大、架構能力不足和複用性低等多重挑戰。具體表現如下：

【研發難度高】：搜尋展現服務基於過程管理，邏輯複雜，多個策略框架分佈於程式碼的各個階段，不能滿足多業務對於簡化管理、易於擴充套件的效率訴求

【架構能力欠缺】：hhvm基礎設施已經停止維護，對於非同步/多執行緒等功能的支援較為有限，流式能力的缺失使其無法滿足生成式搜尋等需求，因而不能滿足服務穩定性和新產品需求迭代的要求。

【可複用性低】：搜尋展現層主要服務與通用搜尋、垂類搜尋等。目前，通用搜尋和垂類搜尋之間目前缺乏合理的架構設計，這導致相同的需求在通用搜尋和垂類搜尋中都需要進行重複的開發。

GEEK TALK

02

解決方案

2.1 整體設計

2.1.1 核心思路：

降低研發難度：根據展現層特點，透過設計實現圖管理引擎，將展現功能以運算元的粒度進行拆分，單個運算元的邏輯簡單清晰、業務方把工作聚焦在功能（運算元）和需求，而非應用整體，同時將搜尋展現服務的過程處理升級為DAG圖處理，降低流程管理的複雜度。透過實現運算元->圖->需求的層次管理，推動搜尋展現服務的過程研發模式從程式導向到面向功能、面向業務。

提升架構能力：從PHP+HHVM轉型GO，基於百度內部GO開發框架搭建搜尋展現服務，獲得更好的效能和更高的併發處理能力。同時對於非同步/協程/流式互動能力支援成本更低。

提升可複用性：透過抽象公共運算元和實施基礎Lib共建，提高程式碼的可複用性和可維護性。公共運算元可以在多個搜尋展現服務中複用，避免了重複開發和維護的代價。基礎Lib可以提供通用的功能和工具類，方便開發人員快速開發和維護程式碼，減少重複開發和出錯的可能性。

△搜尋展現層架構圖

2.1.2 基礎設施

GDP(Go Develop Platform)：百度內部基於go實現的業務開發平臺，具備完善的RPC Server和RPC Client能力，主要用於API、Web以及後端服務開發。

ExGraph: 百度搜尋展現團隊自研圖執行引擎。

圖：設計了一套簡單的圖描述語言，不借助任何工具，rd可輕鬆學習並據此瞭解模組執行邏輯的全貌，降低接手難度

運算元：設計簡單的介面，遮蔽實現細節，rd實現運算元介面即可執行

執行：靈活設計了序列組、並行組、子圖、條件運算元、switch運算元、中斷、等待等機制，以適配複雜的業務流程

效率工具：實現了程式碼生成器、腳手架等效率工具，可快速建立應用

Datahold：百度搜尋展現團隊自研資料管理器，主要解決模組資料（比如配置、字典）依賴和載入問題。具備如下能力：

• 支援熱載入，後臺監聽並解析變更檔案後切換到前臺使用；提供通用字典、配置解析器，同時支援自定義檔案解析器

• 支援透過配置完成資料物件自動註冊、載入和解析，有效管理大型服務中配置/字典不可丟、解析出錯及時報警感知等

• 支援rd線下環境一鍵部署模組依賴遠端資料，提升研發階段環境部署效率

公共lib：此外基礎設施層還提供了udai（遠端資料統一訪問cgo擴充套件）、百度自有簽名等等展現團隊公共lib，公共Lib建設有統一準入標準，避免重複造輪子，提升研發效率。

2.1.3 公共運算元

將搜尋展現通用邏輯抽象為介面，基於圖引擎提供公共運算元，實現一處開發，通用搜尋、垂類搜尋等多個應用共同使用。目前已經實現抽樣、適配、降級、限流、檢索請求、落地頁點出、渲染等數十個公共運算元，開箱即用，快速支援搜尋新展現應用搭建。

2.1.4 應用層

透過公共運算元、各服務自有展現運算元搭建執行圖，實現應用業務邏輯。當前搜尋展現服務包含通用搜尋展現服務、垂類搜尋展現服務、生成式搜尋展現服務等。

2.2 詳細設計

通用搜尋相比垂類搜尋等業務更具複雜性，本章節將以通用搜尋展現服務為例，具體介紹其重構遷移go的落地方案。

△通用搜尋展現服務重構前後對比圖

在重構遷移過程中我們主要面臨兩個難點：

難點1：前文已提到通用搜尋展現服務是一個數十個產品線100+RD共同研發的模組，展現策略組1&2&3共有600+業務展現策略，每天平均有4+策略迭代上線，在重構遷移落地過程中，首要解決的問題就是：如何相容遷移和現有業務迭代效率？如何協同眾多業務線遷移？

難點2：搜尋展現服務業務邏輯非常複雜，重構專案如何保障使用者效果、商業收入和服務穩定性。

對於難點1，主要透過架構業務解耦、平滑遷移機制這兩個手段解決；對於難點2將從研發、測試、上線全流程穩定性保障。接下來將詳細介紹這兩個部分內容。

2.2.1業務解耦&平滑遷移

保障遷移和現有業務迭代效率，並協同多產品線進行業務展現策略遷移核心手段：解耦架構和業務展現邏輯，架構遷移部分先行遷移go，業務展現策略依舊基於php執行，架構邏輯遷移過程中不阻塞業務迭代，儘量避免php&go兩個版本同時開發相同的業務邏輯。設計一套機制支援業務展現策略按業務線獨立遷移到基於go的搜尋展現服務上，並將整個複雜遷移過程拆分成四個階段有序進行，最終實現整體專案目標。

第一階段：架構部分圖化遷移go+展現策略服務化

將限流、引數處理、檢索請求、廣告檢索請求、http-header渲染等架構邏輯程式碼基於GDP+Exgraph圖化遷移go，基於go的通用搜尋展現服務完成檢索資料統一處理之後，再請求基於php的展現策略服務進行業務展現邏輯。這樣即可以保證迭代相對不頻繁的架構邏輯先行遷移go，為後續展現策略遷移做好基礎，同時也能保證迭代頻繁的展現策略依舊可以按原有研發模式繼續迭代。

第二階段：非同步摘要請求全量遷移

首先回答下非同步摘要是什麼。

檢索系統往往為了考慮計算資源和響應速度，會在各個子系統內部設定cache，cache失效時間至少都是分鐘級別，部分場景甚至達到天級別。對於部分需要秒級別就能更新的展現元素，比如搜尋結果裡需要展現影片播放量、文章點贊數量，以及使用者是否對這條結果進行點贊等，cache就沒有那麼友好了。非同步摘要因此誕生，檢索請求返回之後基於檢索結果請求高時效摘要服務，摘要請求是非同步完成的，和普通展現策略併發，既實現了實時摘要補充，又避免了使用者響應速度的退化。

為了避免隨著展現策略逐漸遷移go，非同步摘要請求時間可並行時間縮短，引入旁路系統。非同步摘要策略數十個，本身迭代相對普通展現策略較不頻繁，請求整體一起遷移go，非同步摘要請求成功寫入旁路系統，執行完所有普通展現策略（無論是遷移到go執行，還是保留在php上執行），基於PHP的策略服務透過旁路系統獲取所有非同步摘要並執行實時摘要補充。引入旁路系統本身也需要通訊開銷，透過以下手段降低：

• 透過邊車化實現旁路服務降低遠端通訊開銷

• 基於go展現服務不對非同步摘要進行解析，將原始序列化結果寫入到旁路系統，基於php服務獲取資料進行解析。可以有效避免go/php展現重複反序列化資料帶來開銷。

第三階段：展現策略遷移

協同各個產線線完成展現策略組1、展現策略組2、展現策略組3遷移到基於go的搜尋展現服務。該階段支援產品線按策略粒度、按業務小流量遷移；同時新展現策略（不包括非同步摘要策略）可以直接基於go的搜尋展現服務開發。

遷移準則：按展現策略有無依賴分類遷移。依賴常見場景：策略執行依賴其他非本業務的展現策略先執行，這種場景必須被依賴策略先遷移；策略內部依賴了架構能力，但這部分能力沒有遷移go等。

遷移優先順序：

（1）優先遷移無依賴的展現策略，可以獨立遷移開發、實驗、推全

（2）對於存在依賴的展現策略，協同被依賴方一起完成遷移

第四階段：全量遷移

整體完成非同步摘要策略遷移、渲染、後置任務遷移。

該部分邏輯迭代也相對不頻繁，為什麼不提前遷移go?

主要限制因素是響應速度。如果將基於php展現策略服務發回給基於go的展現服務，再進行渲染、後置任務，php->go會再增加一次序列化、反序列化以及通訊時間，會造成速度退化，這部分速度退化遷移go之後無法帶來速度最佳化彌補抵消。

2.2.2 全流程穩定性保障

通用搜尋展現服務重構專案的使用者效果、商業收入和服務穩定性主要透過全流程穩定性保障。全流程穩定性主要包含研發、測試、上線穩定性保障。

研發保障

遷移過程不僅僅是簡單功能平遷，通用搜尋展現服務已經迭代了數十年，本身存在諸多不合理設計，如資料冗餘、歷史飛線邏輯較多、程式碼複用低等，我們基於以上問題進行資料治理、飛線包袱清理、重新抽象設計公共運算元等。這些對研發質量提出了更高的要求，一方面透過單元測試和自動化流水線測試（資料diff&UI-DIFF，測試保障介紹）保障程式碼質量，另一方面透過日誌打點分析對歷史包袱進行提前下線避免不合理、不必要的遷移。

測試保障

功能測試：

資料Diff：協同qa建設自動化資料diff功能，錄製線上請求進行回放，將關鍵資料如檢索請求、廣告請求、輸出給渲染服務的資料等等進行全面自動化例行資料diff，透過資料diff發現潛在問題，累計發現並消除上萬資料diff。

UI-Diff: 搜尋結果頁結果型別眾多，比如天氣阿拉丁、股票阿拉丁等等，共有上千個資源型別，每種資源型別都有各個的展現模板。效果迴歸成本高且難度大，根據資源展現量大小作為優先順序，利用ui-diff平臺（html頁面畫素級diff）自動挖掘線上query進行基線和策略線自動化ui-diff，重點關注diff差異超過閾值的效果問題，透過這種方式累計發現並修復40+效果類問題。

端到端測試：資料diff&UI-diff這兩個自動化測試手段已經能夠覆蓋絕大多數效果類場景，除此此外，QA對搜尋重點場景比如落地頁跳轉、翻頁、廣告效果等人工效果測試迴歸。透過自動化測試+人工效果測試保障重構改造後的展現效果。

穩定性測試：透過引流線上流量進行長時間壓力測試，模擬線上執行環境，保障服務線上穩定性。

效能測試：透過效能火焰圖發現系統效能熱點並最佳化點；通用線上例項峰值qps進行效能測試以及極限壓測獲取服務極限qps，提前預估線上資源容量是否充足，響應資料是否存在退化。

上線保障

上線階段穩定性保障主要手段包括：上線前資源/響應時間預估等進行穩定性評審、監控&報警、降級、內測、全網小流量等。

GEEK TALK

03

總結

本文介紹了搜尋展現服務發展過程以及當前面臨主要挑戰：研發難度高、架構能力不足、可複用性低，然後提出基於圖執行引擎+公共運算元+重構遷移go方式解決上述問題，最後基於通用搜尋展現服務詳細闡述了方案的落地。本文旨在透過將搜尋展現服務重構思考分享給大家，期望大家有所借鑑和收穫，當然也可能存在不足之處，也期望大家留言共同探討。