阿里巴巴複雜搜索系統的可靠性優化之路

背景

搜索引擎是電商平臺成交鏈路的核心環節，搜索引擎的高可用直接影響成交效率。閒魚搜索引擎做爲閒魚關鍵系統，複雜度和系統體量都很是高，再加上閒魚全部導購場景都依靠搜索賦能，搜索服務的穩定可靠成爲了閒魚大部分業務場景可用能力的衡量標準；如何保障搜索服務的穩定和高可用成爲了極大的挑戰。

閒魚搜索做爲閒魚核心系統，有如下幾個突出的特色：

• 數據體量大：對接閒魚數十億的商品，引擎有效商品數億；
• 索引龐大：閒魚非結構化商品須要與算法團隊合做，預測抽取有價值的結構化信息，創建索引；已建立數百的索引字段，整個引擎索引數據量爲T級別；
• 增量消息多：平常增量消息QPS 數十萬，峯值QPS能夠達到 數百萬；
• 查詢複雜：不少特殊業務場景，查詢條件要求苛刻而複雜；好比召回GROUP分組統計，聚合/打散/去重，關鍵詞複合運算查詢等；
• 實時性性要求高：閒魚中都是二手商品，賣家商品的庫存都是1；商品上下架頻繁，對引擎數據的同步更新實時性要求很是高；
• 智能化擴展：因爲閒魚商品非結構化特性，爲保障召回數據的效果以及相關性；須要引擎具有智能插件擴展的能力，能與算法開發人員協同；

鑑於閒魚商品搜索引擎以上主要特色，本文詳細介紹閒魚搜索在系統高可用上作的各類努力，但願能給讀者一些啓發。

閒魚搜索總體架構

正式引出搜索穩定性保障方案以前，咱們須要對閒魚搜索技術有一個簡單大體的瞭解；

咱們比較過不少外部開源的搜索引擎，都不能完美支持背景中所列的需求點；閒魚使用的是阿里巴巴最新研發的搜索引擎平臺Ha3，Ha3是一款很是高效，智能強大的搜索引擎，它徹底知足閒魚搜索的要求；
Elasticsearch是基於Lucene的準實時搜索引擎，也是比較經常使用的開源搜索引擎，可是其在算法擴展支撐/絕對實時的能力上與Ha3相差甚遠；在同等硬件條件下，基於1200萬數據作單機性能對比測試發現，Ha3比ElasticSearch開源系統的QPS高4倍，查詢延遲低4倍；Elasticsearch在大規模數據量場景下的性能和穩定性與HA3相比尚有很大的差距。

01閒魚搜索體系運行流程

下圖是閒魚搜索體系系統結構圖，主要分在線和離線兩個流程；

索引構建流程

索引構建即咱們所謂的離線流程，其執行者BuildService①，負責將不一樣存儲類型的純文本商品數據構建成搜索引擎格式的索引文件。原始的商品數據有兩類，一類是存放在存儲上的全量商品數據，這個按期(通常以天爲週期)經過DUMP②產出，另外一類爲實時變動的數據，在商品信息變動後，由業務系統即時同步給消息系統Swift③。最終分發給在線服務的Searcher④更新索引。

搜索查詢流程

搜索查詢即咱們所謂的在線流程；閒魚搜索服務應用A發起搜索請求，經過SP⑤進行服務能力編排；首先SP發起QP⑥算法服務調用，進行用戶意圖預測，並獲取排序輔助信息；而後結合QP返回的結果加上業務系統的查詢參數，向Ha3搜索引擎發起查詢請求；Ha3搜索引擎QueryService⑦中Qrs⑧接收到查詢請求後，分發給QueryService中的Searcher進行倒排索引召回、統計、條件過濾、文檔打分及排序、摘要生成；最後Qrs將Searcher返回的結果進行整合後返回給SP，SP通過去重再返回給業務系統；

02閒魚搜索體系團隊構成

閒魚搜索的運維體系，是一個至關複雜的構成；其中涉及不少團隊的鼎力協做；

首先必須有Ha3搜索引擎團隊在底層提供核心的搜索引擎能力支持；主要負責Ha3搜索引擎核心能力的建設維護；提供並維護引擎運維操做平臺和實時引擎搜索服務。
而後是算法團隊，在Ha3搜索引擎上進行定製，優化用戶搜索體驗；對閒魚非結構化的商品經過算法模型進行理解，預測抽取出結構化信息，供搜索引擎商品索引使用；監控維護QP集羣服務；開發並使用Ha3引擎排序插件，進行召回數據分桶實驗，驗證調優。
最後是咱們業務工程團隊，串聯整個搜索流程，監控維護整個搜索鏈路的可用性；主要維護搜索對接的數據，Ha3搜索引擎接入管理，進行SP搜索服務編排，制定合理的查詢計劃；以及閒魚搜索統一在線查詢服務的研發維護工做。
本文亦是從業務工程團隊的工做角度出發，闡述如何對複雜搜索業務系統進行穩定性的保障；

穩定性治理

01部署架構優化

獨立網關部署

Ha3引擎經過SP提供基於HTTP協議的搜索服務API，對相似閒魚這樣複雜的搜索場景，每一個閒魚上層的業務若是都經過拼接SP HTTP接口參數的形式來使用搜索服務，全部上游業務都須要關心SP的拼接語法，會使開發成本劇增，並且若是因爲特殊緣由SP進行了語法調整或者不兼容升級，那麼全部上層業務都須要修正邏輯，這樣的設計不合理；爲了讓業務系統與搜索系統徹底解耦，而且提升搜索服務的易用性，閒魚搜索經過統一的業務搜索網關來提供簡單一致的分佈式服務，供閒魚各上層搜索業務使用，並與SP對接，屏蔽掉SP對上游業務系統的穿透；
最開始閒魚搜索服務與其餘不少不相關的業務場景共建在一個比較龐大的底層應用中；這種部署方式對穩定性要求很高的業務模塊來講有很是大的安全隱患；
1.各業務模塊會相互影響；存在必定程度的代碼耦合，同時還涉及機器資源的競爭，風險比較高；
2.應用太過龐大，嚴重影響開發協做的效率和代碼質量；
因而將閒魚搜索服務部署到獨立的容器分組，新增應用A供閒魚搜索服務專用，做爲各業務使用搜索服務的獨立網關，同時對接下游的SP搜索服務；保證服務是隔離和穩定的。
先後部署圖以下所示；

多機房容災部署

在最初，閒魚商品搜索服務對接的Ha3搜索引擎只部署在一個機房；當此機房出現比較嚴重的問題時，對上游業務影響很是大，甚至會引起故障；鑑於此，對閒魚商品搜索引擎的在線離線集羣進行雙機房部署容災；在詳細展開以前，咱們先大體理解下Ha3引擎DUMP流程的原理；

如上圖所示，Ha3引擎DUMP流程大體流程能夠簡單分爲如下幾步：

• 準備源數據：評估業務需求，將須要接入引擎的數據準備好；通常業務數據大部分都是DB數據表，也有少數的ODPS⑨離線數據表；算法團隊提供的數據絕大部分都是ODPS離線數據表；
• DUMP拉取數據：經過Ha3引擎團隊提供的運維平臺，能夠將這些表的某些數據字段接入到建立好的搜索引擎中，後續DUMP執行的時候，Ha3離線引擎會拉取這些接入的表字段數據，造成一份引擎自用的鏡像數據表，在這一步中，咱們可使用引擎團隊提供的UDF工具，對數據進行清洗/過濾等處理；
• 數據Merge：引擎將全部的鏡像表數據，經過咱們指定的主鍵進行Join；最終造成一份數據大寬表；供引擎建立索引使用；這一步數據Join後，還能夠對最終的數據經過UDF進行進一步的清洗/過濾處理，驗證經過的數據纔會進入到大寬表；
• 建立更新索引：Ha3離線引擎經過buildService，使用大寬表的數據，與事先咱們在Ha3引擎運維平臺指定好的索引Schame對齊，從新構建索引；

以上流程能夠經過Ha3引擎運維平臺手動觸發執行，執行完上述流程後，會生成一份新的索引；新的索引集羣服務可用後，在線實時模塊會將查詢服務切換到新的索引集羣上，完成一次索引的更新；這個完整流程咱們將其稱之爲"全量"；

全量完成後，當系統有新的商品信息變更，且相應的數據表有啓用實時更新(咱們稱之爲增量功能,DB表是經過binlog/ODPS表是經過Swift消息通知的方式實現)，則離線DUMP引擎會感知到這次變更，進而將相應的鏡像數據表中商品數據更新，並會按上述離線DUMP流程中的步驟，將這個改動信息一直向引擎上層投遞，直至成功更新引擎索引中的相應數據，或者中途被系統規則丟棄爲止；這個實時數據更新的流程咱們稱之爲"增量"；增量更新還有一條通道：算法同窗可使用特殊的方式，經過Swift增量消息的方式直接將須要更新的數據不經過DUMP流程，直接更新到Ha3引擎索引中。

閒魚商品量飛速增加，目前已經達到數十億；接入了數百的索引字段，因爲閒魚商品非結構化的緣由，索引字段中只有一小部分供業務使用；另外大部分都是算法接入的索引，好比大量抽出來的標籤數據，向量化數據等，這些向量化數據很是大；最終的情形表現爲閒魚商品搜索引擎的DUMP處理邏輯比較複雜，並且索引數據總量異常龐大，增量消息量也處在很是高的水位，再加上閒魚商品單庫存的現狀；所以對數據更新的實時性要求很是高，這些都給穩定性帶來了極大的制約。

索引數據是搜索引擎的內容核心，若是進入引擎的索引數據有問題，或者新變動的數據沒有更新到引擎索引中，將直接影響搜索服務的質量；
搜索引擎單機房部署期間，時常會由於一些不穩定的因素，致使DUMP全量失敗，或者增量延遲，甚至中止；一旦引擎DUMP出現問題，須要恢復基本都很困難，不少場景下甚至須要從新跑全量才能解決問題；可是閒魚商品索引數據體量較大，作一次全量每每要大半天，沒有辦法快速止血，對業務形成了較大的影響；因而對搜索引擎進行雙機房部署容災(M/N機房)，互爲備份；
兩個離線DUMP機房採用相同的引擎配置和相同的數據源，產出相同的索引數據，分別供兩個在線機房使用，兩個機房的在線流量比例也能夠按需實時調整；當M機房出現不可逆問題時，自動或手動將流量所有切換到N機房，實現線上快速止血，而後再循序漸進排查解決M機房的問題。

下圖爲最終的搜索機房部署狀況；

進行引擎雙機房部署雖然增大了機器資源成本，可是除了上述業務容災優勢外，還有如下好處；

• 引擎需求的發佈，以前缺少有效的灰度流程；當搜索引擎有重大變動/升級，出現高風險的發佈時，能夠先在單機房小流量beta測試，數據對比驗證經過後，再發布到另外一個機房；
• 日常單機房能支撐所有搜索查詢業務的流量，當遇到大促或大型活動時，將兩個機房同時掛載提供服務，這樣搜索服務能力和容量直接能翻倍；避免了單機房頻繁擴縮容的困擾；
• 性能評估時，能夠單獨對未承載流量的機房進行壓測，即便因爲壓測致使宕機也不會對線上業務形成影響；

02流量隔離

上文獨立網關部署一節中講到，閒魚搜索經過統一的業務搜索網關來提供簡單一致的分佈式服務，供閒魚各上層搜索業務使用；使用統一的微服務，就必然帶來上游不一樣業務優先級和可靠性保障的問題。

閒魚搜索服務支撐了種類繁多的上游業務，爲了統一對各業務場景的流量/服務質量進行度量和管理，在上游業務接入閒魚搜索服務時，須要申請使用相應的業務來源，這個業務來源標示會伴隨着整個搜索查詢的生命週期；在日誌採集時直接使用，從而能夠針對業務維度進行監控告警，實時感知業務運行的健康狀況(簡單監控視圖以下圖)，也能夠對具體業務進行流量管控，降級限流等；

搜索業務來源生命週期圖

03分級監控體系

對高穩定性系統，當出現問題，或者即將產生問題時，能即時感知，顯得尤其重要；方便實時進行跟蹤處理，防止繼續擴大；目前使用的主要手段是創建健全完善的多維度監控告警體系；

引擎基礎服務監控

使用監控能夠快速發現問題，若是監控的粒度夠細還能進行問題的快速定位；不過有時也會存在誤報或者漏報的狀況，所以真實的監控必定要結合每一個業務自身系統的特性，梳理出關鍵鏈路，針對關鍵鏈路進行多維度360度無死角監控，而且進行合理的預警規則設置，監控預警纔會比較有效；

閒魚搜索引擎在線離線流程/各上游重要應用系統的核心鏈路上，創建了完備的日誌數據採集模塊，對關鍵指標進行了精準的監控預警設置；作到任何問題都能及時被感知到。下圖是搜索服務相應核心日誌以及監控告警狀況。

模擬用戶行爲的在線業務監控

上文提到，閒魚搜索引擎索引體量比較大，須要不少團隊共同協做，搜索流程複雜度比較高；並且有算法同窗的加入，對閒魚非結構化的商品作了不少AI識別，加上閒魚都是單庫存商品，對引擎實時性要求很是高；前面已經作了一些容災的保障方案；可是對實時性的感知上還須要更進一步，才能及時知道數據的準確狀況，是否存在更新延遲，以及延遲時間大概是多久等一系列健康度信息；

解法是從業務層面進行實時性的監控告警；提取出閒魚商品量比較大更新也比較頻繁的類目K，在閒魚的後臺業務系統中，經過jkeins間隔必定時間（時間步長能夠實時調整），使用類目K做爲關鍵詞和品類，根據商品更新時間索引降序招回，模擬用戶輪詢的方式發送搜索查詢請求，召回知足要求的第一頁商品；而後根據引擎召回數據的商品更新時間與當前系統時間進行差值比對，大於閾值時長（能夠實時調整）說明存在較嚴重的數據更新延遲，則進行告警信息發送；

04壓測

全鏈路壓測

對搜索服務以及各上游業務系統進行全鏈路壓測改造；並使用線上真實的用戶請求構造大批量的壓測數據，在保證不影響線上業務正常進行的前提下，驗證鏈路在超大流量模型下系統的容量和資源分配是否合理，找到鏈路中的性能瓶頸點，驗證網絡設備和集羣容量。

引擎單鏈路壓測

Ha3搜索引擎在線流程，支持經過回放線上高峯時段查詢流量的方式，進行引擎在線服務性能壓測。

Ha3搜索引擎離線流程，支持經過回放一段時間Swift增量消息的方式，進行引擎DUMP增量性能壓測。

05灰度發佈

閒魚商品的非結構化特性，離不開算法賦能；在咱們的研發週期中，與兩個算法團隊，至關多的算法同窗保持着深度合做；給閒魚搜索帶來了跨越式的發展，可是在團隊協做和研發效率上也給咱們帶來了極大的挑戰。

算法團隊、引擎團隊、加上業務工程團隊，很是大的搜索項目開發小組，每週都有很是多的新算法模型，新的引擎改造，新的業務模塊須要上線。

大量的新增邏輯改動直接上線，會帶來不少問題；首先是代碼層面，雖然預發環境有作充分測試，但也難保沒有邊緣邏輯存在測試遺漏的狀況；即便預發測試都徹底覆蓋，但線上和預發終究環境不一樣，線上大流量環境及有可能會暴露一些隱藏的代碼問題；第二方面，假使代碼沒有任何質量問題，但全部功能所有綁定上線，全部邏輯都混雜在一塊兒，如何評定某個模塊上線後的效果成爲極大的困擾，特別是算法模型的優化，和業務上新模式的嘗試，都須要根據詳細的效果反饋數據指標來指導進行下一步的優化方向；

所以急需一套灰度實驗保障體系，不只能夠用來協調和隔離整個搜索業務中各個模塊，作到對各模塊進行單獨的效果評估；而且還能提升你們的協做效率，讓各模塊能進行快速試錯，快速迭代；

爲了解決以上很是重要的問題，業務工程團隊開發了一套實驗管理系統，用來進行搜索實驗灰度調度管理，系統功能如上圖所示；其具備如下特色。

• 實驗靈活方便，一個實驗能夠包含多個實驗組件，一個實驗組件可供多個實驗使用；一個實驗組件又能夠包含多個實驗分桶；
• 各頁面模塊的實驗均可以在系統中實時調控，包括實驗的開/關；以及實驗之間的關係處理；
• 搜索實驗埋點全鏈路打通，統計各類實驗數據報表；
• 統計數據接入了閒魚門戶和通天塔，可查看各個指標不一樣分桶的實驗曲線；
• 提高實驗迭代速度，提高算法/業務效率，快速試錯，加速搜索成交轉化的增加；

06應急預案

根據評估分析或經驗，對搜索服務中潛在的或可能發生的突發事件的關鍵點，事先制定好應急處置方案；當知足必定的條件時進行多維度多層級的自動降級限流，或者配置手動預案進行人工干預；

任什麼時候候發現線上問題，首先須要快速止血，避免問題的擴大；具備自動預案會自動發現問題，自動熔斷，咱們須要密切關注系統的運行狀況，防止反彈；若出現反彈，而且對業務有較大影響時，快速人工介入執行降級預案；完成止血後再詳細排查具體緣由，當短期沒法肯定問題根源時，如在問題出現時有過變動或發佈，則第一時間回滾變動或發佈。

對系統中各級的依賴服務，熔斷降級已經系統負載保護，咱們使用的是阿里巴巴自主研發的資源調用控制組件Sentinel[4]，目前已經開源；或者也可使用Hytrix降級限流工具；

07問題排查

將閒魚搜索鏈路接入阿里搜索問題排查平臺，搜索實時查詢請求的各個步驟輸入的參數信息/產出的數據信息都會在此工具平臺詳細展現，方便各類問題的排查跟進，以及數據信息對比；

能夠對各查詢條件下各個分桶的實驗召回數據進行可視化顯示，方便各個實驗間的效果對比；以及每一個召回商品的各種細節信息查看，包括業務數據和算法標籤數據，還包含每一個商品對應的各引擎插件算分狀況，都能詳細閱覽；

還能夠根據商品Id，賣家Id，賣家Nick進行商品索引信息的披露；能夠排查相應商品在引擎索引中的詳細數據，若是數據和預想的有出入，具體是離線DUMP哪一步的處理邏輯致使的狀態異常，都能一鍵查詢。

接入此問題排查平臺後，能很是直觀的掌握引擎的運行情況，搜索召回的鏈路狀態；對快速發現問題根源，即時修復問題都有很是重大的做用！

總結與展望

本文主要介紹閒魚如何保障複雜場景下搜索引擎服務的穩定性，主要從架構部署，隔離性，容量評估，風險感知&管控等方面進行闡述，介紹瞭如何穩定支撐20+線上搜索業務場景，作到了快速發現恢復線上問題，高效提早預知規避風險案例50+，極大程度提高了搜索服務的用戶體驗，保障了閒魚搜索整年無端障；

通過上述治理方案後，閒魚搜索系統穩定性獲得了極大的保障，同時咱們也會繼續深耕，在搜索能力的高可用、更易用上更進一步，讓上游業務更加順滑；
但願給各位讀者帶來一些思考和啓發。

原文連接