百度搜索與推薦引擎的雲原生改造 | Geek大咖說第一期

時間 2021-04-14

標籤前端算法微信架構併發 app 負載均衡 less 運維機器學習欄目系統架構简体版

原文原文鏈接

導讀：從去年開始，百度MEG（移動生態事業羣）架構平臺上的用戶產品逐步進行雲原生改造，現在已基本完成。現階段更多關注動態彈性能力、動態管理機制的建設。本期「Geek大咖說」，咱們邀請到來自推薦技術架構部的傳玉老師，跟你們聊聊百度搜索與推薦引擎雲原生改造的階段性策略，以及對將來發展的思考。前端

嘉賓簡介：傳玉算法

2012年起專一於搜索引擎與推薦引擎方向；2016年開始負責自有的資源調度和容器編排系統的研發工做；2019年開始負責部分通用基礎組件的研發工做，並開始在MEG用戶產品內部全面推動雲原生架構改造。微信

01 核心關注兩個「效率」，實現降本增效
「說雲原生的目標是讓整個開發上線應用的過程更簡單，這一點我是贊成的。百度的搜索與推薦引擎規模都很是龐大、業務極其複雜，尤爲是搜索，有着20多年的歷史，沒法徹底按照一套新的理念來設計邏輯。因此，咱們在嘗試雲原生時，必須結合咱們本身的基因和現狀。」
雲原生架構的主要價值在於效率的提高，包括資源利用效率和研發效率兩個方面。
從資源利用效率上，指望經過容器化和動態資源調度實如今線服務的充分混布，讓集羣總體資源使用更加均衡，更加高效，從而下降總體的機器成本。此外，經過雲平臺實現高效率的資源化交付取代物理整機交付，提高資源的流轉效率，讓內部的資源可以更快速地流轉到重點業務上，支持業務的快速發展。
在研發效率上，一方面經過微服務改造，解耦不一樣業務團隊的迭代，減小團隊間的互相影響，去提高業務迭代效率。另外一方面指望把通用基礎架構能力下沉到雲原生基礎設施上，提高新業務架構能力的基線水平。
例如一些局部故障容錯能力，在一些業務線上相似的架構機制已經很成熟了，但對於新的業務線很難直接複用，每每還須要再踩坑，參照成熟業務線的經驗，逐步建設，若是咱們能把這些通用的能力以標準化和規範化的形式沉澱到雲原生基礎設施裏，那創新業務線就能比較簡單地複用，少走彎路，儘量少欠技術債。
此外，雲原生架構對研發效率上的提高，還體如今下降線上問題的處理以及維護上人力和時間。 一般業界有個說法：一個存儲系統好很差用，關鍵看他的運維水平。
但實際上，不只是存儲系統，對於不少創新項目來說，若是太多的人去支持維護線上服務的運行解決線上問題，那麼投入研發上的人力就相對減小了，相應的發展速度可能就會受影響經過一些雲原生的基礎設施，咱們能夠把各類常規的運維操做標準化和自動化，好比機器故障的自動維修，服務實例故障自動遷移，服務容量的自動化調整。一方面能夠減小運維的人力成本，另外一方面不少狀況下自動化的系統能比人工作的更好。 「在以前，咱們也是有自動化機制的。但應用雲原生架構帶來的好處，是讓咱們可以經過一個更規範、更標準、更可持續發展的路徑，去作這些自動化的機制。就是把那個大量的人力從這種線上服務的維護中解放出來。在團隊規模不變的狀況下，維護人力減小了，能全力投入研發上的人力天然就多了，總體研發效率也就上來了。」 整體來講，雲原生最大的意義在於提升效率，提升了總體研發的baseline。
尤爲是在作新產品時，可以省去購買資源的成本，在基礎階段也省去用太多的人力投入來保障產品上線順利。成本越低、能作的創新就越多。這樣就讓每個新產品都避免輸在起跑線上。架構

02 規範服務設計標準，爲雲原生改造立好規矩
MEG架構平臺在2019年時已經全面雲化。可是，多數服務的遷移僅僅是部署方式從物理機部署轉變爲PaaS平臺容器內部署，並無針對雲環境以及雲能力進行架構上的改造和升級來得到更大的成本和效率上的收益。基於這一問題，指望經過進一步規範MEG架構平臺服務設計標準，實現從雲化架構到雲原生架構的轉變。「實現雲原生化以前，咱們已經具有必定的基礎。首先是從整個組織上具有了微服務的思想；其次是從實踐上制定了一系列微服務最佳實踐的標準，創建了《MEG用戶產品架構雲原生內部規範》；第三，咱們已經有一系列公共的基礎設施。」傳玉參考了業內普遍承認的雲原生應用的特徵，結合百度內部的先行實踐，爲了保證雲原生架構落地的效率和效果，從如下三個方面來規範服務模塊設計：併發

一、微服務化： 每一個服務粒度應該在限定的範圍內； 二、容器化封裝： 一個服務的部署，應該只依賴基礎架構以及本容器內的組件，而不該該依賴其餘業務服務； 三、動態管理： 每一個服務應該能夠動態調整部署，而不影響自身對外承諾的SLA。

*各項規範的評估方式：app

規範	驗收方式
資源開銷	由資源平臺統計，按實例總數計算符合規範的比例
部署時間	由PaaS平臺統計，按實例總數計算符合規範的比例
單一包描述	由業務自行上報，OP驗收 - 以部署平臺收到包描述，可以自動完成服務部署爲準，按實例總數計算符合規範的比例
僅存在資源依賴	業務上報，OP驗收 - 以PaaS平臺在任意資源知足的機器上可完成實例部署&啓動&測試爲準，按實例總數計算符合規範的比例
經過Naming Service訪問	業務上報，OP驗收 - 經過PaaS平臺遷移實例，可以成功遷移，且系統無異常爲準，按實例總數計算符合規範的比例
可容忍單點異常	OP驗收/混沌工程實驗驗收，按實例總數計算符合規範的比例
服務狀態可感知	業務上報，OP驗收 - 以PaaS平臺可以正常識別服務啓停爲準

*業務總體評估方式：負載均衡

一、未接入PaaS的服務，以不知足標準計算；二、以服務爲單位評估是否知足規範，只有當一個服務同時知足上述全部標準時，才認爲一個服務是知足雲原生架構規範的；三、每一個業務線以百分制計算雲原生規範指數，計算方式爲（符合規範的服務模塊所佔的quota總量 / 總quota），使用CPU quota/MEM quota，按比例低的計算；四、各單項分數，僅做爲內部指標參考, 用於分析瓶頸，推進落地。

03 劃重點，雲原生化的階段性實現路徑
從雲化到雲原生化，是一個很是複雜的過程。在制定了雲原生改造規範後，陸續經歷了4個階段，分別是：微服務改造、容器化改造、動態管理、進階雲原生，而MEG的雲原生化進程並未中止，而是朝着第5個階段——聲明式架構繼續探索。
第一階段：微服務改造
起初，百度MEG架構平臺實現全面雲化時，將全部的架構服務、資源都託管到內部的雲平臺上，可是當時仍遇到了對資源的利用問題。MEG架構平臺推行雲原生的第一件事，就是要求全部的服務去作微服務改造，消滅巨型服務。 「這些巨型服務，會致使總體的資源分配容易出現碎片，好比某個服務佔用一臺機器80%的資源，那剩下20%頗有可能分不出去，就會出現獨佔的現象，不能混布。還有一些服務在部署以前，要對整機的環境作一些修改。
所以，雖然當時全部的資源都託管在了雲平臺上，但咱們在使用時仍然與直接使用機器差別不大，OP投入了不少，總體線上資源利用率，包括資源的分配率，相對較低。」 微服務拆分以後，帶來了幾個變化：首先是性能提高。
雖然多了一些RPC的開銷，但拆分以後，每個服務均可以被針對性的優化，全部的擴縮容操做亦可只針對這一服務的邏輯進行。所以從總體成本、延遲等各方面使性能達到大幅提高。
其次是研發效率提高。
按原來的產品和策略的迭代，不少時候一個服務須要幾百人共同進行，上線耗時長。但拆分以後，雖然多出幾十個模塊，但一個模塊只需兩三我的迭代便可，也能夠隨時隨地上線。這對研發效率總體提高是很大的。「好比說咱們的Feed視頻推薦服務，在拆分前是一個巨型服務，迭代頻繁。單實例450 CPU，100G內存，單模塊越40+ 策略RD參與開發，天天上線feature 10+個。因此在運營過程當中產生了大量資源碎片、上線時間長、內存迭代困難。
咱們作了3件事：less

第一， 按推薦業務邏輯，拆分爲聚合和召回兩層； 第二， 召回層按召回算法區分，拆分爲若干並行的召回服務，召回服務部分可丟； 第三， 聚合層拆分爲機器學習預估服務和聚合服務兩塊，機器學習服務使用avx指令集加速。」

Feed視頻推薦服務改造的成果是：運維

l 單個大模塊拆分爲10+個小模塊，最大的模塊內存佔用 < 40G. l 總體cpu佔用減小23%，內存佔用減小84% l 延遲下降50+ms，穩定性從不足99.9%提高到99.97% l 迭代效率大幅提高，完全消除了搭車上線互相block的狀況.

第二階段：容器化改造
MEG架構平臺作容器化改造，就是要求全部的服務把它依賴的東西，都放到容器內。實現全部服務的一鍵式的部署，也就是自動化的部署。可能如今的一些新興的互聯網企業中並不存在這一的問題，由於你們不少服務自己就是基於 Docker 的。但百度搜索系統具備二十年曆史，必須花時間去作這件事。這個過程當中，一個典型是改造搜索的BS模塊，它的年齡幾乎和百度搜索同樣大。二十年前，百度架構師在設計BS時，考慮的是儘量佔滿整機資源。「那個時候 SSD 很是昂貴，因此設計BS時，就但願能把SSD用滿，同時，爲了方便，並無所有顯示申請，好比你聲明瞭用10G，而實際上卻用了60G。這在當時沒什麼問題，由於一臺機器只有一個服務，使用資源時不管是顯示仍是隱式，都跟別人不要緊。如今的磁盤硬件已經跟二十年前徹底不一樣了，單個服務的計算量每每不足以佔滿徵集整機資源，爲了不浪費，就須要把其餘服務混布上去。這樣一來，問題就出現了，就得改。」 第一件事，每一個服務顯式地聲明自身須要佔用的資源，改掉貪婪式搶佔的策略。
把全部的資源放在他本身的容器裏。也就是說，把BS從一個機器級的服務，變成了一個容器級的服務，不佔用容器外資源。作到這一點，才能讓容器編排系統的調度能力真正發揮做用。 第二件事是提高服務的部署效率。
有一些比較老的服務，可能部署的時候須要去拉不少額外的數據，甚至部署的時候還須要op去人工作一些機器的參數和配置調整。這都會致使部署無法自動化執行，或者部署的速度太慢。爲了改善效率，須要把服務對於物理環境的依賴都消除，只依賴容器內的環境。此外，咱們也須要作P2P的下載優化，和一些數據的實時化的改造，去優化服務啓動的速度。「咱們以前曾經用過一個存儲數據類的服務，邏輯上來講是能遷移的，但實際上一個實例的遷移大概耗費8小時。這種的可遷移性就沒有太大意義。由於存儲數據服務受副本數/容量/併發數的限制，好比說一個集羣有成百上千個實例，但最多一輪只能遷移幾個，而後遷移一輪的話，要耗費8個小時。那整個集羣遷移的時間就會很是長。想進行內核升級、操做系統升級、故障維修等就會很是麻煩。所以，咱們要作P2P分發優化，作數據下載和數據分發的優化，把部署速度提上去。」

機器學習

第三階段：動態管理
動態管理這件事，主要說的「動態」，好比線上服務是否能隨時遷移、隨時擴縮容。
它分爲兩個層面： 一方面從業務自己來看，動態管理要求全部的服務都具有必定程度的彈性和容錯能力。
由於線上的實例但凡涉及到擴縮容或遷移，就會出現短期內的重啓或不可用。這就首先要求線上全部服務都具有必定的故障容忍能力。其次，服務須要具有自動的負載均衡的能力（最簡單的方式就是使用naming service來訪問服務），有新的實例加入，須要能自動去打散流量，有實例故障或者退場，也須要能及時屏蔽 另外一方面從基礎設施層面來看，既然全部的服務都能隨時作遷移和擴縮容。
那咱們就能夠在服務的容量和流量上按需操做實現自動化的按需分配。「一旦某個業務要作一個運營活動，就須要臨時作大量的擴容操做。這個過程在非雲原生的模式下原來很麻煩，要先去找一批物理機，而後把服務部署到這批新機器上實現擴容，作完了活動之後再把服務下掉，以後再退出物理機，整個過程涉及到大量的人工操做，成本是比較高的。但在動態改造後，找物理機的操做就沒有了。咱們全部的服務在一個大的資源池裏面。任意業務短期內須要額外的資源，直接在裏面擴縮容就行了。由於不一樣業務的需求時段也不一樣，還能錯峯使用。「再有就是資源使用的彈性上，好比說對於我本身的推薦系統來講，若是資源池裏有額外的資源可用，這能讓個人推薦系統經過更多的複雜計算來提供更好的用戶體驗。因此在沒有運營活動時，咱們用這部分閒置資源來提高推薦和檢索效果。當有運營活動時，咱們再把這份資源吐出來給運營活動。這樣方便咱們總體對資源進行平衡使用，並且這個過程應該是一個代價很是低的一個自動化的操做。」

第四階段：進階雲原生
爲了繼續下降成本、提高效率，從2021年開始，MEG架構平臺的雲原生改造，在動態管理的基礎上增長了像Serverless、Function as a Service等進一步的操做。在改造以前，整個系統的那個容量是基本固定的，一旦有突發流量就只能降級。經過Serverless機制，實時監控流量，發現異常就能在幾分鐘內自動完成擴容。而Function as a Service的話，是讓研發效率提高到極致的一個方向。它能讓業務同窗只關心本身想要實現的邏輯。至於在架構上怎麼拆分微服務、怎麼作流量的調控、怎麼作作容量管理，所有交給底層的系統來執行。

第五階段聲明式架構
傳玉提到，其實在進階雲原生階段作的一些事情，都在向着聲明式架構靠攏。好比Function as a Service就是聲明式架構中關鍵的一環，包括Serverless機制的實現，最終目標也是但願能把策略和架構完全解耦。「如今不少架構在設計的初期都是沒什麼太大的問題的。但隨着業務發展，運行了一段時間後每每都須要重構，由於隨着業務的變化，系統面臨的業務場景已經不同了。但架構的調整是很是複雜的，通常都會傷筋動骨，還會涉及到大量的業務策略邏輯遷移等。咱們指望儘量的把業務和架構拆分開，把業務邏輯和架構設計拆分開。這樣業務描述邏輯時儘量簡單，咱們的系統能夠根據這些描述自動拆分Function，再把這些Function發送到系統裏去執行。」 若是能作到架構&業務分離，那麼MEG架構平臺會變得很是靈活。
包括有哪些節點、執行哪些Function、用這些Function怎麼去作鏈接、怎麼去作組合，所有交由自動的推導系統去實現。如此一來，咱們的系統會變成聲明式的，也就是說你在上面聲明你的業務邏輯，它會自動推導出須要怎樣的架構，自動去執行。「這樣這固然是一個最終的理想態。咱們在實現的路上，還須要作不少不少事情。」以上，是百度MEG架構平臺完成雲原生改造的一些關鍵路徑。在後續的分享中，傳玉還會圍繞服務治理、自動化、混沌工程等方面，重點聊聊過程當中的一些問題和解決辦法。