作者簡介

攜程搜廣推中臺框架（Eagle）技術團隊。

團隊熱招崗位：AI中臺資深算法工程師

在攜程的搜廣推業務中，Eagle技術生態扮演著核心角色，不斷地應對業務擴展帶來的新挑戰。本文首先剖析了Eagle算法策略平臺的架構創新，包括流程組件化、編排可視化和邏輯算子化，這些設計有效提高了開發效率并確保生產穩定性。進一步通過推薦信息流業務的實踐案例，展示了策略平臺在性能提升和資源優化方面的實際效益。最后，對平臺的未來發展進行了展望，包括優化調度、增強編排、靈活部署、全鏈路監控和提升用戶體驗等，以持續引領技術創新，滿足業務發展需求。

一、背景

二、算法策略平臺是什么？

三、整體設計

3.1 策略編排：簡單，直觀，安全，高效

3.2 OP-Lib：面向運行時的統一代碼庫

3.3 DAG執行器：高效的通用策略執行引擎

3.4 策略平臺在推薦信息流中的實踐

3.5 未來規劃

一、背景

目前Eagle（攜程搜廣推中臺框架）技術生態在集團多個業務線搜廣推業務中發揮了關鍵作用。它在模型訓練/推理，特征生產/服務，在線策略服務、分層實驗以及運維監控等方面提供了統一且易用的基礎框架，顯著提升了各業務團隊在研發效率和業務效果上的表現。

在效率提升方面的核心點包括：首先它改變了傳統的算法和開發協作模式，使得算法同學能夠直接參與到線上召回和重排模塊算法策略代碼的開發，大幅降低了溝通成本和一致性問題。其次，通過分層實驗平臺實現了A/B實驗參數化、配置化高效做實驗。這在一定程度上提升了策略邏輯的透明性和實驗效率。然而，隨著業務場景的擴展、業務需求量和復雜度的增加，同時更多的算法和產品同學參與進來，在代碼質量、參數管理以及溝通協作出現了一些新的問題。這些對工程質量、迭代效率和性能帶來了新的挑戰。主要體現在以下幾個方面：

1）代碼冗余、參數爆炸：由于各場景在召回和重排階段存在策略邏輯的相似性、導致了大量的代碼復制現象。這種狀況不僅使得服務變得過于臃腫，也大幅增加了維護成本和迭代難度。

2）邏輯黑盒和溝通成本：業務邏輯的掌握僅限于開發者本人，其他人一般都是通過文檔和口述同步邏輯。反之則需要投入大量時間來理解和掌握現有的代碼邏輯，這無疑增加了團隊的協作難度和溝通成本。比如，日常的case Debug和策略解釋路徑很長，產品找算法找開發一層層傳遞，效率和溝通成本問題嚴重。

3）迭代風險與難度：代碼缺少流程和模塊化設計，比如：某一個召回策略邏輯幾十行甚至幾百行代碼都寫在一個類里面。這樣當需要更改這塊邏輯時，無疑增加了出錯的風險，也使得迭代過程變得更加困難和低效。

4）質量和性能問題：算法同學（包括一部分工程同學）工程能力層次不齊，算法同學更多的是關注策略邏輯的實現，在代碼設計和質量沒有太多的優化經驗。導致上線運行時的各種問題逐漸顯現，如：時空復雜度、頻繁GC、潛在的代碼漏洞，系統的穩定性、資源利用率以及性能瓶頸等問題等。

二、算法策略平臺是什么？

Eagle 算法策略平臺是一個高度配置化和透明化的算法策略開發和部署平臺。平臺專為搜索、廣告和推薦系統業務領域設計，通過實現搜廣推全流程的配置化和透明化，簡化算法策略的迭代流程，使得算法團隊能夠更加專注于策略的效果優化和業務目標的實現。平臺提供了視圖和工具，使算法團隊能夠直觀地理解和監控流程中的每個環節（數據召回、排序邏輯、模型預測等），同時集成了自動化測試、實時監控和告警、分層實驗和問題排查功能，確保了平臺服務的高穩定性和可靠性。

三、整體設計

策略開發平臺為用戶提供一套從算子開發，任務編排到策略上線的完整解決方案，實現了策略上線流程標準化平臺化管理，沉淀策略通用能力。策略開發人員可以根據不同的業務場景對相應的業務流程進行編排和發布。相對于傳統的策略開發上線流程，該方案具有以下優勢：

• 流程組件化：將策略上線流程劃分為三個階段：算子開發，策略編排，任務運行；三階段分別封裝為完全解耦的三個組件，使方案整體具有高擴展性和低成本維護。
• 編排可視化：策略的編排采用標準的DAG模型，在頁面直觀的展現策略節點邏輯信息及節點間的邏輯關系，實現了策略邏輯完全透明。
• 邏輯算子化：框架提供一套統一的OP算子接口，實現了每個算子參數協議獨立，功能單一，進一步減少策略代碼的冗余度和提升代碼的復用性。

因此，我們將整個開發平臺劃分為三部分：

1）OP-Organization：通過可視化的頁面管理邏輯算子（OP-Lib）代碼庫，策略組件管理，策略邏輯編排（DAG）。執行策略標準化上線流程；

2）OP-Lib：實現統一OP接口的代碼庫。通過接口及注解定義了統一的OP代碼開發規范，元數據聲明，耗時及異常實時監控。大幅提高代碼的開發效率和復用性；

3）OP-engine：實時監聽策略配置（DAG）變更，支持DAG的自動優化（節點合并），動態裁剪，節點限流，熔斷，實時監控，數據回流等功能，確保策略高效運行；

3.1 策略編排：簡單，直觀，安全，高效

策略邏輯作為支撐線上效果的主要邏輯，需要高效的迭代上線，不斷的驗證正向收益，在底層的框架支持上，已有分層實驗平臺和ABtest實驗可以滿足高效的實驗和結果驗證，但在涉及到邏輯執行層，沒有統一的管理平臺，以適應策略的高頻迭代，為解決上述痛點，設計并開發了策略開發平臺。在搜廣推場景中，針對不同的調用階段，將整體流程分為了召回，粗排，精排，重排幾個階段，下面就以召回階段的視角來介紹策略開發平臺的特點。

3.1.1 策略編排可視化，所見即所得

召回首先要解決的問題是如何將策略邏輯透明化，需要宏觀視角去呈現線上服務運行的策略鏈路，它們之間的調用關系是什么？如何快速地調整不合理的策略邏輯。

3.1.1.1 應用場景可視化

進入BU下的策略首頁，即可看見以卡片形式展示出的策略梗概信息(場景，上線狀態，更新時間等)，擁有權限人員可以編輯對應卡片。

3.1.1.2 策略組件可視化

進入具體策略，可以查看編輯該策略，同時可以追蹤、回退歷史版本。在當前頁面中，為了增加策略邏輯的可讀性，使用自定義組件將邏輯功能相同的策略節點封裝在一起，使用戶對邏輯策略的認識更加直觀。例如下圖中，在召回階段按召回通道將策略封裝成一個個并行組件，使用戶直觀了解到該策略下的所有召回通道。

3.1.1.3 策略節點可視化

組件中的策略節點是平臺中的最小單元，是由策略OP算子（OP-Lib代碼庫）和策略參數組成。通過此頁面不僅可以方便的選擇一個OP來生成策略節點，同時可以以拖拽的方式編排各個節點的調用關系，通過OP算子上報了的元數據信息，平臺確保節點調用關系的正確性，保證策略上線的安全。

3.1.2 標準化上線流程，提升上線效率

標準化上線流程在提升上線效率的同時，保證每次配置發布都按照規定的步驟和規范進行，降低人為錯誤的風險，并通過驗證和測試來提高配置發布的質量和穩定性。

3.1.2.1 自動化測試

自動化測試工具將服務代碼打包成Docker鏡像并部署到k8s容器中。根據線上服務的歷史請求數據，構建請求報文并發送到該服務。獲取到結果后，對不同配置獲取到的結果進行比較。最終生成的測試結果將作為策略開發人員判斷配置變更對服務性能、功能、穩定性的影響的評估依據。如果測試結果不符合預期，策略開發人員可以及時調整配置，確保服務可以正常運行。

3.1.2.2 灰度發布

策略開發人員可以將新配置發布到鏡像集群或者測試集群，在正式上線前盡可能發現并解決潛在的問題，確保基于新配置的服務能夠穩定運行，功能和各項指標符合預期。當新配置通過測試和驗證，即可發布到生產環境。

3.1.2.3 配置回滾

當配置發布到生產環境后不符合預期或者出現問題，可以通過回滾功能將配置回退到上一個穩定版本，降低配置對服務的影響。

3.1.3 先設計、再開發（Design First）

平臺提供了在線編排可視化功能，極大降低了用戶上線策略的學習成本，用戶只需對策略OP進行編排，即可完成策略上線。這種開發模式的轉變，要求用戶更多的去思考如何合理編排策略OP，以及如何設計可復用的策略OP，避免了老的開發模式（邊開發邊設計）帶來的需求演變、迭代時大量修改和補丁的問題。

同時，策略OP的動態組合也帶來了一些問題：1）如何確保組合后的各個OP能正常調用，避免出現不合理的調用關系甚至參數類型不兼容，2）編排好的DAG圖在運行時卻找不到掛載的OP實例。在高并發流量的首頁信息流場景中，每一個問題都足以致命，為了解決上線的安全性，這就需要依靠完善的OP元數據上報機制以及OP代碼庫的版本驗證來保證。

3.1.3.1 OP開發流程和規范

為了保證用戶在操作策略節點編排時的安全性，在設計OP時，首先定義元數據信息，包括但不限于：OP類信息，輸入輸出類型和校驗邏輯、方法詳細功能描述等。當OP設計完成后再是代碼開發。

3.1.3.2 OP代碼庫版本驗證

由于OP代碼庫在線上服務中為預加載方式，即線上OP實例在一個運行周期內是完全恒定且單例的，需要在配置平臺在推送策略DAG異步上線時確保每個DAG節點掛載的OP實例在服務中是存在的，平臺使用的方案是在推送策略變更前做一次版本驗證，保證線上OP版本與配置版本完全一致。

OP代碼版本驗證流程圖

i. 用戶編排策略（DAG）時從OP池選定某一個OP-Lib代碼版本構圖，如選擇最新版V3。

ii. 策略發布時進入版本驗證流程（version check），該流程從在線服務中拉取當前線上OP代碼版本與構圖OP版本對比，版本相同時策略進入launch流程推送至配置存儲系統（Config store）。

iii. 在線應用實時監聽，將內存中的策略配置（DAG）更新，完成一次策略發布。

3.1.4 數據引擎

平臺集成了數據引擎matrix，為在線策略提供線上數據訪問能力。matrix負責管理數據上線流程和提供統一的類sql查詢訪問，對應用屏蔽底層存儲，大大降低了策略開發成本，開發人員能夠專注于業務實現。

3.2 OP-Lib：面向運行時的統一代碼庫

在敏捷開發模式下，開發人員更加關注的是每次迭代需求的快速交付，往往容易忽略新增代碼與現有代碼的統一風格規范，代碼冗余度，整體運行效率等問題。容易出現不同功能代碼間的強耦合，編碼相互入侵，上下文運行環境不兼容等一系列問題。這些問題帶來的最直接的后果就是代碼維護成本不斷提高，線上運行效率的不斷下降，同時大量的補丁代碼也增加了線上BUG出現的概率，因此我們需要提供一套標準的策略算子統一規范，在滿足業務功能的前提下將異常的影響控制在最小的范圍內。

3.2.1 OP-API：功能完善的OP接口

為了使策略邏輯代碼和開發平臺解耦，我們設計了一套完整的OP接口規范，通過這套接口的隔離，用戶只需定義OP的輸入輸出并實現對應的OP接口，而請求上下文信息，參數驗證，異常異常處理都由框架自動處理。

• EagleOperations是OP算子的統一接口，作為OP與調用方的交互規范，為了增加OP的通用性，OP接口只有一個exec方法
• AbtractEagleOp封裝了對OP算子的通用處理邏輯，包括參數驗證，上下文解析，運行時監控埋點以及異常處理。
• AbtractNodeOp是OP接口對策略執行引擎的擴展，主要面向執行引擎的DAG節點實現，在OP接口的基礎上擴展了節點相關參數

3.2.2 OP-Lib：開放的策略OP代碼庫

OP-Lib是所有策略業務實現的代碼庫，在OP接口的規范下，策略的實現可交由各個業務開發來完成，同時在發布代碼時上報該策略OP的元數據信息，如邏輯說明，輸入輸出參數類型等。框架將在服務啟動時以預加載的形式實例化這些OP算子，并在請求進入時根據DAG執行計劃統一實現調度策略OP開發流程遵循：OP設計與實現、單元測試、（框架）集成測試、 Snapshot包、Release包。

3.2.2.1 OP定義與實現

策略OP作為DAG的執行圖節點，包含圖節點基本要素，同時作為邏輯單元，為提高策略復用性、策略上線效率，通過配置化驅動。同時為避免參數爆炸、策略實驗等問題，引入“參數組”概念，OP代碼提供了邏輯模板，配合參數組完成具體業務策略。

i. 元數據信息定義

開發OP前，首先定義OP元數據信息，將定義的OP元數據信息通過配置文件的形式保存，用于后續上報。

ii. 代碼實現

框架提供了一套完整的OP開發接口，屏蔽了底層圖執行相關實現細節，同時提供了異常、超時等機制，用戶只需關心OP的內部的邏輯功能實現。

策略OP可繼承的OP基類可分為兩類：

1）NodeOp0<I,O,P>

表示接收多個同類型上游OP的輸出結果集合作為入參，上游OP的數量不限制，并且接受的上游的輸出是無序的。

I：輸入類型，O：輸出類型，P：參數類型

2）NodeOpN<I1,I2,....,IN,O,P>

表示接收N個不同類型上游OP的輸出結果作為入參，N在這里是泛指多個，具體基類包括：NodeOp1，NodeOp2，NodeOp3.......等，實際執行時上游OP的數量要同該OP定義的數量保持一致，且有序。

I1，I2，....，IN：輸入類型，O：輸出類型，P：參數類型。

基類提供3個方法：

1）Opout<O> process()：具體的功能邏輯

2）Opout<O> fallback()：失敗回調方法，用于異常處理，降級處理。當上游節點拋出異常、或者自身邏輯拋出異常時，會執行該方法，方法的返回即節點的輸出。

3）Function<JsonNode,P> paramFn()：定義策略參數解析器，用于將策略平臺定義的json參數結構轉化為OP定義的參數實體。

3.2.2.2 調試與監控

1）在線debug調試

為方便用戶在線調試、排障，我們提供了debug模式，可以在線查看整個圖中各節點的輸出的結果，驗證各節點結果的正確性，快速定位問題。

在構建DAG圖的執行請求時，通過設置debug參數為true來開啟debug模式。

同時考慮到某些節點的輸出可能是函數、延遲計算等不可直接查看的對象，我們提供了SyncOpOutput接口，實現OP輸出的自定義轉換，同時不影響線上正常輸出。

2）自動化測試

OP上線前，我們要保證對線上現有的策略和性能上無影響，可借助自動化測試完成。

目前平臺已集成自動化測試功能，支持多種測試需求，包括：功能測試、回歸測試、結果一致性測試、性能測試。上線前需要將測試包/分支上傳至測試平臺，同時設置樣本用例、測試規則等參數即可開始自動化測試任務。

3）監控埋點

平臺提供了豐富全面的監控埋點（流量監控，耗時監控，異常監控等等），幫助用戶觀測OP在線運行情況。

3.2.2.3 部署與注冊

最后需要將包含OP元數據信息的配置文件跟隨代碼一起發布到代碼倉庫，發布一個正式的代碼倉庫包，然后在策略平臺的OP管理庫中升級版本，將剛創建的包注冊進去，完成OP上線。

3.3 DAG執行器：高效的通用策略執行引擎

策略的執行引擎是一款基于有向無環圖（DAG）的數據結構實現的策略節點調度框架，為了滿足和覆蓋搜廣推全場景策略的編排，在引擎的設計上充分突出靈活易擴展的特點，既可以快速應用于現有的策略場景中，又可以實現快速擴展附加功能。該執行引擎具有如下特點：

• 標準的DAG規范：框架接收所有符合DAG規范的執行計劃。具有高通用性
• OP復用，為了增加OP的復用性，降低代碼冗余，框架從設計上將OP實例作為單例模式預加載，并可以掛載到多個相同功能的節點上，通過執行節點參數來執行不同的邏輯分支
• DAG嵌套：支持在DAG中將節點配置成另一個DAG子圖，形成DAG嵌套結構。該功能在復雜的DAG中可避免節點平鋪，具有更好的可讀性，同時隔離資源及異常
• 動態圖裁剪：支持根據請求動態裁剪DAG的邊對象，滿足節點維度的ABtest實驗
• 可擴展的圖優化器：框架監聽到圖配置變更后默認啟動責任鏈模式的圖優化器，用戶根據應用場景擴展需要的節點優化規則
  

OP策略執行框架結構設計示例圖

OP算子復用示例圖

3.3.1 應對復雜場景的執行引擎多種實現

由于框架設計目標是可以執行任何標準的DAG圖，為了保證各種簡單或復雜的DAG能以最高的效率運行，我們在執行器引擎設計上采用了統一接口的多種運行策略實現，并支持動態切換，目前已實現了三種執行引擎：

3.3.1.1 廣度優先串行調度

在廣度優先(BFS)的訪問策略下，執行器會以入度為0的頂點作為入口，直接使用請求線程以串行方式依次調用當前層的所有節點，如果同一層訪問完畢，再調用下一層，直到所有節點訪問完畢。該策略在執行周期內完全使用請求線程，沒有線程切換開銷，占用資源較少。但所有節點串行執行會增加執行器整體耗時，比較適用于對響應時間要求不高或無狀態的純計算場景。

3.3.1.2 廣度優先并行調度

此調度實現同樣使用BFS的算法訪問節點，并綁定一個線程池資源，調度時會將同一層的節點打包提交到線程池并行執行，對于并行度較大的DAG，此策略可以有效提升DAG的執行效率。

3.3.1.3 全異步響應式調度

雖然并行調度的方式可以并發執行DAG中平行的節點，但仍然存在“短板效應”,由于提交批次間仍然是串行的，如果某一批次中的節點N執行耗時較大，則該批次所有節點都會阻塞等待，盡管下一批次中大部分節點不依賴節點N。為解決此短板，我們使用異步阻塞隊列實現一個全異步響應式執行器，執行過程如下：

主線程邏輯：

1）主線程（請求線程）進入執行器，創建一個阻塞任務隊列Q。并找出DAG的所有根節點（入度為0的頂點）作為任務隊列的初始任務；

2）主線程進入事件隊列開始調度：主線程嘗試從任務隊列等待可執行的節點，如果獲取到節點則將節點提交給異步線程（子線程）執行（如果等待超時，則退出）；

3）如事件隊列還存有未執行事件則重復2）操作，如當前請求所有事件（任務）全部執行完成，則獲取葉子節點的返回結果并退出DAG，執行后續的流程。

子線程邏輯：

1）子線程接收到主線程提交的任務后開始執行，并將返回值存入臨時緩存區。

2）子線程在完成當前節點任務后，從DAG中找出當前節點所有可執行的下級節點集合，壓入任務隊列，（觸發主線程步驟2）

3）子線程標記后被回收（如是虛擬線程則直接釋放）

異步響應式調度的優勢在于，在復雜DAG下，每個節點只要滿足了前置條件（入度全部完成）即可觸發運行，不受同層平行節點的耗時干擾，進一步提升了執行器運行效率。同時該策略下由于每個節點都是異步運行，在傳統的平臺線程池模式下，高并發意味著占用更多的線程資源，需要合理設置線程池規模和資源降級策略，另外框架支持在java21環境下將線程池配置為虛擬線程模式，該模式下節點將使用無池化的虛擬線程異步執行，關于虛擬線程相關概念可通過JDK官網了解

下圖對比了分層調用和響應式調用的區別，可見響應式調用可明顯減少調用時間： 

3.3.2 執行效率提升：可擴展的DAG圖優化器

在策略開發平臺的策略編排（DAG構圖）完全由用戶自定義，這意味著推送到執行引擎中的DAG規模可能非常大，如果用戶同時使用的是異步執行器，節點的并行規模可能會耗盡線程資源，因此，我們引入了一個異步圖優化流程，執行引擎監聽到DAG圖變更后，會將此圖的節點按照需要的規則進行合并，最終生成實際的物理執行計劃；從設計上看，優化器采用了責任鏈的開發模式，除框架預設的優化器外，用戶可以擴展實現自定義規則的優化器并設置順序。合理的執行順序能有效提高優化器的執行效率。

圖：基于責任鏈的圖優化器

目前框架預設的優化器為串行節點優化器，可以將關系唯一的兩個相鄰節點合并為一個包裝節點，減少執行器的調度次數和線程資源。

在實際案例中證明，用戶的DAG圖越復雜，默認優化器的優化效率越高：

3.4 策略平臺在推薦信息流中的實踐

目前整個推薦策略已完成策略OP化改造工作，策略OP涵蓋了召回和重排等多個階段，已有80多個推薦信息流業務場景接入了策略平臺，涵蓋了多條業務線。

3.4.1 策略上線效率提升

以信息流召回階段的策略上線為例，在原有開發模式下，需要重新定義一個新的通道，涉及代碼邏輯定制，要經歷開發、測試、發布的一個完整上線流程，至少兩天時間。接入策略平臺之后，完善的策略OP池基本覆蓋了召回各種需求策略，一個新通道上線，只需添加配置，測試驗收即可，簡單的策略1小時內可以上線，復雜的策略半天時間，極大的提升了策略上線效率。

3.4.2 策略邏輯透明

策略邏輯通過DAG圖化展現，根據每個節點所選擇的OP以及定義的參數組能夠快速了解該節點內部邏輯，策略整體邏輯清晰明了，大大降低了學習成本低，溝通成本。

下圖為首頁召回階段平臺視角，可以清楚看到線上生效的策略（SWI，LIVE，PN，LGC，SEA，GPR等），以及各策略使用的召回組件模板，可大致了解通道邏輯，比如SEA使用的是模型召回組件（ModelRecall），通過模型來召回產品；SWI使用的是trigger召回組件（X2I），通過指定條件召回產品。

點擊通道可查看該通道具體的策略邏輯，下圖是PN通道的策略邏輯，可以看出該通道由兩路查詢策略合并組成。

3.4.3 性能提升，資源優化

首頁推薦信息流召回服務接入策略平臺后，服務性能得到提升，資源利用率得到優化。

性能相關指標如下：

整體耗時提升30%左右，性能得到明顯提升。

資源相關指標如下：

下圖左邊為老版召回應用核數變化，初始核數為2400，右邊為新版應用核數變化，流量完全切至新版后核數為900，CPU核數從2400縮減至900，縮減比例60%。

同時策略平臺底層框架引入了java21虛擬線程技術，對于召回這種重IO的業務場景，資源得到進一步優化。下圖為新版召回服務使用虛擬線程前后資源對比，因虛擬線程切換，CPU核數從900縮減至600，縮減比例30%，CPU利用率由 20%提高至40% ，提升100%。

經過上述兩次優化，召回服務的CPU總核數從2400縮減至600，縮減比例75%，資源得到優化。?

3.5 未來規劃

3.5.1 平臺建設

平臺未來會持續建設、優化，主要目標包括：

• 繼續優化圖執行引擎，提升圖執行效率；
• OP性能優化和組件沉淀：優化OP性能，沉淀業務組件、提升新場景構建效率；
• 全鏈路Debug：為全流程提供統一的Debug，幫助用戶快速定位鏈路問題，提高問題解決效率；
• 平臺易用性：為提升用戶體驗，進一步提升易用性；

3.5.2 平臺推廣

平臺專為搜廣推業務領域設計，目前首頁推薦業務場景已接入策略平臺，未來將繼續推動和支持更多業務線搜廣推業務場景接入。