一文解析百度知道上云與架構(gòu)演進

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

導(dǎo)讀?

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

01 背景與挑戰(zhàn)

1.1 背景

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

1.2 挑戰(zhàn)

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

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

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

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

1.3 收益

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

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

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

02 概念介紹

2.1 知道業(yè)務(wù)簡介

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

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

2.2 業(yè)務(wù)架構(gòu)

知道整體業(yè)務(wù)架構(gòu)如下圖所示：

2.3?流量架構(gòu)

上云前知道整體流量架構(gòu)如下圖所示：

03 上云設(shè)計與實踐

3.1 上云方案選型

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

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

3.1.1 why pandora

主要有幾個方面考慮：

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

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

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

3.1.2 why 知云

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

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

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

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

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

3.2 切流與擴量實踐

3.2.1 上云前改造

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

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

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

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

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

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

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

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

業(yè)務(wù)層改造

業(yè)務(wù)層捕獲上述流量標記，分別創(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 擴量相關(guān)

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

3.2.4 云上網(wǎng)關(guān)切換

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

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

最終達到的效果：

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

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

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

3.3 架構(gòu)演進

3.3.1 現(xiàn)狀 & 問題

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

3.3.2 演進方案

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

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

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

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

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

3.3.3 具體實現(xiàn)

知道核心流量三地域建設(shè)完成后流量架構(gòu)演進如下所示：