百度搜索与推荐引擎的云原生改造
導讀：從去年開始，百度MEG（移動生態事業群）架構平臺上的用戶產品逐步進行云原生改造，如今已基本完成。現階段更多關注動態彈性能力、動態管理機制的建設。我們邀請到來自百度推薦技術架構部的傳玉老師， 跟大家聊聊百度搜索與推薦引擎云原生改造的階段性策略，以及對未來發展的思考。
嘉賓簡介 ：傳玉
2012年起專注于搜索引擎與推薦引擎方向；2016年開始負責自有的資源調度和容器編排系統的研發工作；2019年開始負責部分通用基礎組件的研發工作，并開始在MEG用戶產品內部全面推進云原生架構改造。
01 核心關注兩個“效率”，實現降本增效
“說云原生的目標是讓整個開發上線應用的過程更簡單，這一點我是同意的。百度的搜索與推薦引擎規模都非常龐大、業務極其復雜，尤其是搜索，有著20多年的歷史，無法完全按照一套新的理念來設計邏輯。所以，我們在嘗試云原生時，必須結合我們自己的基因和現狀。”
云原生架構的主要價值在于效率的提升，包括資源利用效率和研發效率兩個方面。
從資源利用效率上，期望通過容器化和動態資源調度實現在線服務的充分混布，讓集群整體資源使用更加均衡，更加高效，從而降低整體的機器成本。此外，通過云平臺實現高效率的資源化交付取代物理整機交付，提升資源的流轉效率，讓內部的資源能夠更快速地流轉到重點業務上，支持業務的快速發展。
在研發效率上，一方面通過微服務改造，解耦不同業務團隊的迭代，減少團隊間的互相影響，去提升業務迭代效率。另一方面期望把通用基礎架構能力下沉到云原生基礎設施上，提升新業務架構能力的基線水平。
例如一些局部故障容錯能力，在一些業務線上類似的架構機制已經很成熟了，但對于新的業務線很難直接復用，往往還需要再踩坑，參照成熟業務線的經驗，逐步建設，如果我們能把這些通用的能力以標準化和規范化的形式沉淀到云原生基礎設施里，那創新業務線就能比較簡單地復用，少走彎路，盡可能少欠技術債。
此外，云原生架構對研發效率上的提升，還體現在降低線上問題的處理以及維護上人力和時間。
通常業界有個說法：一個存儲系統好不好用，關鍵看他的運維水平。
但實際上，不僅是存儲系統，對于很多創新項目來講，如果太多的人去支持維護線上服務的運行解決線上問題，那么投入研發上的人力就相對減少了，相應的發展速度可能就會受影響
通過一些云原生的基礎設施，我們可以把各種常規的運維操作標準化和自動化，比如機器故障的自動維修，服務實例故障自動遷移，服務容量的自動化調整。一方面可以減少運維的人力成本，另一方面很多情況下自動化的系統能比人工做的更好。
“在之前，我們也是有自動化機制的。但應用云原生架構帶來的好處，是讓我們能夠通過一個更規范、更標準、更可持續發展的路徑，去做這些自動化的機制。就是把那個大量的人力從這種線上服務的維護中解放出來。在團隊規模不變的情況下，維護人力減少了，能全力投入研發上的人力自然就多了，整體研發效率也就上來了。”
總體來說，云原生最大的意義在于提高效率，提高了整體研發的baseline。
尤其是在做新產品時，能夠省去購買資源的成本，在基礎階段也省去用太多的人力投入來保障產品上線順利。成本越低、能做的創新就越多。這樣就讓每一個新產品都避免輸在起跑線上。
02 規范服務設計標準，為云原生改造立好規矩
MEG架構平臺在2019年時已經全面云化。但是，多數服務的遷移僅僅是部署方式從物理機部署轉變為PaaS平臺容器內部署，并沒有針對云環境以及云能力進行架構上的改造和升級來獲得更大的成本和效率上的收益。基于這一問題，期望通過進一步規范MEG架構平臺服務設計標準，實現從云化架構到云原生架構的轉變。
“實現云原生化之前，我們已經具備一定的基礎。首先是從整個組織上具備了微服務的思想；其次是從實踐上制定了一系列微服務最佳實踐的標準，建立了《MEG用戶產品架構云原生內部規范》；第三，我們已經有一系列公共的基礎設施。”
傳玉參考了業內廣泛認可的云原生應用的特征，結合百度內部的先行實踐，為了保證云原生架構落地的效率和效果，從以下三個方面來規范服務模塊設計：
*各項規范的評估方式：
| 資源開銷 | 由資源平臺統計，按實例總數計算符合規范的比例 |
| 部署時間 | 由PaaS平臺統計，按實例總數計算符合規范的比例 |
| – | – |
| 單一包描述 | 由業務自行上報，OP驗收 - 以部署平臺收到包描述，能夠自動完成服務部署為準，按實例總數計算符合規范的比例 |
| 僅存在資源依賴 | 業務上報，OP驗收 - 以PaaS平臺在任意資源滿足的機器上可完成實例部署&啟動&測試為準，按實例總數計算符合規范的比例 |
| – | – |
| 通過Naming Service訪問 | 業務上報，OP驗收 - 通過PaaS平臺遷移實例，能夠成功遷移，且系統無異常為準，按實例總數計算符合規范的比例 |
| 可容忍單點異常 | OP驗收/混沌工程實驗驗收，按實例總數計算符合規范的比例 |
| – | – |
| 服務狀態可感知 | 業務上報，OP驗收 - 以PaaS平臺能夠正常識別服務啟停為準 |
*業務整體評估方式：
03 劃重點，云原生化的階段性實現路徑
從云化到云原生化，是一個非常復雜的過程。在制定了云原生改造規范后，陸續經歷了4個階段，分別是：微服務改造、容器化改造、動態管理、進階云原生，而MEG的云原生化進程并未停止，而是朝著第5個階段——聲明式架構繼續探索。
第一階段：微服務改造
起初，百度MEG架構平臺實現全面云化時，將所有的架構服務、資源都托管到內部的云平臺上，但是當時仍遇到了對資源的利用問題。MEG架構平臺推行云原生的第一件事，就是要求所有的服務去做微服務改造，消滅巨型服務。
“這些巨型服務，會導致整體的資源分配容易出現碎片，比如某個服務占用一臺機器80%的資源，那剩下20%很有可能分不出去，就會出現獨占的現象，不能混布。還有一些服務在部署之前，要對整機的環境做一些修改。
因此，雖然當時所有的資源都托管在了云平臺上，但我們在使用時仍然與直接使用機器差異不大，OP投入了很多，整體線上資源利用率，包括資源的分配率，相對較低。”
微服務拆分之后，帶來了幾個變化：首先是性能提升。
雖然多了一些RPC的開銷，但拆分之后，每一個服務都可以被針對性的優化，所有的擴縮容操作亦可只針對這一服務的邏輯進行。因此從整體成本、延遲等各方面使性能達到大幅提升。
其次是研發效率提升。
按原來的產品和策略的迭代，很多時候一個服務需要幾百人共同進行，上線耗時長。但拆分之后，雖然多出幾十個模塊，但一個模塊只需兩三個人迭代即可，也可以隨時隨地上線。這對研發效率整體提升是很大的。
“比如說我們的Feed視頻推薦服務，在拆分前是一個巨型服務，迭代頻繁。單實例450 CPU，100G內存，單模塊越40+ 策略RD參與開發，每天上線feature 10+個。所以在運營過程中產生了大量資源碎片、上線時間長、內存迭代困難。
我們做了3件事：
第一，按推薦業務邏輯，拆分為聚合和召回兩層；
第二，召回層按召回算法區分，拆分為若干并行的召回服務，召回服務部分可丟；
第三，聚合層拆分為機器學習預估服務和聚合服務兩塊，機器學習服務使用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架構平臺完成云原生改造的一些關鍵路徑。
在后續的分享中，傳玉還會圍繞服務治理、自動化、混沌工程等方面，重點聊聊過程中的一些問題和解決辦法。
更多精彩內容歡迎關注百度開發者中心公眾號。
總結
以上是生活随笔為你收集整理的百度搜索与推荐引擎的云原生改造的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 百度 Serverless 架构揭秘与应
- 下一篇： 百度开发者中心全新升级 | 文末六一送福