在攜程的搜廣推業務中，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 平台推廣
平台專為搜廣推業務領域設計，目前首頁推薦業務場景已接入政策平台，未來将繼續推動和支援更多業務線搜廣推業務場景接入。
作者:攜程搜廣推中台架構（Eagle）技術團隊。
來源-微信公衆号:攜程技術
出處:https://mp.weixin.qq.com/s/vF9WX9nLJ04CL60yxUYA7Q