作者 | 瞭東

導讀 

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

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

01 背景

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

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

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

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

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，提前預估線上資源容量是否充足，響應數據是否存在退化。

上線保障

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

03 總結

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

搜索技術平台研發部正在招募 AI 研發工程師，歡迎感興趣的同學投遞簡歷至linzecheng@baidu.com

——END——

推薦閲讀

百度APP iOS端包體積50M優化實踐(七)編譯器優化

百度搜索內容HTAP表格存儲系統

大模型時代，“人人可AI”的百度開發者平台長什麼樣？

數十萬QPS，百度熱點大事件搜索的穩定性保障實踐

百度搜索萬億規模特徵計算系統實踐