導讀
百度垂搜架構歷經多年發展，內部沉澱了多個開發者平台\工具，涉及覆蓋了搜索系統的多個階段模塊，如何高效地串聯繫統全流程，為業務提效提質，可靠的工程化基建和更上層的抽象設計是關鍵。本文闡述了百度垂搜一站式研發平台（經天）的思考和探索過程，以及如何通過FaaS機制和SaaS服務產品化來為業務提效提質。
01 背景
百度垂搜架構團隊為數十個業務線的上百個搜索場景提供全鏈路的技術支持，經過多年的發展，內部已經沉澱了多個開發者平台\工具，覆蓋了檢索、展現、策略、離線等多個模塊。伴隨着眾多垂類業務的持續深耕發展，自定義的開發場景和接入需求越來越多，在此過程中出現了以下問題：
- 架構研發維護成本高：研發平台分散，缺乏完善的工程化基建和模型抽象，很多基礎能力沒有快速複用的機制，重複研發成本高；歷史平台技術棧落後，前後端邏輯分離不徹底，長期維護成本高。
- 業務接入學習門檻高：搜索系統鏈路長、模塊數量多、功能類型豐富、上下游連接複雜，歷史平台沒有從全流程視角去規劃建設，研發入口分散不統一，業務接入研發流程複雜，學習使用門檻高。
02 思路與目標
那有沒有一些合適的方案，既能有效降低架構自身的研發維護成本，同時又能給業務方的研發學習門檻流程提效？進一步深入來看，一方面，需要我們建設更高效的工程化基建，降低架構側的研發、運維成本。另一方面，需要將面向業務方的搜索研發環節更好地收斂、抽象、建模，降低業務研發的使用及迭代門檻，端到端地為業務方提供一站式服務。
在平台易用性、基建方面，業界目前對於工程化應用尤其是Web端的應用場景，主要聚焦於通過使用Serverless技術方案來低成本、快速可靠地完成業務需求，比較典型的有AWS Lambda、Google Cloud Functions、阿里雲FC、百度雲CFC等，在工程化場景中Serverless方案可以快速完成業務迭代和服務部署，有效降低運維負擔，提升開發效率。
在檢索流程方面，我們通過對常見場景的抽象與分析，發現很多業務需求存在大量通用共性之處，我們可以對那些通用、高頻使用的檢索流程進行可視化建模，沉澱建設各類標準化的搜索服務SaaS產品，並通過DAG可視化、低代碼等平台化的方式將服務提供給業務方，讓業務方少寫甚至不寫代碼。
基於以上思路，我們建設了垂搜的一站式研發平台（經天），其主要從兩大目標入手：
- FaaS機制：讓架構研發用户僅需聚焦其業務邏輯的實現，由平台側統一提供在線調試、上線發佈、容量管理、運維管控等能力。從聚焦於服務研發轉變為聚焦於函數開發，全面提升平台類工程應用的研發效率。
- SaaS服務：將一系列基礎搜索產品加配置組成的解決方案，封裝沉澱為針對特定場景的搜索套餐，提供標準化業務接入、迭代的流程，提升業務的接入效能。
03 一站式研發平台（經天）的設計與實踐
3.1 “一站式”應用中心
經天的目標之一是“統一”，統一整合、收納存量的各類平台工具，隨着各方向能力在平台上的持續擴展，用户勢必會面臨一個問題：我如何快速找到我所關心的功能？
針對這個問題，我們考慮在產品入口層面使用“千人千面”的方案，不同的用户角色默認初始化不同的導航類目，比如：研發用户展現各類研發、迭代工具的入口，而運營用户展現各類運維報表的快捷導航。用户可以通過收藏置頂等方式，自定義其關心的能力入口。
通過一站式應用中心，我們將各能力入口統一、聚合在了一起，用户可以快速概覽目前管理系統提供的所有能力。
3.2 Faas機制
我們通過調研發現百度智能雲已經對外提供了函數計算產品CFC，其提供基於事件機制，彈性、高可用、擴展性好、極速響應的雲端無服務器計算能力，其支持多種語言及函數觸發器，滿足多樣化的事件觸發場景。
經過深入考察後，我們最終選擇百度智能雲函數計算CFC作為經天FaaS的底層基座，在其上擴展了更全面的面向業務場景的FaaS管理能力。
△示意圖：業務方僅需關注函數本身的業務邏輯開發
我們面臨的挑戰
函數調用性能不足
一方面，由於函數在需要響應事件的容器中運行，因此存在一定的延時（啓動容器和runtime的耗時），這被稱為”冷啓動”。當函數執行完成後，函數容器會保留一段時間，如果另一個事件在此時被觸發，則它的響應速度要快得多，這通常被稱為”熱啓動”。熱啓動和冷啓動的耗時差異在於容器和runtime的啓動等初始化的過程；
另一方面，函數本身在被調用時，由於無法像常駐內存的應用可以將一些熱點數據緩存起來，當函數中存在需要對接上下游應用的情況時，每次調用函數都要去做一些請求BNS_（BNS 即 Baidu Naming Service）_解析等預處理的工作，造成額外的資源開銷和耗時。
複雜場景難以應對
由於FaaS實現的是“無服務器”架構，每個函數都是狀態無關的，這就導致應用程序狀態管理困難，尤其是在需要保存數據或維護狀態的應用場景中尤為明顯，同時還存在一些邏輯複雜，需要異步處理或常駐內存的場景，純函數的方案可擴展性有限；
出於對資源有效利用的考慮，CFC的底層限制了函數同步調用時間不能超過5分鐘，異步調用（定時觸發的方式）不能超過60分鐘，一旦超時容器即被銷燬。垂搜團隊內部目前存在很多長時類型的定時任務，依賴函數的定時觸發器無法滿足所有需求。
我們做了什麼
△我們做了什麼
深度定製SDK（性能提升）
由於函數是觸發式調用，調用完成後數據不會在內存中持久化或保留在容器中，當函數中存在BNS查詢請求時，函數執行速度會受到較大影響，而像使用Golang開發的這類傳統應用，其在初始化完成後會將BNS結果暫存內存中並持續更新，當後續請求到達時直接從內存中讀取數據，相比之下，這裏函數調用的耗時差距就體現出來了。
我們基於GDP_（Go Develop Platform，百度 Go 業務開發平台）_深入定製了面向業務方的FaaS Go SDK及相關demo。經天提供了BNS加速服務，支持用户在線配置函數中使用到的BNS，當系統調用端觸發函數時，會通過header頭直接下發BNS結果給函數，SDK內會自動捕獲並無感轉換BNS結果，以減少函數執行時的BNS查詢時間。
在實際場景中，往往業務需要為某類服務寫一系列函數，而CFC僅支持單個代碼片段與單個函數的匹配，為每個函數創建單獨的代碼倉庫不利於維護。我們在SDK中定製了服務組概念，提供了函數與調度處理器的映射機制，在一個業務代碼庫中可以關聯多個函數，同時每個函數也都支持單獨的版本管理，靈活滿足了業務實際使用場景。
函數預熱（性能提升）
函數首次訪問存在冷啓的情況，會明顯導致響應時間增加，針對熱點函數，我們為用户提供了函數預熱能力，在平台開啓該功能後，經天系統將對函數容器持續保活（至少保有一個活躍的容器），以確保函數每次被觸發時都有已就緒的容器，減去容器初始化和runtime準備的時間，從而提升函數整體響應速度。
△某場景下，開啓函數預熱能力前後訪問耗時的對比
多功能API網關（能力擴展）
我們支持可視化配置 “HTTP路由 - 函數” 的映射機制，用户寫好函數後，無需編寫路由分發邏輯，只需在平台上配置自定義的路徑及函數名，即可完成API網關路由的綁定。允許業務配置鑑權中間件，當啓用鑑權時，網關會首先完成請求端的內部鑑權，鑑權通過後會將用户信息、參數簽名等下發給函數，由函數SDK完成驗參等操作。在確保數據安全流轉的同時，讓研發用户更加聚焦其業務邏輯本身的實現。
同時，針對複雜場景（常駐內存或複雜異步任務），當函數方案無法快速滿足時，我們的API網關能力也兼容外部系統的對接，用户可以獨立部署運維自己的Server服務，只需按照指定的簽名規則，在平台完成路由註冊、調試後，即可發佈API接口。
多場景異步任務（能力擴展）
經天FaaS機制除了支持常規的HTTP服務場景外，也能滿足異步任務需求：
用户可以直接為指定函數配置定時任務，由CFC提供底層調度，不過由於CFC對資源的硬限制，其最大運行時長限制為1小時，適合簡易型任務使用。
同時，作為對FaaS能力的補充，我們也自建了一套基於docker容器的定時任務調度機制，業務方僅需將其任務代碼及環境打包成docker鏡像並推送至鏡像倉庫，在平台完成簡單配置即可。其不受運行時長限制，且能指定專屬task agent機器運行，更好地滿足了長時型定時任務需求。
3.3 Saas服務產品化
面對模塊多、鏈路複雜、功能豐富多樣的搜索系統，新業務接入和存量業務迭代需求的項目上手門檻高，業務需要學習大量策略算子(100+)和模塊配置邏輯細節，修改涉及模塊多\流程長，業務和架構人力投入大。基於眾多垂類搜索場景接入流程和系統策略能力抽象沉澱，設計了基礎能力和能力編排產品化機制，並構建了文本相關性、語義向量、結構化、向量數據庫等多種典型搜索解決方案（套餐），支持業務低門檻快速接入新場景，架構服務部署通過工作流編排實現自動化，大量減少架構自身重複性枯燥工作。
△搜索SaaS服務產品化
在SaaS服務產品化的設計過程中，我們主要圍繞兩大核心點來設計：
- 基於已有的搜索策略框架，統一數據結構和通信協議，制定套餐的標準化接口；
- 採用高度組件化、模塊化的設計思路，建設易擴展的平台能力；
3.3.1 套餐標準化接口
基於上面的思考和設計，我們通過將數據引入、召回、排序、結果組裝等服務抽象沉澱為公共產品，再將這些產品以“積木化”的方式拼接組成套餐提供給業務，通過虛擬化的應用管理，對用户隱藏底層的架構實現，以邏輯應用來支持業務調研、請求、配置等接入迭代場景。
在深入調研及實踐後，我們制定了SaaS產品套餐的標準接口及調用流程：
3.3.2 初階動態表單機制
SaaS平台化的建設涉及前端、後端、架構系統側等多方同學的協作配合，且配置細節又多而繁雜，往往一處配置的改動都會涉及多方協作，協同迭代效率不夠理想。
通過 JSON Schema 協議動態渲染表單，是業界比較流行的中後台表單解決方案之一。結合我們的使用場景，我們通過使用標準的 JSON Schema 協議來統一管控套餐的表單配置，建設了套餐市場，允許架構&業務自助對外發布套餐產品，使用 FormRender 及 ant-design UI庫，提供了美觀、統一的表單展現交互能力。SaaS套餐的研發同學只需按照標準的 JSON Schema 協議即可所見既所得地定製前端表單，極大減少了平台側研發人力成本的投入。
△用户表單配置可視化設計界面，所見即所得
△套餐配置階段的動態表單
我們遇到的痛點
JSON Schema 協議渲染表單，可以輕鬆應對常見的 input / select / radio等表單使用場景，但是在實際的開發中，可能會遇到如下的應用場景：
- 普適性不高/難以用 schema 描述的組件：我需要寫一個異步加載的搜索輸入框;
- 完全定製化的需求：我需要在表單內部寫一個 excel 上傳按鈕;
- 業務邏輯耦合高：我當前的表單可選項依賴於上面某個表單的用户輸入值;
FormRender 內置的控件不能滿足全部業務功能需求，我們通過定製自定義組件 widget 來解決這些痛點，widget 是一個普通的 React 組件，它會接收 FormRender 傳遞給它的一些 props，根據這些 props 我們可以完成控件的受控、聯動、校驗等操作。在組件定製完成後，用户在 JSON Schema 中描述表單時，僅需使用自定義組件名即可使用其能力：
通過 JSON Schema 以及搭配自定義widget組件，經天的動態表單渲染能力不僅可以滿足SaaS檢索產品套餐的可視化表單渲染，還可以滿足其他所有平台表單類需求。而表單類需求，在平台化建設過程中的往往佔比非常大，靈活地運用表單動態渲染技術，大幅減少了平台側研發人力的投入。
3.3.3 進階DAG可視化
不管是檢索架構的SaaS套餐，還是展現架構vsgo框架的seda引擎算子等，其內部都大量使用了DAG（Directed Acyclic Graph）設計，相比平鋪的表單設計或原始代碼配置，DAG可以快速、清晰地呈現任務及任務之間、節點與節點之間的依賴關係。為此經天設計了可複用的DAG可視化組件，除了支持配置展現，還支持用户拖拽連線、編輯節點等。通過可視化的DAG交互，可以讓研發同學更直觀地理解業務流程，友好的交互體驗進一步提升了業務方的迭代效率。
△檢索層-某場景業務配置DAG示例
△展現層-某場景下業務的圖引擎配置DAG示例
04 總結與展望
業務加速創新，在需求越來越多、迭代越來越塊、創新能力要求越來越高的背景下，如何通過技術手段為業務開發降本增效提質做出突破，是搜索架構、也是眾多產品研發平台需要思考和解決的問題。經天一站式研發平台從業務場景和痛點出發，對複雜的後端系統深入開展了平台化探索和實踐，據此形成一套從技術思路、到系統能力、再到業務運營可借鑑可複用的一站式平台解決方案，整個解決方案包含3個關鍵組成：
- 基於FaaS機制，實現業務需求的快速迭代，幫助業務少寫代碼;
- 標準化搜索流程，對流程進行抽象、可視化建模，以搭積木的方式，為大部分典型場景提供SaaS服務套餐產品，進一步降低搜索賦能門檻;
- 重視用户培育，營造共創氛圍，促進創新生產力工具的應用、推廣和共建，在實戰中持續成長;
搜索SaaS服務產品化推進以來，我們通過套餐市場已經陸續對外提供了10+套餐，覆蓋了文本相關性、向量檢索、結構化檢索等多個常見業務場景，大幅提升了業務快速接入迭代效率。一些新業務接入的典型場景，可以實現小時級交付完整的搜索服務生產環境。
經天一站式研發平台自上線以來，日均為180+位搜索研發用户提供了各類服務。相比於傳統研發模式，FaaS能力使得業務開發成本降低了80%，目前已託管了300+函數，月均調用400w+次，相比傳統Server託管的模式，服務器/帶寬等運維成本節省了約95%。
目前垂搜內多個平台/工具已經按照經天一站式研發平台的標準進行了重構、收斂、融合，並收穫了早期用户的高滿意度和良好口碑，驗證了經天一站式研發平台實現複雜業務場景降本增效提質的切實可行性。它是一個平台，一套工具，也是一套標準，我們期望打造開放共創的生態，業務和架構同學都可以基於這套標準來沉澱更多的研發能力、應用案例和實踐經驗等等，而這些可以支撐我們進一步向更高效能、更好體驗去邁進，促進多元業務高效率、高質量、低成本地敏捷迭代，為加速業務創新和發展做出更多貢獻。
————END————
推薦閲讀
初探圖譜Embedding用於異常檢測（一）
AIAPI - 轉向AI原生檢索
學校新來了一位AI作文老師：能看、會評、還教改寫
搞定十萬卡集羣！貧窮限制了我的想象力…
AI Agent重塑微服務治理
