導讀：百度Feed資訊流推薦系統服務于手百、好看、全民、貼吧等公司絕大多數資訊流業務場景，随着業務的高速發展，整個系統承載的流量已經高達數十億，在龐大的流量規模背後是數百個微服務和數萬台機器做支撐。如何保證整套系統對外的高可用性是整個系統能力建設的關鍵，也是我們團隊的一個非常核心的工作方向。為了保障資訊流推薦系統常态5個9的可用性目标， 本文将基于我們實際的工作經驗分享介紹百度Feed線上推薦系統是如何建設高可用性架構的。
一、背景
百度Feed資訊流推薦系統服務于公司絕大多數資訊流業務場景，目前已經承載了手百、好看、全民、貼吧等多端産品的資訊流推薦能力。如下是從資源漏鬥次元給出的百度feed推薦系統的一個簡化示意圖。
△圖1：系統簡化示意圖
系統簡要說明如下：
資源索引庫：基于反向索引或是向量索引提供數千萬資源的索引查詢能力，通常會有數十甚至數百的不同的資源索引庫，分别提供不同類型的資源索引能力。
召回層：從數千萬的資源中召回跟使用者相關的數十萬的資源，通常與資源索引庫強綁定，比如一些顯式召回會在召回層基于使用者的tag去相應反向索引庫找到使用者相關的文檔資源。
排序層：在大型推薦系統中，為了平衡算力和效果會建構粗排&精排兩層排序體系，基于統一的預估打分機制從數萬的資源中找到使用者最感興趣的數百條資源送給混排層。
混排層：混排層從數百資源中根據使用者上下文資訊推薦出最終使用者看到的十幾條資源，通常也會耦合産品的幹預能力，比如資源的多樣性控制等。
使用者模型：使用者模型服務提供使用者級别的特征擷取能力，比如使用者感興趣的标簽集合。
文檔特征：文檔特征服務提供文檔級的全特征服務，通常基于文檔id通路擷取得到。
随着業務的高速發展，百度Feed推薦系統目前已經承載了數十億的線上請求流量，在龐大的流量規模背後是數百個微服務和數萬台機器做支撐。如何保證系統的高可用是整個系統架構設計的關鍵能力之一，也是我們整個團隊工作的一個核心方向。
為了保證線上推薦系統常态5個9的高可用目标，基于我們實際工作的不斷抽象沉澱，形成了我們整個架構的柔性處理能力。
△圖2：多層級柔性處理能力
如圖2所示，從對單請求的長尾逾時異常到IDC級大規模故障，基于我們的實際工作總結，都形成了相應的架構設計方案來應對，接下來進行具體的介紹
線上推薦系統是由數百個微服務所組成，并且在私有雲上進行了大規模的混部， 對于常态可用性名額影響最大的因素主要有兩個方面：
單執行個體故障所引起的可用性抖動，可能的引發原因包括機器當機、磁盤打滿，混部導緻的cpu過載等。
長尾請求逾時所導緻的失敗， 這通常是由于系統的一些随機因子所導緻，引發的原因多種多樣，且很難被抽象歸一，比如資源的競争、接收流量的瞬時不均、周期性的記憶體清理、旁路日志操作等運維活動。
通常對于這類問題的解決方案是增加重試機制和對于異常執行個體的屏蔽探活機制，我們的解決思路類似，但在實作方面對可能引發的問題做了進一步演進。
1.1 動态重試排程
重試機制最大的問題是重試時間的設定和雪崩問題：
重試時間設定的短，意味着常态下重試流量的比例會相對較大，造成資源的浪費，同時會更容易引發下遊服務的雪崩，比如一旦下遊出現大面積的延遲退化，就會導緻流量的整體翻倍，進而整個下遊服務都将被拖垮。
重試時間設定的長，意味着整個服務的逾時都會長，否則重試的效果就起不到有效的作用，在複雜的微服務排程鍊路上很容易引起逾時的倒挂。
當然重試時間的設定，我們可以基于某個狀态下去權衡利弊，給出一個近似的解來避免上面的問題， 但業務的快速疊代需要我們不斷的基于新的條件去更新這個值，這會帶來極大的運維成本。
基于上述問題的考慮，我們設計并實作了動态重試排程機制， 其核心思想是嚴格控制重試流量的比例(比如隻允許3%的流量觸發重試)，同時基于分位耗時的實時動态采集機制，将重試的機會配置設定給需要重試的流量，這同時也意味着我們不再需要手動去維護逾時時間的設定了。
如下是一個實作對比圖：
△圖3：動态重試排程
其核心實作包括：
後端分位耗時統計機制：将時間序列劃分為周期性的間隔(比如20s一個周期)，基于前一個周期的流量去統計分位耗時值，并結合配置化的重試比例來動态的确定backup_request_ms的值，基于rpc的請求級重試時間設定機制，就達成了我們動态逾時排程的目标了。
熔斷控制機制： 從分位耗時統計機制來看，可以發現這裡有個周期的滞後， 但不會對我們效果産生大的影響，這是因為前後兩個周期服務的延時變化不會發生很大的波動，隻要能夠處理極端情況下滞後所導緻的流量超發(可能引發的雪崩)問題就可以了， 而這正是熔斷控制機制所要解決的問題， 熔斷控制機制通過實時統計重試請求數量，并基于更小時間視窗來控制請求的比例，同時會通過平滑的機制去處理小視窗帶來的統計不準問題。
整個方案在推薦系統應用後，在常态下可用性相對能夠提升90%以上。
1.2 單執行個體故障處理
應對單執行個體故障通常采取的方案是屏蔽和探活機制，但在高可用架構上面還面臨如下挑戰：
識别能力上：這裡包含幾個次元的考量，準确率、召回率和時效性三個方面， 一方面基于單機視角的探活在時效性方面雖然能夠做到實時的效果，但由于局部視角的原因準确率往往不高，誤識别的機率較大，而基于全局資訊的采集往往會帶來時效性的大幅降低，同時在性能方面也會帶來一定折損。
政策處理上：一方面探活流量會導緻小部分流量的折損，同時非全局視角的屏蔽會導緻可用叢集的服務容量風險，進而帶來整體的惡化。
基于上述問題的考慮，我們在動态重試排程的基礎上，做了進一步的演進， 其核心思想在于實時動态的盡可能降低損失，異步準實時的做全局異常處理控制。
實時動态止損：動态重試機制應對的場景是無執行個體差異的長尾請求，為了應對單執行個體故障這個特定化的場景，這裡有兩個抽象的處理方案來解決，其一基于可用性和耗時回報的權重調節機制，利用可用性可以感覺到異常執行個體的存在，進而快速降低權重通路，同時在重試執行個體的選擇上也會加以區分；利用耗時回報的平滑調節，會基于壓力去自适應的調節正常執行個體的權重，保證正常執行個體的可用性不會因為容量問題打垮。
全局準實時的止損：基于我們內建在brpc架構内部的元件能夠快速的收集單機視角的執行個體級資訊，然後周期級别的去上報給統一的控制彙聚層。 通過高效的代碼實作以及兩層的彙聚機制基本上可以做到對client的性能無影響。更重要的是我們基于與pass的關聯來進一步控制我們對異常執行個體的控制政策，進而在保證可用性容量的前提下做徹底的止損。
△圖4：全局準實時止損方案
基于上述方案的實作，我們的系統基本上能夠自動的應對單執行個體故障的問題，可用性抖動相較于單純的動态重試方案，抖動區間更小，基本上在5s内就能得到收斂，同時在抖動區間可用性的降低幅度也相較于之前下降了50%。
這裡講的服務級故障指的是在微服務體系下某個子服務出現大規模不可用，基本上無法對外提供任何服務能力。目前基于雲原生的微服務化架構是整個業界的發展趨勢，設計良好的微服務體系能夠極大的提高整個系統開發的疊代效率，同時在穩定性方向也提供了更多可探索的空間。在微服務架構的基礎上，我們通過柔性架構的設計思想并結合多層級的容災設計來應對這種大規模的服務故障場景。這裡先給出其核心要點：
差異化對待異常：比如對于核心服務，我們需要有一定的機制應對可能潛在的異常；對于非核心的服務，我們要做的可能僅僅是控制它的異常不要擴散到核心鍊路。
多層級容災機制：通過多層級的容災機制，當大規模故障發生時，能夠在一定的時間内保障使用者體驗的基本無損。
當然服務級故障的處理需要依托于具體的業務場景來做具體的設計，這裡給出部分例子來說明在Feed推薦系統是如何來進行處理的。
2.1 多召回排程架構
在推薦系統中，由于召回方式的差異性，往往會設計成多召回架構，每路召回負責某種具體的召回能力，比如從資源層面看，我們可以分為圖文召回，視訊召回， 從召回算法層面，我們可以分為itemcf召回，usercf召回等。就單召回路而言，對整體服務的影響取決于它的功能劃分：
一級召回：比如營運控制相關的召回， 直接影響産品的體驗感覺， 不允許失敗；
二級召回：決定了資訊流分發效果，這些召回路如果失敗，會導緻大盤分發下降顯著， 單路可允許短期失敗，但多路不能同時失敗；
三級召回：補充召回路，比如探索興趣召回，對長期效果起到一定增益作用，短期對産品效果影響不顯著，允許短期失敗。
對于三級召回路，服務調用失敗雖然短期對産品影響不顯著，但大規模的逾時失敗會導緻整體性能的延遲退化，進而影響到整體服務的可用性。一種直接粗暴的解決方案就是調小這些召回路的逾時時間，使得其即使逾時也不會影響到整體，但這顯然會降低這些服務的常态可用性，不是我們想要的效果， 為了抽象統一的解決這個問題， 我們設計了多召回排程架構， 具體設計如下：
△圖5：多召回排程架構
其核心設計包括：
召回等級劃分：一級召回不允許主動丢棄；二級召回路劃分多個群組，目前我們按照資源類型劃分，圖文召回群組&視訊召回群組&...；每個召回群組由對分發貢獻最大的幾個召回路組成， 群組内部允許超過40%(可配)的召回路主動丢棄；三級召回路則允許主動丢棄；
丢層機制：當滿足要求的召回路都傳回後，剩下沒有傳回的召回路會主動丢棄，不在等待傳回結果了；
補償機制：丢棄對産品效果始終還是有影響的，隻是影響較小而已， 為了将這部影響降低到最小，我們設計了旁路的cache系統，當主動丢棄發生後，利用上次的結果cache作為本次的傳回，進而一定程度的降低損失。
基于上述方案的實作，通過我們實際的演練結果，目前我們整個系統能自動應對二/三級召回隊列服務級故障的處理。
2.2 排序層故障解決方案
排序服務建構在召回之上，提供對多路召回資料的一個統一打分機制，進而完成資源的整體排序， 目前業界通常采用粗排&精排的兩層排序體系來解決算力和效果相沖突的問題。
粗排通過雙塔模型的設計能在一次使用者請求中支援數萬的資源排序預估，但效果相對來說偏弱；
精排通過更複雜的網絡模型能提供效果更優的排序能力，但支援的預估數量級隻有千級别；
召回 → 粗排 → 精排 的漏鬥過濾體系在算力一定的情況下很好的提升了推薦效果。
可以看到，排序服務對整個推薦效果至關重要，一旦排序服務出現大規模異常，基本上就是在數萬的資源裡面進行随機推薦了。為了防止這類問題的發生，在設計之初我們也是充分考慮了故障的應對場景，其核心思路是建設層級的降級機制。
△圖6：排序層降級方案設計
建構一層穩定的中間代理層Router：改層邏輯簡單，疊代少，穩定性高，提供異常發生時的降級能力；
粗排異常處理方案：旁路建設一路基于資源的點展比和時長資訊的排序能力，資料由離線後延統計資訊挖掘得到，當粗排服務發生大規模異常時，利用該路資訊提供應急排序能力；
精排異常處理方案：粗排的排序效果相比精排要差，但可以作為精排異常的時候降級資料供整個系統使用，當精排服務發生大規模異常時，直接利用粗排服務進行降級。
相比于随機推薦來說，整套排序層故障解決方案能夠大幅降低故障時對推薦效果的影響。
2.3 彈性容災機制
基于排序層故障解決方案的進一步演進，我們建構了針對全系統的彈性容災機制，其目标是用一套統一的架構支援異常的處理，當異常發生的時候，降低對使用者的體驗感覺和政策效果的影響。
△圖7：彈性容災新架構
穩定的推薦系統入口子產品Front：該子產品是推薦系統的入口層，定位是不耦合任何業務邏輯，隻支援彈性容災相關的能力；
分層的異常資料建設：個性化容災資料 + 全局容災資料， 個性化容災資料通常基于跨重新整理資料的緩存來建構， 全局容災資料通過旁路挖掘來建構；
統一的異常感覺機制：跨服務的異常透傳能力，當上層Front感覺到核心服務異常時，就優先擷取個性化容災資料來進行容災，若無個性化容災資料，即通路全局容災資料來進行容災。
我們通過資訊流的置頂資料的異常處理來做說明。
全量容災資料的挖掘：旁路周期性的将所有可用的置頂資料寫入全局的容災cache中；
個性化容災資料的建構：當使用者前一刷的時候，置頂召回服務會取出符合使用者條件的最佳置頂資料集合，将這部分資料寫入個性化容災資料cache；
服務失敗感覺：當置頂召回通路失敗，或是從Front到置頂召回服務之間任何鍊路失敗時， Front接收到的資料傳回包裡面都沒有标志置頂資料成功的标記；
容災控制：Front會基于傳回資料做判斷，如沒有成功标記，則開始進行容災處理，優先讀取個性化置頂容災資料，沒有讀取到，則開始利用全局容災資料進行容災。
該機制建構了統一的彈性容災能力，一方面利用個性化資料在容災時盡可能保證政策的損失最小，另一方面利用全局的容災資料進行兜底容災盡可能的保證使用者體驗的無感覺。
IDC級的故障解決方案通常采用異地多主方案來解決，即故障發生時通過idc切流來及時止損， 百度推薦系統也采用類似的方案來解決，這裡我們通過下發曆史存儲服務的異地多主方案設計來做個介紹。
下發曆史存儲服務提供使用者級别最近的下發、展現、點選過的資源。基于它提供跨請求的政策支援，比如多樣性控制， 更重要的是防止重複資源的下發。一旦服務挂掉将整個推薦服務将無法對外提供服務。
其整體設計如下：
△圖8：下發曆史存儲服務多主架構
每個地域維護一份全量的存儲；
對于讀請求，隻允許讀本地idc；
對于寫請求，同步寫入本地機房，同時進行跨idc同步寫入，若寫入失敗，則寫入消息隊列，由消息隊列進行異步跨idc進行寫操作更新。
當出現idc級故障時，基于異地多主多活架構能夠快速支援切流止損。
百度Feed推薦架構支援着業務的高速疊代發展，在整個架構演進過程，可用性建設一直是系統架構能力的關鍵名額，我們通過柔性架構的建設，保證了對外常态5個9的高可用目标，并具備應對正常大規模故障的能力。
△圖9：近一個月的出口可用性名額
本期作者 | windmill & smallbird
<b></b>
<b>閱讀原文：https://mp.weixin.qq.com/s/sm8eehjoUEqvF_PS4VcRKg</b>
推薦閱讀
｜百度資訊流和搜尋業務中的彈性近線計算探索與應用
｜有趣！有料！有溫度！「百度技術沙龍」全新更新，重磅回歸！
---------- END ----------
百度架構師
百度官方技術公衆号上線啦！
技術幹貨 · 行業資訊 · 線上沙龍 · 行業大會
招聘資訊 · 内推資訊 · 技術書籍 · 百度周邊
歡迎各位同學關注！