作者 | 百度Geek說-百度知道研發組

導讀?

百度知道作為上線十多年的老產品線，業務場景多、架構老舊、代碼風格不統一，同時業務迭代較快，整體承載流量大，穩定性要求高，給業務全面上云帶來不小的挑戰。本文基于實踐，介紹知道如何進行上云方案的選型和落地，并同步進行架構演進，提升線上服務穩定性和容災能力。

01 背景與挑戰

1.1 背景

隨著集團 PaaS 化戰略和云上百度戰略推進，當前在線運行平臺 ORP 已正式進入維穩階段，不再進行功能更新和安全修復；同時 ORP 接入層在穩定性、變更效率等方面也無法滿足云上部署要求。OXP 逐漸成為業務發展和迭代的瓶頸。為了解決這一問題，同時增強資源彈性，降低業務資源成本，接入各類云原生能力，提升部署效率，保障線上服務穩定性，知道啟動去 OXP 專項，將逐步完成整體上云及架構演進工作。

1.2 挑戰

1、知道產品線老舊，歷史債務多。?百度知道是一個已有十八年歷史的老產品線，業務模式繁雜，上下游依賴較多，不同時期的重點方向不一樣，架構老舊，代碼風格不統一，改造成本高；

2、知道業務發展快，迭代變化快。?雖然產品線歷史久遠，為了適應新變化，業務迭代敏捷，核心場景更新換代頻繁，年均上線業務需求 780 + 個，需在保證業務目標達成前提下完成上云遷移，使業務全程無感；

3、知道流量大，商業收入多，穩定性要求高。?作為知識類流量收入雙 TOP 產品線，知道日均 pv 過億，遷移過程中不能影響任何流量和商業收益，核心服務穩定性目標需在四個 9 以上；

4、上云同時架構合理演進。?上云遷移作為知道歷史上一次重大技術變革，除了能給老產品線帶來先進的云原生能力，優化 IT 成本以外，還希望借此推動知道整體架構優化演進，提升容災能力及線上服務穩定性。

1.3 收益

1、全部流量上云，為知道帶來先進的資源彈性供給能力，大幅提升擴縮容效率，避免流量波動帶來的線上容量風險，提升在線服務穩定性；

2、引入容器彈性售賣能力，按需使用、按量付費、動態調整，優化線上服務整體資源量級；騰退大批量 OXP 機器，大幅降低知道 IT 成本；

3、知道架構隨上云持續演進，將 0 到 1 實現核心流量三地四機房云上部署，降低核心頁端到端耗時，使核心頁面具備 N+1 冗余災備能力，提升業務抗風險能力。

02 概念介紹

2.1 知道業務簡介

知道是傳統的圖文知識類內容生產業務。首先通過用戶自發提問，或者對搜索每日 query 篩選挖掘，獲取到待解決問題；其次引導各類生產者，在不同頁面、后臺對問題進行解答，生產回答內容；再次將生產好的問答對推送至搜索、Feed 等場景供用戶瀏覽消費，用戶點擊進入問答頁后獲得解答，同時靠廣告點展為知道帶來商業收入。

知道經過多年經營，積累了海量問答資源，在搜索生態中穩定覆蓋了眾多長尾需求；同時通過識別用戶需求，挖掘高價值線索，引入機構或 MCN 賬號，建設了多垂類優質內容，逐漸形成了相對穩定的多層次內容生態和品牌認知。

2.2 業務架構

知道整體業務架構如下圖所示：

2.3?流量架構

上云前知道整體流量架構如下圖所示：

03 上云設計與實踐

3.1 上云方案選型

知識垂類內 php 模塊廣泛使用的 PaaS 平臺 orp 已公告于 2022 年底停止維護，同時現有的 orp 系統在容器編排管理層面存在一些問題，預算資源管理也和現有公司的機制流程不通。知道的現有架構基于 odp 原生實現，更多體現成一個大型大單體應用，通過本次升級，知道需遷移至更加接近云原生環境的 PaaS 平臺上，進行新一輪的架構迭代，打造符合業務現狀的架構理想態。

雖然管理容器化應用程序的開源系統 Kubernetes 作為社區和未來發展趨勢，但綜合考慮改造成本、時間節點、開發人力等因素，知道本次上云與其他知識垂類產品線遷移最終選型保持一致：底層使用 pandora，資源管理及上線使用 “知云平臺”。

3.1.1 why pandora

主要有幾個方面考慮：

1、pandora 適應公司內主要的 C 端業務，如大搜、feed、手百、百家號、視頻（好看）等，這些業務在場景上與知識體系更加接近，詳細調研和評估可支持現有變更方案；

2、pandora 在現有 PaaS 內唯一能夠支持較多模塊同時部署（最大支持 2K），而無需業務過多改造合并，更適應現 odp 大單體的架構；

3、易用性層面 pandora 暫時不及 opera，但已通過知云解決；同時知云會提供 orp 的包括接入、靜態資源、代理、數據配送等服務，故不影響最終選型結論。

3.1.2 why 知云

知識垂類及其他 oxp-based 業務有個比較明顯的架構：大單體模式下的多 APP 同構，這部分需求在現有的 PaaS 平臺均無支持。同時，因為 pandora 底層對打包和服務的規范，業務線需要針對性的進行代碼改造和回歸，這部分工作存在明顯的重復性。知云平臺旨在提供一套更符合知識業務（及 oxp-based）的上云解決方案，主要具備以下幾類優勢：

1、上線變更：除基礎上線、配置管理及回滾等外，核心支持多 APP 同構的模式，及支持多模塊部署?？梢宰龅?oxp 項目遷移至知云成本降低，理想情況下無需合并 / 拆分代碼庫，可以平移支持；

2、平臺服務：對標 oxp 現有服務，提供包括日志切分、定時任務、接入層、靜態資源、飛線、中控等的支持和解決方案，同時基于云原生思想開放服務模式，支持業務部署自定義服務；

3、業務運行時環境：odp 基礎運行環境快速部署和定制；

4、基礎環境（容器）：整合入口，在日常運維時提供更方便的操作方案。

3.2 切流與擴量實踐

3.2.1 上云前改造

對各流量集群，在遷移 Pandora 之前，主要涉及以下幾方面工作：

1、知云創建產品線及應用。?需在知云平臺搭建知道產品線基礎環境，創建 APP 基礎信息，申請 ECI 各機房資源 2 及實例配置，添加 ODP 基礎運行環境及數據配送容器相關信息，創建容器組件相應配置，添加靜態文件存儲地址，修改部署路徑及配置派生 conf，創建上線模板等；

2、接入層改造及授權。?接入層創建對應新 APP 的 BNS 變量，并針對新的 BNS 進行各類 DB、redis 授權，涉及新機房，還需要對各 mysql 及 redis 配置進行升級適配；

3、業務層改造及測試。?知道本次上云會同步完成后端語言 HHVM->PHP7 升級改造，語言版本更新會帶來安全及性能方面的進一步提升，同時 PHP7 還提供了眾多新的語法特型，老舊版本無法使用。需完成對應模塊 PHP7 兼容性問題改造，并完成線下測試；

4、添加監控及日志采集。?需添加對應 APP 的各級 noah、sia 監控，對各監控項進行調整，對監控閾值進行優化；修改相應日志采集路徑，合并各服務組，并離線進行入庫效果驗證。

3.2.2 切流方案

小流量實驗方案如下圖所示：

接入層改造：

可借助接入層的 lua 腳本實現小流量切流，腳本實現了以下規則：

?

?

['strategy_1_1_98'] = {?1?, 1?, 98?}?,? ['strategy_5_5_90'] = {?5?, 5?, 90?}?,? ['strategy_10_10_80'] = {?10?, 10?, 80?}?,? ['strategy_20_20_60'] = {?20?, 20?, 60?}?, .....,? ['strategy_80_20_0'] = {?80?, 20?, 0?}?, ?['strategy_95_5_0'] = {?95?, 5?, 0?}?,? ['strategy_100_0_0'] = {?100?, 0?, 0?} 返回值有三種結果："opera", "abtest", "orp"，從左到右分別對應三段數字，即每種結果出現的概率，從而可以根據返回的結果實現流量控制； 使用新增變量 $upstream_target 來標記最終 proxy 值，四種取值分別對應 pc 端和移動端實驗組 / 對照組流量：

#設置最終proxy的值：pc_orp、pc_pandora、wap_orp、wap_pandora set $upstream_target "${terminal_target}_${target_cluster}"; #知道上云切流實驗配置結束

?

?

新增給業務傳遞標記，取值為 "pandora"、"abtest"、"orp"，分別用來標識實驗組、對照組、無關組流量。

業務層改造

業務層捕獲上述流量標記，分別創建并使用新的 Eid 發起商業請求，即可獲得當前實驗組 / 對照組各頁面商業流量數據。

?

?

if ($_SERVER['HTTP_X_BD_TARGET'] == 'pandora') { $adsEids = array( 'asp' => array(50001), ); } else if ($_SERVER['HTTP_X_BD_TARGET'] == 'abtest') { $adsEids = array( 'asp' => array(50002), ); }

?

?

3.2.3 擴量相關

以知道核心問答頁為例，擴量的每個階段都有該階段需重點關注的工作內容，及進入下一個階段的準入 list，需要 list 內容全部達標，才可開啟下一階段擴量實驗。具體說明如下：

3.2.4 云上網關切換

在業務層上云后，網關下游由原本幾乎不發生遷移的 orp 環境，變成了遷移頻繁的云上環境，原 orp 接入層對頻繁的下游變化無法做到靈敏感知，因此需對原 orp 接入層進行上云切換。Janus 網關已經廣泛使用在了如手百、百科、問一問、經驗、百家號等產品線中，與原 inrouter 對比具有以下優勢，同時經過了大量的實踐驗證，因此知道上云選擇了知云體系中的 Janus 來進行網關切換。

知道經歷了 18 年的迭代，網關的路由轉發規則已經臃腫不堪，邏輯繁瑣，維護成本非常高，稍有不慎就會引發嚴重線上事故。網關作為對流量轉發控制的服務，應當盡可能地簡單、清晰，具備較好的可讀性和可維護性。因此在網關上云切換時，應當同步進行路由的深度重構治理，而不是簡單的平遷。遷移重構核心流程如下：

最終達到的效果：

1、下游感知靈敏：新網關對下游實例漂移感知靈敏，疊加重試策略，實例漂移對業務 SLA 幾乎無影響；

2、大大增強可維護性：將預覽、內網、外網三類域名隔離建設，劃分清晰，使用和維護都一目了然。將原 nginx 轉發規則 2768 行 conf 文件整合收斂至 18 條規則，清理了 18 年來的歷史包袱；

3、安全性得到進一步增強：上線細化至每個服務、每條路由、每條轉發規則，影響面可控。除了分級發布，疊加 checker、上線巡檢、測試用例等手段，大大增強了網關上線變更的安全性。

3.3 架構演進

3.3.1 現狀 & 問題

知道長久以來 95% 以上主體流量集中在北方，核心流量打到 tc+jx 機房，非核心流量打到 yq 機房。從外網接入點，到實際業務層，到底層依賴基礎服務，再到重要的第三方依賴服務，均沒有搭建其他地域資源和服務。這就造成一個非常明顯的安全隱患，一旦華北地域出現故障，無法進行徹底的切流來規避線上損失。

3.3.2 演進方案

1. 知道三端 QB 頁核心流量，占知道總體流量 80% 以上，是知道 99% 以上商業收入來源，自然流量大，用戶交互多，對線上事故敏感，穩定性要求四個 9 以上。這部分是知道的生命線，本次伴隨上云遷移，會同步建設三地四機房，使 QB 頁具備單地域故障快速切流其他兩地能力，提升系統整體可靠性；

2. 除 QB 頁以外非核心流量，由于時間久，涉及模塊多，底層資源類型繁雜，同時又基本不貢獻商業收入，各子系統流量占比較低，考慮改造成本及性價比，本次上云遷移將非核心流量遷至華北雙機房，具備同地域不同機房冗余災備能力，暫不建設其他地域；

3. 針對核心流量，需進行 “外網接入點 ->BFE-> 接入層 -> 業務層 -> 依賴自身服務 -> 依賴三方服務 -> 依賴底層存儲” 全鏈路三地資源建設，并進行連通性測試；

4. 針對核心流量，各級服務資源到位后，需進行全方位壓測及災備演練，確保新地域機房流量承壓能力，并達到單地域故障時可自由切換至其他兩地域狀態。針對重要的、且無法線上壓測演練的三方服務例如商業廣告請求，協同對方 OP、RD、QA 等角色共同制定切流觀察方案，以免流量分布改變后造成線上安全隱患；

5. 針對核心流量，設計切流方案并建立各三方服務同步機制，切流期間共同觀察，上下游各子系統是否符合預期。

3.3.3 具體實現

知道核心流量三地域建設完成后流量架構演進如下所示：

04 總結與收益

1. 截至 23 年 3 月 31 日，知道云上流量占比已達 100%，知道業務已全面上云。

2.2022 年 Q3 知道開始切流上云，連續三個季度 SLA 滿足四個 9，由上云引入線上問題數 0。

3. 知道核心頁已完成三地四機房建設，知道線上核心流量分布比例為華北：華中：華南 = 43，知道歷史上首次具備了 N+1 跨地域冗余災備能力。

4. 小程序 QB 核心接口端到端耗時均值下降 12%，FMP80 分位穩定 1S 內，不需要其他技術優化即達成秒開。

5. 完成 GTC 接入點三地調整，公網 IP 均攤費用自 2023 年以來逐月下降，同時批量交付下線 OXP 機器，節省了大量研發成本。

編輯：黃飛