博客 / 詳情

返回

百度視覺搜索架構演進實踐

本文深入探討百度視覺搜索在快速發展的業務及技術背景下,如何通過持續的技術創新和架構升級強化自身的競爭力和適應性,支撐業務健康高效迭代。本文介紹了我們如何通過技術棧升級、架構能力提升以及穩定性建設,來實現全鏈路架構的演進。藉助Golang、百度自研GDP開發框架和ExGraph圖化引擎,我們對視覺搜索展現架構進行了全面重構,並重新定義了視覺搜索全系統通路上的模塊職責和分層邏輯,開展了一系列系統收斂內聚優化。此外,我們還建設了配套穩定性基礎設施,確保系統的高效運行。期望大家能有所收穫和借鑑。

01 背景

視覺搜索是基於圖像識別和深度學習技術實現的圖像搜索應用,區別於傳統文本方式搜索,接受用户拍照/上傳圖片輸入,識別圖像特徵和內容,獲取圖片內容相關的檢索結果。目前廣泛應用在學習、動植物、商品等領域,滿足用户對圖片的認知、購買等多元需求。

圖片

△視覺搜索業務概覽

隨着產品的高頻迭代和規模迅速拓展,視覺搜索架構需要通過持續的技術創新和架構升級,強化自身的競爭力和適應性,以應對業務和技術的一系列新挑戰。具體手段為:

  • 【技術棧更新】現有展現架構採用PHP開發、HHVM運行,隨着HHVM基礎設施停止維護,以及對異步/多線程等功能支持的侷限性,我們需要探索下一代框架和語言,以持續滿足服務高可用性、及AI大模型挑戰下的新產品迭代要求
  • 【架構能力升級】隨着業務高速迭代,要求系統架構也必須隨之升級以不斷適配新的業務需求,當架構通路中開始出現龐大的單體應用模塊和日益複雜的模塊交互,需要及時開展架構重構/優化,保障業務健康可持續迭代
  • 【穩定性保障】穩定性方面,隨着技術棧和架構的升級,配套的基礎技術建設也當隨之加強,從測試流水線、監控攔截、線上監控、定位工具等各環節持續健全穩定性能力,從而高效實現問題閉環,確保服務穩定性目標得以實現

02 解決方案

2.1 整體設計

本項目從展現架構重構、系統分層改造、基礎技術建設等多個角度出發,結合圖化思想,對現有視覺搜索整體架構進行全鏈路重構優化,同時一方面接入搜索內部公共技術棧,另一方面完善視覺自有技術基建,建設如下全系統圖:

圖片

△視覺搜索全系統圖

  • 展現架構重構
  • 接入層:開發視覺BFF(Backend For Frontend)接入模塊,提供多端統一適配&動態路由解決方案,提高系統可擴展性和可維護性;
  • 技術棧:PHP+HHVM轉向Golang,支持併發/異步/流式交互能力,提高系統性能;同時,基於百度內部的Golang開發框架和搜索內部自研的ExGraph圖化服務,對展現模塊進行徹底重寫,以DAG圖的方式描述業務流程,算子化實現業務細節和基礎Lib,並保障算子的可複用性;
  • 全系統改造:
  • 分層:明確視覺整體架構分層及模塊定位,對檢索通路中現存龐大單體應用解耦拆分,實現展現層與檢索層單次請求多路召回,降低業務與數據耦合,簡化架構通路交互;
  • 協議:統一召回數據及模板展現數據協議,提升研發效率;
  • 穩定性建設:
  • 流水線:健全全模塊持續集成與持續交付流水線能力;
  • 標準化:拒絕重複造輪子,複用搜索內部配套運維與問題閉環生態環境,統一基礎技術棧,降低運維成本;同時基於Prometheus+Grafana監控解決方案重建業務監控系統,保障核心穩定性。

2.2 詳細設計

2.2.1 接入模塊建設

通過建設視覺BFF(Backend For Frontend)模塊提供多端適配問題解決方案,提高用户跨設備使用業務的無縫性和一致性,並且使得業務需求的開發能夠更專注於需求自身邏輯,實現高效接入和迭代。為滿足上述要求,視覺BFF整體流程如下:

圖片

△視覺接入層整體流程

  1. 服務初始化:系統首先完成服務啓動,初始化App及依賴詞典、服務等;
  2. 多端適配:接收到用户實時流量請求時,首先完成對不同前端應用輸入數據協議的解析適配,然後執行中間件,識別用户信息、設備信息,完成抽樣染色、功能開關初始化等;
  3. 路由分發:根據多端適配信息,以及流量分發配置規則,動態調整負載均衡和API響應;
  4. 結果輸出:收集下游返回數據,適配各端私有化協議,確保業務數據傳輸到不同前端應用的安全性與一致性。

2.2.2 展現模塊重構

視覺展現模塊的主要職責是使用圖片請求檢索系統獲取結果,基於檢索數據,完成不同業務場景下的數據解析和組裝渲染,最終在多終端上呈現給用户豐富多樣的結果滿足樣式。本小節將主要介紹使用Golang對視覺展現模塊進行圖化改造和重寫的實現方案。

圖片

△視覺搜索展現模塊架構圖

  • 框架選型:採用百度內部基於Golang實現的業務開發平台GDP(Golang Develop Platform),具備完善的RPC Server和RPC Client能力,主要用於API、Web以及後端服務開發。
  • 模塊拆分:解決原展現模塊自身複雜度的問題,拆分獨立功能,如上文所述的BFF接入模塊,讓UI聚焦到具體的業務邏輯實現,忽略不同端或者場景不同協議以及不同參數等的輸入輸出問題;
  • 邏輯分層:為了保持UI模塊有清晰的邏輯分層,便於業務長期健康迭代和維護,將UI內部按照功能邏輯定義分層結構,在後續迭代裏遵循分層規範,嚴格控制相應的代碼和邏輯管理;
  • 圖化改造:抽象和封裝公共算子及業務算子,簡化業務主幹邏輯,通過圖化引擎編排和調用算子實現需求->圖->算子->Lib庫/基礎設施的層次調度:

圖片

△檢索流程圖化改造前後對比圖

  • 圖化引擎選型:採用百度搜索展現團隊自研圖執行引擎ExGraph,提供了一套利於研發人員和機器理解的圖語言,該圖語言將算子作為基礎單位,通過串行組、並行組、子圖、條件算子、switch算子、中斷、等待等機制,能靈活適配複雜的業務流程;
  • 公共算子:可在不同業務圖流程中靈活配置調用的功能算子,目前已實現圖片上傳,緩存管理,風控,檢索請求,渲染等,一處開發,多處快速配置即用;
  • 業務算子:如特定的數據解析、字段填充,下游請求構造等;
  • 策略組:為了使算子邏輯清晰簡潔,通過策略組的方式來管理個性化場景,如參數處理策略組、意圖選擇策略組、不同垂類的整頁展現策略組等;
  • 公共Lib庫:封裝一些業務邏輯無關的開發常用功能庫,例如規則引擎、數據結構容器(如集合、有序map以及字符串常用方法等)、圖片下載工具等,提高代碼的可複用性及研發效率。

2.2.3 系統分層改造

在前2小節中闡述了對視覺接入和展現模塊的圖化重構及技術棧升級,為服務性能、技術儲備、研發效率等方面帶來了一定程度的提升,隨後我們轉向全系統架構通路,着手解決如下問題:

  • 模塊交互複雜:一次用户請求過程中,展現模塊與檢索模塊多次交互,不僅增加了網絡耗時,也增加了線上問題定位的難度,同時造成線上服務間相互依賴,甚至請求成環等問題;
  • 檢索系統複雜:視覺在線檢索系統承接了數十業務場景下的多輪調度、觸發、召回等檢索邏輯、圖片處理等策略邏輯、以及數據整合等展現邏輯,是視覺架構中最為龐大的單體應用,隨着業務日益複雜化和大模型應用場景崛起,檢索系統開始面臨架構設計、模型管理、可擴展性、流式能力、高速迭代等方面的多重訴求和挑戰;
  • 數據適配複雜:缺少業務標準數據定義,以模板驅動數據選擇,數據通路可複用性較差,展現模塊中字段適配歸一的邏輯佔比較高。

首先,我們梳理了全鏈路模塊內部邏輯,明確各模塊的職責功能,重新制定模塊間的交互接口協議及模塊內的邏輯分層,在此基礎上,完成了對檢索模塊中業務展現、檢索及策略邏輯的解耦重構,主要工作包括以下幾個方面:

圖片

△視覺全系統分層改造前後對比

  1. 展現服務分層改造:模塊內部定義邏輯分層,降低模塊代碼複雜度,提升可複用性,同時提高系統的異步執行和並行化能力;
  2. 檢索接口收斂內聚:檢索服務底層框架升級,採用圖化思路重寫,以算子化的方式重新拼裝組合不同場景及不同下游的邏輯調度,對上游提供收斂後的統一檢索接口,一次檢索請求即可拿到全部召回結果和策略信號;
  3. 龐大單體應用解耦:重新分解和認領龐大單體應用中的功能,按照系統分層完成對應邏輯的遷移重構,最終完成目標模塊解耦下線,提升系統效能,優化機器資源;
  4. 數據協議標準化:統一召回數據規範,並制定標準組件模板協議,以數據驅動展現模板選擇;同時增加特徵通路和日誌通路,去除數據透傳模塊依賴。

2.2.4 穩定性建設

隨着視覺架構和各模塊的演進改造,我們也梳理了配套的質量保障技術設施,查漏補缺,完善感知>處置>預防>根因分析覆盤>巡檢各環節的穩定性基建,從而保障服務能夠提供穩定可靠的用户效果。

故障感知:

首先,GDP框架提供了一套基於Prometheus的標準化採集&監控解決方案,能極大降低傳統日誌採集+解析+監控配置+可視化的學習和管理成本,它定義了統一的指標規範,可由業務方按需調用接入。基於該標準化監控方案和業務核心訴求,我們建設了如下核心指標故障感知指標:

上述指標的監控報警生效在研發、測試、上線全流程,快速發現故障,確保各階段業務效果符合預期。

故障處置:

長期以來,經過對線上各模塊錯誤日誌的治理和代碼重構優化後,線上日常故障更多的集中到了機器/實例/應用等容器管理的健康狀態波動上,因此,我們通過ALM(Application Lifecycle Management)機制,依據健康探活、日常quota及日常採集指標,自動化實現實例遷移以及模塊容量彈性伸縮管理,提升系統的自愈能力,同時提升資源整體的分配率和使用率。

根因分析覆盤

通過ALM自愈機制我們實現了問題實例的快速感知和自動遷移,但在日常運維中,不易做到快速介入人工分析,導致現場丟失,以至於cpu/mem/協程等指標異常多歸於偶發問題。為了有效實現問題排查和閉環,搜索團隊基於Go語音內置pprof性能工具及監控平台,自研pprof自動化採集系統Keeper,在對應報警事件發生時,通過回調觸發pprof文件採集及上報,能有效保留問題現場,讓業務做到對故障根因的分析覆盤。

輔助平台工具

  • 調研平台:全模塊建設線下仿真環境,一鍵搭建/升級環境模塊,快速滿足環境交付需求,提高業務評測、開發聯調效率;
  • Debug平台:平台化模擬端到端請求,可視化展現全鏈路模塊日誌,快速實現問題復現和定位;
  • Trace平台:採集業務核心模塊,自定義日誌切割規則及鏈式日誌關鍵字,條件化快速查詢線上日誌,提高定位效率;

03 總結

本文介紹了視覺搜索架構為了應對業務和技術發展帶來的一系列挑戰,從技術棧更新、架構能力升級、穩定性保障等方面入手,採取了全鏈路架構演進的技術應對方案。基於業務特點,結合百度內外的技術設施儲備,我們採用Golang+GDP開發框架+ExGraph圖化引擎重構了視覺展現架構,將其拆分為接入模塊及展現模塊,降低多端數據與業務邏輯耦合度;然後重新定義了視覺搜索架構分層及模塊功能職責,並對展現模塊及檢索模塊進行了數據協議統一、功能收斂內聚、邏輯分層改造工作;最後完善了業務感知>處置>預防>根因分析覆盤>巡檢各環節的穩定性基建。本文旨在將視覺搜索架構演進的思路和方案分享給大家,希望對面臨類似挑戰的業務有所借鑑,未來我們仍將持續優化業務系統和性能,為大家提供更好的產品服務。

————END————

推薦閲讀

智算基石全棧加速,百度百舸 4.0 的技術探索和創新

HelixFold 3 全球首個完整復現 AlphaFold 3,百度智能雲 CHPC 為人類生命探索提供算力平台支撐

百度搜索結果波動的極致治理

PaddleX圖像分割賦能醫療領域篩查檢測,打造智能醫療診斷系統

百度智能雲x️石家莊交管局,大模型打造全時在線數字交警

user avatar
0 位用戶收藏了這個故事!

發佈 評論

Some HTML is okay.