作者簡介

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

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

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

一、背景

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

三、整體設計

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

3.2 OP-Lib：面向運行時的統(tǒng)一代碼庫

3.3 DAG執(zhí)行器：高效的通用策略執(zhí)行引擎

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

3.5 未來規(guī)劃

一、背景

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

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

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

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

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

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

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

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

三、整體設計

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

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

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

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

2）OP-Lib：實現(xiàn)統(tǒng)一OP接口的代碼庫。通過接口及注解定義了統(tǒng)一的OP代碼開發(fā)規(guī)范，元數(shù)據(jù)聲明，耗時及異常實時監(jiān)控。大幅提高代碼的開發(fā)效率和復用性；

3）OP-engine：實時監(jiān)聽策略配置（DAG）變更，支持DAG的自動優(yōu)化（節(jié)點合并），動態(tài)裁剪，節(jié)點限流，熔斷，實時監(jiān)控，數(shù)據(jù)回流等功能，確保策略高效運行；

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

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

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

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

3.1.1.1 應用場景可視化

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

3.1.1.2 策略組件可視化

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

3.1.1.3 策略節(jié)點可視化

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

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

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

3.1.2.1 自動化測試

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

3.1.2.2 灰度發(fā)布

策略開發(fā)人員可以將新配置發(fā)布到鏡像集群或者測試集群，在正式上線前盡可能發(fā)現(xiàn)并解決潛在的問題，確?；谛屡渲玫姆漳軌蚍€(wěn)定運行，功能和各項指標符合預期。當新配置通過測試和驗證，即可發(fā)布到生產(chǎn)環(huán)境。

3.1.2.3 配置回滾

當配置發(fā)布到生產(chǎn)環(huán)境后不符合預期或者出現(xiàn)問題，可以通過回滾功能將配置回退到上一個穩(wěn)定版本，降低配置對服務的影響。

3.1.3 先設計、再開發(fā)（Design First）

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

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

3.1.3.1 OP開發(fā)流程和規(guī)范

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

3.1.3.2 OP代碼庫版本驗證

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

OP代碼版本驗證流程圖

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

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

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

3.1.4 數(shù)據(jù)引擎

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

3.2 OP-Lib：面向運行時的統(tǒng)一代碼庫

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

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

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

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

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

OP-Lib是所有策略業(yè)務實現(xiàn)的代碼庫，在OP接口的規(guī)范下，策略的實現(xiàn)可交由各個業(yè)務開發(fā)來完成，同時在發(fā)布代碼時上報該策略OP的元數(shù)據(jù)信息，如邏輯說明，輸入輸出參數(shù)類型等?？蚣軐⒃诜諉訒r以預加載的形式實例化這些OP算子，并在請求進入時根據(jù)DAG執(zhí)行計劃統(tǒng)一實現(xiàn)調(diào)度策略OP開發(fā)流程遵循：OP設計與實現(xiàn)、單元測試、（框架）集成測試、 Snapshot包、Release包。

3.2.2.1 OP定義與實現(xiàn)

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

i. 元數(shù)據(jù)信息定義

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

ii. 代碼實現(xiàn)

框架提供了一套完整的OP開發(fā)接口，屏蔽了底層圖執(zhí)行相關實現(xiàn)細節(jié)，同時提供了異常、超時等機制，用戶只需關心OP的內(nèi)部的邏輯功能實現(xiàn)。

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

1）NodeOp0<I,O,P>

表示接收多個同類型上游OP的輸出結果集合作為入?yún)ⅲ嫌蜲P的數(shù)量不限制，并且接受的上游的輸出是無序的。

I：輸入類型，O：輸出類型，P：參數(shù)類型

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

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

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

基類提供3個方法：

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

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

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

3.2.2.2 調(diào)試與監(jiān)控

1）在線debug調(diào)試

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

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

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

2）自動化測試

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

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

3）監(jiān)控埋點

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

3.2.2.3 部署與注冊

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

3.3 DAG執(zhí)行器：高效的通用策略執(zhí)行引擎

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

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

OP策略執(zhí)行框架結構設計示例圖

OP算子復用示例圖

3.3.1 應對復雜場景的執(zhí)行引擎多種實現(xiàn)

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

3.3.1.1 廣度優(yōu)先串行調(diào)度

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

3.3.1.2 廣度優(yōu)先并行調(diào)度

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

3.3.1.3 全異步響應式調(diào)度

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

主線程邏輯：

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

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

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

子線程邏輯：

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

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

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

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

下圖對比了分層調(diào)用和響應式調(diào)用的區(qū)別，可見響應式調(diào)用可明顯減少調(diào)用時間： 

3.3.2 執(zhí)行效率提升：可擴展的DAG圖優(yōu)化器

在策略開發(fā)平臺的策略編排（DAG構圖）完全由用戶自定義，這意味著推送到執(zhí)行引擎中的DAG規(guī)?？赡芊浅４螅绻脩敉瑫r使用的是異步執(zhí)行器，節(jié)點的并行規(guī)模可能會耗盡線程資源，因此，我們引入了一個異步圖優(yōu)化流程，執(zhí)行引擎監(jiān)聽到DAG圖變更后，會將此圖的節(jié)點按照需要的規(guī)則進行合并，最終生成實際的物理執(zhí)行計劃；從設計上看，優(yōu)化器采用了責任鏈的開發(fā)模式，除框架預設的優(yōu)化器外，用戶可以擴展實現(xiàn)自定義規(guī)則的優(yōu)化器并設置順序。合理的執(zhí)行順序能有效提高優(yōu)化器的執(zhí)行效率。

圖：基于責任鏈的圖優(yōu)化器

目前框架預設的優(yōu)化器為串行節(jié)點優(yōu)化器，可以將關系唯一的兩個相鄰節(jié)點合并為一個包裝節(jié)點，減少執(zhí)行器的調(diào)度次數(shù)和線程資源。

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

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

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

3.4.1 策略上線效率提升

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

3.4.2 策略邏輯透明

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

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

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

3.4.3 性能提升，資源優(yōu)化

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

性能相關指標如下：

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

資源相關指標如下：

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

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

經(jīng)過上述兩次優(yōu)化，召回服務的CPU總核數(shù)從2400縮減至600，縮減比例75%，資源得到優(yōu)化。?

3.5 未來規(guī)劃

3.5.1 平臺建設

平臺未來會持續(xù)建設、優(yōu)化，主要目標包括：

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

3.5.2 平臺推廣

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