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

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

導(dǎo)讀?

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

01 背景與挑戰(zhàn)

1.1 背景

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

1.2 挑戰(zhàn)

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

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

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

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

1.3 收益

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

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

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

02 概念介紹

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

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

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

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

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

2.3?流量架構(gòu)

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

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

3.1 上云方案選型

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

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

3.1.1 why pandora

主要有幾個(gè)方面考慮：

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

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

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

3.1.2 why 知云

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

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

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

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

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

3.2 切流與擴(kuò)量實(shí)踐

3.2.1 上云前改造

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

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

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

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

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

3.2.2 切流方案

小流量實(shí)驗(yàn)方案如下圖所示：

接入層改造：

可借助接入層的 lua 腳本實(shí)現(xiàn)小流量切流，腳本實(shí)現(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"，從左到右分別對(duì)應(yīng)三段數(shù)字，即每種結(jié)果出現(xiàn)的概率，從而可以根據(jù)返回的結(jié)果實(shí)現(xiàn)流量控制；使用新增變量 $upstream_target 來標(biāo)記最終 proxy 值，四種取值分別對(duì)應(yīng) pc 端和移動(dòng)端實(shí)驗(yàn)組 / 對(duì)照組流量：

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

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

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

業(yè)務(wù)層捕獲上述流量標(biāo)記，分別創(chuàng)建并使用新的 Eid 發(fā)起商業(yè)請(qǐng)求，即可獲得當(dāng)前實(shí)驗(yàn)組 / 對(duì)照組各頁(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 擴(kuò)量相關(guān)

以知道核心問答頁(yè)為例，擴(kuò)量的每個(gè)階段都有該階段需重點(diǎn)關(guān)注的工作內(nèi)容，及進(jìn)入下一個(gè)階段的準(zhǔn)入 list，需要 list 內(nèi)容全部達(dá)標(biāo)，才可開啟下一階段擴(kuò)量實(shí)驗(yàn)。具體說明如下：

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

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

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

最終達(dá)到的效果：

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

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

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

3.3 架構(gòu)演進(jìn)

3.3.1 現(xiàn)狀 & 問題

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

3.3.2 演進(jìn)方案

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

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

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

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

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

3.3.3 具體實(shí)現(xiàn)

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