百度基於雲原生的推薦系統設計與實踐

　　 01 雲原生技術棧

　　下圖是 CNCF 公佈的雲原生基礎架構的抽象圖。　　

　　典型的雲原生技術棧可分為四層：供給層（Provisioning）、執行時層（Runtime）、策劃和管理層（Orchestration & Management）以及App定義和開發層（App Definition & Development）。還包括一些可觀測性和分析的基礎設施，比如監控、日誌、呼叫追蹤、混沌工程。

　　我們要做的，就是在推薦系統上，利用好 cloud native 的這幾層架構，來實現基礎技術能力。早期 cloud native 有些基礎設施還沒有完善，因此部分公司在搭建推薦系統時，部分基礎設施是自建的。後期，在 cloud native 技術完善之後，在設計推薦系統時，就會基於 cloud native 的技術棧來進行模組設計。無論是哪一種形式，都要對雲原生的技術棧和推薦系統的基礎架構有比較深入的瞭解，才能做到較好的融合。

　　 02 推薦系統架構　　

　　推薦系統的技術架構，可以分為線上和離線部分。

　　離線部分通常做內容建模，資料引入時，通常做內容建模，例如內容生態和合作資料引入。我們對這些資料進行內容處理，如標籤化、標籤特徵抽取、向量化（即根據一些模型把 Doc 資料轉化為向量）。對於使用者資料，例如使用者點展、共享和分享這些使用者行為，我們會對其進行資料探勘和使用者畫像、Attention 抽取等，並且對使用者的屬性也進行向量化。在此基礎上，將使用者的推送或相關性、關聯性等 doc 維度的屬性進行召回和排序，最終進行展現。

　　流量方面，在天級範圍內體現出明顯的潮汐現象。比如在晚高峰流量高，低谷期流量低。

　　 03 基於雲原生的推薦系統設計重點　　

　　針對推薦系統的特點，在設計時需要從三個層次建設基礎能力和業務架構。第一層，需要構建好雲原生的基礎設施，包括 PaaS、事件機制、服務編排、服務畫像、指標採集等；在此基礎上，是第二層，雲原生能力的建設，包括構建 ALM 的全生命週期管理、容量管理，SaaS 方面的資源管理、排程機制，以及流量管理、混沌工程穩定性等等；最終體現在第三層業務價值上，包括降低成本、提升研發效率、保證穩定性、提升業務效果和提升效能。

　　接下來重點介紹四個方面：虛擬化和微服務化改造，服務治理和彈性建設，基於雲原生能力的推薦業務應用以及穩定性建設。

　　1. 虛擬化和微服務改造　　

　　虛擬化技術是雲原生系統中最基礎的部分，本質上是軟硬體的技術棧。硬體輔助虛擬化方案（Hardware virtualization，HVM），主要利用 CPU 等硬體輔助處理敏感指令，以實現完全虛擬化功能，無需修改客戶端作業系統。

　　VMware Workstation，Xen，KVM 產品或架構都是應用了該技術，當前市場中幾乎所有主流硬體都是支援硬體輔助虛擬化技術的。

　　最常見的虛擬化落地方式是 KVM 技術，透過處理敏感指令，實現 CPU、記憶體和 IO 的虛擬化技術。　　

　　另一個趨勢是 GPU，在推薦系統中日益盛行，主要用於模型訓練、線上推理等一系列高密度複雜計算。GPU 視訊記憶體大、計算能力強，需要對其進一步虛擬化切分，使業務能夠以更低的成本使用，獲得高效的運算效果。　　

　　虛擬化構建之後，必不可少的步驟是微服務的改造。微服務化改造是精細化排程和服務資源運營的基礎。以百度為例，早期業務流量增長迅猛，對研發迭代的效率要求極高，早期實現方式為巨型服務，每個業務模組功能變複雜後，功能依然在模組內部實現，導致開發迭代變得越來越困難。隨著模組逐步龐大，會發現一臺機器上的部分資源被佔滿，而部分資源空閒，因此需要進行微服務化改造。比如預估層，抽出 CTR 預估、時長預估等，將服務拆解。

　　微服務化拆分的目標是無巨型服務和可遷移服務。無巨型服務，即約束服務的資源顆粒度。同時做到可遷移，即各服務實現例項自動化遷移。可遷移除了常見的擴容外，還有服務例項自愈。比如當整機出現熱點，或當服務模組出現異常時，能快速探測，並實現自愈。

　　拆分的原則包括：按策略、業務流程拆分，按組織團隊拆分，以及通用服務平臺化。　　

　　一個典型的推薦系統服務改造方式為，將一些巨型服務，如使用者模型、內容資料、索引排序等，進行額外的抽象，進行獨立的平臺化處理，即透過 RPC 訪問外部服務，使其從原本的推薦服務中抽離出來。

　　構建通用服務框架，透過元件式的開發構建可組裝的策略元件。包括業務模組、架構模組。其中架構模組即一些可複用的基礎模組，比如 Filter 或一些基礎函式，還包括一些策略運算元，如 CTR、Rank 等，以運算元庫的形式提供給業務，進行拼裝式的使用。

　　常用的一種拼裝方式是 DAG 引擎。透過一些配置檔案，即可將整個程式碼邏輯組裝起來。

　　2. 服務治理和彈性建設　　

　　應用生命週期管理（ALM）的目標是透過服務治理，讓所有的服務都保持在合理的執行狀態下，確保資源利用健康度，可檢測、可干預。服務治理的能力和效率，是架構可持續發展的關鍵因素，其基礎依賴就是容器編排、虛擬化的支援，在此基礎上透過對基礎引數和效能引數的採集，進行服務編排。同時，還要做到可觀測性。　　

　　透過 ALM 採集的資料，可以對服務進行統一、標準化地治理，實現對資源的合理利用。但有些服務，其資源利用率並不是隨 QPS 增長而線性增長的，不同服務對利用率的容忍率也不同。因此，我們構建了以服務畫像為中心的雲原生技術。

　　根據每個服務的極限負載個性化地設定合理容量，實現系統成本全域性最優。基於服務的機型偏好的排程策略，實現資源最優配置，提升系統效能。摒棄傳統固定容量模式，動態調整服務容量，實現資源按需分配。　　

　　針對負載波動差異大，彈性等級差異大和負載容忍度差異大等問題，透過不同型別的畫像來構建彈效能力。比如線上場景中晚高峰流量大，push 場景中新熱點流量會明顯上升，對於不同的服務構建個性化流量畫像來描繪其波動特性。另外，從儲存和計算兩個維度對各個服務的彈性進行打分，以此作為彈性伸縮的依據。　　

　　透過 Metric agent、Data Polling 等資料採集，離群值處理、缺失值填充以及資料聚合等預處理方法，構建多維度服務畫像。　　

　　基於畫像構建個性化的 ALM quota resize 架構，透過預縮容、反饋和熔斷機制、步進式調整控制流程等方法保障穩定性。　　

　　基於畫像的 serverless，是一種基於流量預測的彈性伸縮策略，可以進行提前預判 & 負載反饋兜底。依託 STL、LSTM 等時序演算法模型進行流量預測。透過主動預測、提前預判、監控負載、主被動結合的方式，構建兼顧穩定性和成本的安全彈性機制。

　　上圖中展示了預測效果。可以看到預估誤差為 4%，相較於簡單規則的 18%，具有明顯優勢。　　

　　3. 基於雲原生能力的推薦業務應用　　

　　釋放出來的資源可以用於額外的計算，以獲得更多收益。

　　推薦產品不依賴使用者的主動輸入，多數使用者的“興趣”長期穩定。Nearline 召回機制是介於線上離線之間的一類全新召回方式，容忍秒級延遲，有更大的計算規模和複雜度，可以使用碎片資源和閒置資源，降低機制成本。　　

　　透過非同步計算的方式，與線上計算解耦，根據系統負載主動計算，可以提前計算獲得預估結果，提升效果。根據資源情況，動態調整計算引數，實現資源平穩與充分利用。

　　4. 穩定性建設 - 混沌工程

　　混沌工程在 2018 年由 CNCF 提出，是⼀⻔新興的技術學科，透過實驗性的⽅法，讓⼈們建⽴對於複雜分散式系統在⽣產中抵禦突發事件能力的信心。

　　傳統的穩定性工作，建立在歷史 case 和工程師經驗基礎上，是一個（發生故障->解決問題->下次發生故障）的迴圈。系統經過重構升級後，穩定效能力可能無法持續。

　　混沌工程的整體目標是透過實驗主動驅動代替過去的 case 被動驅動，在可控範圍內週期性注入故障，主動發現系統隱患，驗證穩定效能力，推動架構迭代最佳化。　　

　　混沌工程的主要機制是透過紅藍對抗機制進行故障的隨機預演練。透過對故障場景編排和自動化巡檢，利用韌性指數把穩定性進行量化。　　

　　基於歷史問題抽象故障庫，建立可量化的穩定性評價體系，引入韌性信心指數規範，混沌實驗週期性巡檢，更新韌性指數，驅動架構最佳化。