一文解析百度知道上云與架構演進

作者 | 百度Geek說-百度知道研發(fā)組

導讀?

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

01 背景與挑戰(zhàn)

1.1 背景

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

1.2 挑戰(zhàn)

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

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

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

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

1.3 收益

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

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

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

02 概念介紹

2.1 知道業(yè)務簡介

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

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

2.2 業(yè)務架構

知道整體業(yè)務架構如下圖所示：

2.3?流量架構

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

03 上云設計與實踐

3.1 上云方案選型

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

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

3.1.1 why pandora

主要有幾個方面考慮：

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

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

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

3.1.2 why 知云

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

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

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

3、業(yè)務運行時環(huán)境：odp 基礎運行環(huán)境快速部署和定制；

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

3.2 切流與擴量實踐

3.2.1 上云前改造

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

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

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

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

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

3.2.2 切流方案

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

接入層改造：

可借助接入層的 lua 腳本實現(xiàn)小流量切流，腳本實現(xiàn)了以下規(guī)則：

['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"，從左到右分別對應三段數(shù)字，即每種結果出現(xiàn)的概率，從而可以根據(jù)返回的結果實現(xiàn)流量控制；使用新增變量 $upstream_target 來標記最終 proxy 值，四種取值分別對應 pc 端和移動端實驗組 / 對照組流量：

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

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

業(yè)務層改造

業(yè)務層捕獲上述流量標記，分別創(chuàng)建并使用新的 Eid 發(fā)起商業(yè)請求，即可獲得當前實驗組 / 對照組各頁面商業(yè)流量數(shù)據(jù)。

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 云上網關切換

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

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

最終達到的效果：

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

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

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

3.3 架構演進

3.3.1 現(xiàn)狀 & 問題

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

3.3.2 演進方案

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

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

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

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

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

3.3.3 具體實現(xiàn)

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