UniSearch我如何用一套統(tǒng)一檢索層把三個(gè)“各自為政”的搜索系統(tǒng)揉成一個(gè)接到這個(gè)“UniSearch”項(xiàng)目的時(shí)候我一開始是想拒絕的并不是因?yàn)榧夹g(shù)有多難而是我知道這類“統(tǒng)一搜索”的需求十有八九不是在做一個(gè)新搜索引擎而是在給一堆歷史包袱擦屁股。果不其然業(yè)務(wù)方那邊的情況非常典型訂單數(shù)據(jù)在MySQL里文檔和日志在Elasticsearch里商品和庫存部分?jǐn)?shù)據(jù)散落在幾個(gè)內(nèi)部API里用戶只想在一個(gè)輸入框里搜出所有東西并且希望結(jié)果按相關(guān)度混排。UniSearch這個(gè)名字聽起來很唬人落地就是一個(gè)把各種數(shù)據(jù)源串起來的“總調(diào)度層”只是這個(gè)調(diào)度層要處理的坑遠(yuǎn)比想象中多。如果你也在做類似的事或者正準(zhǔn)備碰企業(yè)內(nèi)部搜索聚合這類需求這篇東西可以幫你少走很多彎路。我講的是自己實(shí)際落地的一套實(shí)現(xiàn)覆蓋從整體架構(gòu)選型、索引策略、查詢分發(fā)、結(jié)果融合排序到上線后各種疑難雜癥的排查實(shí)錄。所有方案都基于我踩坑后的最終版不是說它唯一正確但至少是能扛得住線上流量和業(yè)務(wù)方花式蹂躪的一種設(shè)計(jì)。1. 統(tǒng)一搜索到底在解決什么問題先說一個(gè)最容易混淆的認(rèn)知UniSearch不是搜索引擎它是一層“調(diào)度和融合中間件”。搜索引擎關(guān)心的是怎么從海量文檔里快速撈相關(guān)文檔而UniSearch關(guān)心的是怎么把已經(jīng)存在于不同系統(tǒng)里的檢索能力以統(tǒng)一的接口暴露出去。你可以把它理解成公司前臺(tái)的接待員——你不會(huì)直接去找財(cái)務(wù)、去找法務(wù)、去找技術(shù)部而是把訴求告訴前臺(tái)由前臺(tái)判斷該找誰然后把多個(gè)部門的答復(fù)整理成一份簡報(bào)交給你。1.1 三種典型接入場(chǎng)景拆解第一類場(chǎng)景是結(jié)構(gòu)化數(shù)據(jù)源的直查。比如MySQL或PostgreSQL里的訂單表、用戶表檢索條件通常很固定按訂單號(hào)、按用戶名、按時(shí)間范圍、按狀態(tài)。這部分完全不值得自建倒排索引直接通過關(guān)鍵詞解析生成SQL條件即可難點(diǎn)只在于如何把用戶輸入的模糊關(guān)鍵詞安全且高效地轉(zhuǎn)換成查詢條件。第二類場(chǎng)景是全文檢索引擎的代理。Elasticsearch這類系統(tǒng)本身已經(jīng)做得很好UniSearch在這里的角色不是替代它而是把ES的DSL翻譯成內(nèi)部統(tǒng)一的查詢模型避免上游系統(tǒng)直接與ES耦合。這樣做的直接好處是哪天你想從ES換成OpenSearch或者把一部分索引遷到ZincSearch上游業(yè)務(wù)代碼一行都不用改。第三類場(chǎng)景是實(shí)時(shí)API的在線聚合。商品庫存狀態(tài)、配送進(jìn)度這類數(shù)據(jù)時(shí)效性極高而且經(jīng)常不在你自己掌控的數(shù)據(jù)庫里只能通過供應(yīng)商或兄弟團(tuán)隊(duì)提供的HTTP接口實(shí)時(shí)獲取。UniSearch需要在這種場(chǎng)景下做并發(fā)請(qǐng)求、超時(shí)控制和結(jié)果合并。1.2 為什么必須做統(tǒng)一查詢模型我見過很多團(tuán)隊(duì)做統(tǒng)一搜索最后做成了一個(gè)“大雜燴”網(wǎng)關(guān)每個(gè)數(shù)據(jù)源各寫一套查詢邏輯對(duì)外暴露的參數(shù)五花八門調(diào)用方得看文檔才能搞清楚什么時(shí)候傳filters什么時(shí)候傳q什么時(shí)候要拼search_type。這種方案上線半年后基本就進(jìn)入維護(hù)地獄。真正的UniSearch項(xiàng)目第一步不是寫代碼而是定義一套“萬能查詢中間格式”。這套格式一般包含query關(guān)鍵詞、filters結(jié)構(gòu)化過濾條件、sort排序規(guī)則、from/size分頁、highlight高亮需求、aggs聚合需求這幾個(gè)核心部分。所有數(shù)據(jù)源適配器只認(rèn)這一套格式對(duì)外也只暴露這一個(gè)格式。Elasticsearch適配器負(fù)責(zé)把它翻譯成DSLMySQL適配器負(fù)責(zé)把它拆解成WHERE條件API適配器負(fù)責(zé)把它映射成對(duì)方接口的請(qǐng)求參數(shù)。這才是“統(tǒng)一”二字的精髓。2. 架構(gòu)分層與核心技術(shù)選型確定要做統(tǒng)一查詢模型之后接下來的任務(wù)就是搭架子。UniSearch整體分為三層接入層、編排層、適配層。這三層各管各的事互不越界。2.1 接入層標(biāo)準(zhǔn)REST接口與參數(shù)設(shè)計(jì)接入層是一層薄薄的HTTP API核心就是參數(shù)校檢和統(tǒng)一鑒權(quán)。我建議接口體設(shè)計(jì)成這樣{ query: 華為手機(jī), filters: { status: ON_SALE, category_id: [12, 13, 14] }, sort: _score, from: 0, size: 20, highlight: true, data_sources: [mysql_products, es_docs, api_stock] }這個(gè)設(shè)計(jì)里有一個(gè)容易被人忽略的點(diǎn)data_sources字段。默認(rèn)情況下UniSearch會(huì)查所有已注冊(cè)的數(shù)據(jù)源但很多調(diào)用方其實(shí)只關(guān)心其中某幾個(gè)。顯式聲明之后編排層能省掉一大半無意義的查詢分發(fā)。鑒權(quán)方面我只推薦兩種內(nèi)部系統(tǒng)用簽名校驗(yàn)外部系統(tǒng)走OAuth2的client credentials模式。不要用簡單的API Key打在URL上線上日志一刷全是泄露的憑證。2.2 編排層查詢分發(fā)與并行調(diào)度編排層是整個(gè)UniSearch的心臟負(fù)責(zé)決定“這個(gè)查詢要怎么拆”。一個(gè)查詢進(jìn)來后先做意圖識(shí)別——業(yè)務(wù)簡單時(shí)可以用基于規(guī)則的方式來識(shí)別比如命中某些正則就路由到對(duì)應(yīng)數(shù)據(jù)源復(fù)雜度上來之后可以訓(xùn)練一個(gè)輕量級(jí)分類器來做這件事。我這次沒有上分類模型因?yàn)闃I(yè)務(wù)場(chǎng)景足夠收斂凡是帶status過濾的基本都查訂單和商品凡是帶highlight的在ES查詢里一定用得上。分發(fā)策略上我最想強(qiáng)調(diào)一點(diǎn)并行永遠(yuǎn)比串行好但要有下限保護(hù)。所有數(shù)據(jù)源同時(shí)發(fā)起請(qǐng)求等待最慢的那個(gè)返回后統(tǒng)一合并。這樣響應(yīng)時(shí)間等于最慢數(shù)據(jù)源的耗時(shí)而不是所有數(shù)據(jù)源耗時(shí)之和。但要給每個(gè)數(shù)據(jù)源的請(qǐng)求設(shè)置超時(shí)上限比如統(tǒng)一1000毫秒超時(shí)的數(shù)據(jù)源直接降級(jí)——返回空結(jié)果并記錄一條warning日志而不是讓整個(gè)UniSearch都跟著卡死。2.3 適配層五種數(shù)據(jù)源連接器的實(shí)現(xiàn)要點(diǎn)我這次接的適配器包括MySQL、Elasticsearch、HTTP API、Redis緩存和CSV靜態(tài)文件每種都有各自的實(shí)現(xiàn)要點(diǎn)MySQL連接器要處理的是動(dòng)態(tài)SQL拼接。關(guān)鍵詞中的特殊字符必須用參數(shù)綁定而不是字符串拼接防止注入。排序字段要做白名單校驗(yàn)絕不允許把前端傳來的字符串直接拼進(jìn)ORDER BY。Elasticsearch連接器要做的是查詢語法翻譯。用戶輸入的name:華為 AND price:[1000 TO 3000]這種Lucene語法需要由適配器解析后在內(nèi)部轉(zhuǎn)換成結(jié)構(gòu)化Query對(duì)象而不是直接把字符串透?jìng)鹘oES的query_string查詢否則用戶一旦傳錯(cuò)語法ES直接返回400。HTTP API連接器最麻煩的是參數(shù)映射和重試。不同系統(tǒng)對(duì)參數(shù)命名習(xí)慣完全不同有的叫keyword有的叫search_text有的叫q。適配器里維護(hù)一份字段映射表通過配置而不是硬編碼來管理。Redis連接器在這里不是做緩存而是做熱搜榜和聯(lián)想詞數(shù)據(jù)源。如果業(yè)務(wù)里需要“搜索框下面顯示熱門搜索詞”這種功能直接從Redis的ZSET里取top N即可。CSV連接器適合處理那種低頻更新的基礎(chǔ)數(shù)據(jù)比如產(chǎn)品規(guī)格表、地區(qū)代碼表。每當(dāng)文件更新后把數(shù)據(jù)加載進(jìn)內(nèi)存建立簡單的倒排索引查詢時(shí)直接在內(nèi)存里跑。2.4 數(shù)據(jù)一致性方案雙寫與事件同步做統(tǒng)一搜索時(shí)一個(gè)無法回避的問題如果一個(gè)數(shù)據(jù)源里的數(shù)據(jù)變了UniSearch怎么感知我采用的方案是“業(yè)務(wù)主庫負(fù)責(zé)寫UniSearch負(fù)責(zé)讀”的事件驅(qū)動(dòng)模式。具體做法是業(yè)務(wù)系統(tǒng)在數(shù)據(jù)變更時(shí)發(fā)送MQ消息UniSearch消費(fèi)消息后更新對(duì)應(yīng)的ES索引或清理Redis緩存。這里有一個(gè)大坑如果只依賴MQ很容易出現(xiàn)消息丟失導(dǎo)致數(shù)據(jù)不一致。所以我還保留了一個(gè)每天凌晨的全量對(duì)賬任務(wù)比對(duì)MySQL和ES里的記錄數(shù)及關(guān)鍵字段的校驗(yàn)值發(fā)現(xiàn)不一致的自動(dòng)重新同步。提示沒有對(duì)賬機(jī)制的統(tǒng)一搜索本質(zhì)上就是一個(gè)定時(shí)會(huì)“出現(xiàn)臟數(shù)據(jù)”的搜索。生產(chǎn)環(huán)境上線之前一定要把全量對(duì)賬定時(shí)任務(wù)安排上。3. 核心流程的工程化實(shí)現(xiàn)理念講得再多最后還是要落到代碼。我按一個(gè)真實(shí)的查詢請(qǐng)求從進(jìn)來到返回的完整鏈路把每個(gè)關(guān)鍵環(huán)節(jié)的工程實(shí)現(xiàn)都拆開講一遍。3.1 查詢預(yù)處理同義詞、糾錯(cuò)、分詞策略原始查詢?cè)~不能直接拿去查數(shù)據(jù)源。首先要做的是查詢預(yù)處理。其中同義詞擴(kuò)展能讓“筆記本”同時(shí)命中“筆記本電腦”和“l(fā)aptop”。實(shí)現(xiàn)上可以通過配置一個(gè)同義詞詞典在查詢時(shí)做檢索詞擴(kuò)展。其次是糾錯(cuò)這里我用的是編輯距離算法配合業(yè)務(wù)詞表庫當(dāng)用戶輸入“華偽手機(jī)”時(shí)能識(shí)別出“華為手機(jī)”才是正確的查詢?cè)~。需要注意的是糾錯(cuò)一定要區(qū)分“建議糾正”和“自動(dòng)糾正”前者是在搜索結(jié)果下方提示“您是不是要找華為手機(jī)”后者是直接拿修正后的詞去查詢。我個(gè)人的經(jīng)驗(yàn)是默認(rèn)用建議式糾正只有用戶明確點(diǎn)擊后再執(zhí)行新查詢自動(dòng)糾正太容易翻車。分詞策略上有一個(gè)重要原則索引期分詞和查詢期分詞必須保持一致否則會(huì)出現(xiàn)明明數(shù)據(jù)在那、卻搜不出來的情況。比如MySQL數(shù)據(jù)源針對(duì)中文商品名做檢索如果索引時(shí)期用的是普通的ngram分詞查詢時(shí)期的預(yù)處理分詞也必須支持同種切法。如果一致性無法保證寧可用簡單的contains匹配也不要上一個(gè)花哨的、不可控的分詞算法。3.2 多路結(jié)果的歸一化與字段對(duì)齊并行查詢返回的四五份結(jié)果形態(tài)各異需要把他們轉(zhuǎn)成統(tǒng)一的結(jié)果對(duì)象。這個(gè)過程我稱之為歸一元組。具體的歸一化規(guī)則如下表數(shù)據(jù)源類型原始返回結(jié)構(gòu)歸一化后的關(guān)鍵字段MySQL行記錄每行是一個(gè)dictid,title,summary,url,score,sourceElasticsearch命中_source及highlightid,title,summary,url,score,sourceHTTP API返回值自定義JSON結(jié)構(gòu)id,title,summary,url,score,sourceRedis熱詞ZSET member和scoreid為空title為熱詞score為熱度CSV內(nèi)存索引內(nèi)存對(duì)象id,title,summary,url,score,source這里有一個(gè)細(xì)節(jié)值得注意score的歸一化。MySQL和API適配器本來是不產(chǎn)生相關(guān)性分?jǐn)?shù)的我通常會(huì)在適配器里根據(jù)命中字段的重要程度去手動(dòng)計(jì)算一個(gè)基礎(chǔ)分值。比如命中標(biāo)題給3分命中摘要給1分命中標(biāo)簽給2分這個(gè)邏輯放在適配層做。3.3 融合排序策略加權(quán)、歸一化與去重所有數(shù)據(jù)源的結(jié)果匯集到一起之后面臨的難題是這些分?jǐn)?shù)并不可直接比較。ES返回0.8的分?jǐn)?shù)和MySQL里我手算的3分量綱完全不同。直接按原始分?jǐn)?shù)排序沒有任何意義。所以我采用了先歸一化、再加權(quán)、再融合的三步策略。歸一化可以用min-max歸一化或者使用Wilson下限來平滑處理避免單條極端分?jǐn)?shù)帶偏整體。加權(quán)則需要按照業(yè)務(wù)定義數(shù)據(jù)源權(quán)重。比如訂單這個(gè)數(shù)據(jù)源權(quán)重是1.0商品是0.9文檔是0.6熱詞聯(lián)想是0.3最終綜合得分的公式大致是final_score normalized_score(source) * source_weight去重策略上面我處理的是跨數(shù)據(jù)源重復(fù)的情況。比如商品和文檔同時(shí)引用了同一篇文章的地址或訂單和商品數(shù)據(jù)源里回到同一個(gè)商品ID。去重邏輯是基于ID加URL的聯(lián)合唯一鍵來判斷。保留哪條優(yōu)先級(jí)順序是API結(jié)果 MySQL ES CSV高優(yōu)先級(jí)的保留其余的被排除。3.4 分頁與深翻頁問題的工程解法統(tǒng)一搜索還有個(gè)細(xì)節(jié)讓很多人頭疼分頁。Elasticsearch超過1萬條深翻頁時(shí)會(huì)報(bào)錯(cuò)MySQL深度分頁也慢得離譜而API接口壓根不支持from加size特別大的查詢。所以UniSearch的默認(rèn)分頁上限是100頁每頁最多50條。超過這個(gè)范圍的查詢有兩種降級(jí)方案可選一種是返回提示讓用戶收窄條件另一種是利用ES的search_after做深翻頁游標(biāo)同時(shí)MySQL側(cè)改用“最后一個(gè)可見ID”來做keyset分頁。我的建議是優(yōu)先用方式一畢竟正經(jīng)用戶不會(huì)翻到100頁以后。3.5 結(jié)果緩存與性能兜底在緩存層上我用了兩級(jí)緩存策略。L1是進(jìn)程內(nèi)緩存使用TTL為30秒適合命中熱點(diǎn)查詢L2是Redis緩存TTL為5分鐘。查詢請(qǐng)求進(jìn)來先查L1沒命中再查L2最后才真正分發(fā)到底層數(shù)據(jù)源。但緩存粒度不應(yīng)該是整個(gè)查詢結(jié)果而應(yīng)該是數(shù)據(jù)源級(jí)別的結(jié)果片段。因?yàn)楫?dāng)四個(gè)數(shù)據(jù)源里只有一個(gè)數(shù)據(jù)變了如果緩存的是合并后的完整結(jié)果其他三個(gè)數(shù)據(jù)源的數(shù)據(jù)會(huì)被無謂地過期。單獨(dú)緩存各數(shù)據(jù)源返回的原始片段再在編排層做融合可以最大程度提高緩存命中率。4. 上線調(diào)試與問題排查實(shí)錄UniSearch這種糅合了多個(gè)系統(tǒng)的中間層一旦出問題表象往往是一坨亂麻。這一章把我線上遇到過的典型問題和排查思路整理出來你可以當(dāng)做一個(gè)速查表來用。4.1 請(qǐng)求超時(shí)罪魁禍?zhǔn)淄恰按小钡谝淮紊暇€壓測(cè)時(shí)P99延遲高達(dá)4.8秒這顯然不可接受。排查發(fā)現(xiàn)問題不在某個(gè)數(shù)據(jù)源性能差而在于我的初版編排邏輯是按順序調(diào)用各個(gè)適配器。每個(gè)適配器平均耗時(shí)200毫秒串行調(diào)五個(gè)就是1秒加上網(wǎng)絡(luò)開銷和數(shù)據(jù)庫慢查詢延遲自然爆炸。改造方案是把串行調(diào)用改成Java虛擬線程或Python asyncio并發(fā)調(diào)度整體吞吐從每秒300漲到2000。如果你用的是Java項(xiàng)目CompletableFuture或者虛擬線程都行如果是Gogoroutine加channel天然支持Python的話我會(huì)夸一句asyncio。但我不推薦用裸線程池因?yàn)榫€程池耗盡太容易造成雪崩。經(jīng)驗(yàn)編排層強(qiáng)制要求所有數(shù)據(jù)源調(diào)用必須并行發(fā)起并且設(shè)置統(tǒng)一的超時(shí)上限這個(gè)是UniSearch性能的第一命門。4.2 數(shù)據(jù)源返回慢不能拖死整體壓測(cè)中還發(fā)現(xiàn)如果其中一個(gè)API數(shù)據(jù)源響應(yīng)卡頓幾秒所有請(qǐng)求都會(huì)被阻塞。后來我把超時(shí)控制做成“逐源設(shè)置”的配置項(xiàng)默認(rèn)統(tǒng)一1000毫秒但對(duì)關(guān)鍵核心數(shù)據(jù)源可以放寬到1500毫秒對(duì)非關(guān)鍵數(shù)據(jù)源比如熱詞、聯(lián)想只給300毫秒。超時(shí)的數(shù)據(jù)源不再等待直接降級(jí)為空結(jié)果在返回體里帶上timeout_sources字段告訴前端這次查詢哪些源超時(shí)了。這樣即使某一個(gè)下游系統(tǒng)故障主鏈路依然是穩(wěn)定的。4.3 數(shù)據(jù)源返回慢不能拖死整體調(diào)參時(shí)發(fā)現(xiàn)ES查詢耗時(shí)最大的瓶頸來自兩次查詢一次普通請(qǐng)求一次獲取total命中數(shù)。ES默認(rèn)會(huì)在每次查詢時(shí)計(jì)算精確總數(shù)當(dāng)索引體量很大的時(shí)候這種計(jì)算代價(jià)很高。我把ES的track_total_hits設(shè)置為false返回總數(shù)改為近似值查詢性能提升35%。對(duì)搜索結(jié)果而言100頁以內(nèi)的總數(shù)用近似值完全能滿足需求沒必要讓精確計(jì)數(shù)拖慢整體響應(yīng)。4.4 Redis緩存穿透與更新風(fēng)暴上線初期緩存穿透非常嚴(yán)重。熱詞數(shù)據(jù)源本身數(shù)據(jù)量不大但是用戶搜索時(shí)經(jīng)常輸入一個(gè)冷門詞結(jié)果Redis沒緩存直接穿透到后端而MySQL又拿不到結(jié)果就變成“緩存擊穿空結(jié)果”的雙重浪費(fèi)。我的解法除了常規(guī)的空值緩存之外還加了一層布隆過濾器在業(yè)務(wù)側(cè)維護(hù)一個(gè)基于所有已知有效查詢?cè)~的布隆過濾器。攔截掉明顯不存在的查詢MySQL的壓力直接下降了一個(gè)數(shù)量級(jí)。4.5 結(jié)果排序不穩(wěn)定導(dǎo)致投訴有一次業(yè)務(wù)方反饋同一個(gè)關(guān)鍵詞搜索的結(jié)果過幾分鐘再搜就發(fā)現(xiàn)順序變了。查下來是融合排序時(shí)分段歸一化算法的問題對(duì)于數(shù)量很少的分片結(jié)果min-max歸一化會(huì)放大微小差異同一句話在不同時(shí)間點(diǎn)檢索甚至只因ES分片間的tie_breaker不同就讓分?jǐn)?shù)發(fā)生細(xì)微抖動(dòng)。最后我把歸一化的下限做了鉗制設(shè)置MIN_SCORE0.1保證所有結(jié)果的基礎(chǔ)分不低于0.1就不會(huì)出現(xiàn)因?yàn)槲⑿〔▌?dòng)導(dǎo)致的排序漂移。4.6 日志與追蹤統(tǒng)一檢索必須帶TraceId這是我覺得整塊項(xiàng)目里最值得做的事情之一。UniSearch一次查詢會(huì)觸達(dá)多個(gè)數(shù)據(jù)源一旦線上有問題沒有日志鏈路就是在黑暗里摸大象。我強(qiáng)制要求日志系統(tǒng)里集成TraceId從接入層生成貫穿編排層、適配層直到底層數(shù)據(jù)源。每個(gè)數(shù)據(jù)源的耗時(shí)、返回條數(shù)、異常堆棧都掛在這個(gè)TraceId下。后續(xù)排查的時(shí)候只需要用TraceId搜索一次完整的調(diào)用鏈就能定位問題。這個(gè)習(xí)慣我從一開始就建了中間有一次線上故障能十分鐘之內(nèi)定位全靠它。5. 工具、參數(shù)與調(diào)優(yōu)細(xì)節(jié)總結(jié)最后把我在整個(gè)把UniSearch項(xiàng)目中實(shí)際使用過的工具和一些重要的調(diào)優(yōu)參數(shù)整理一下。不是每一家公司的技術(shù)棧一樣所以工具選型僅作參考。5.1 基礎(chǔ)設(shè)施選型參考組件選用方案理由接入層APIFastAPI / Spring Boot高并發(fā)性能好社區(qū)資源豐富異步編排Python asyncio / Java CompletableFuture天然支持并發(fā)調(diào)用全文檢索引擎Elasticsearch 8.x成熟穩(wěn)定生態(tài)完善業(yè)務(wù)數(shù)據(jù)庫MySQL 8.0業(yè)務(wù)主存儲(chǔ)穩(wěn)定可靠緩存Redis 7.x支持ZSET熱榜及多級(jí)緩存MQ消息RabbitMQ支撐雙寫事件同步監(jiān)控Prometheus Grafana覆蓋接口QPS、P99時(shí)延、各適配器狀態(tài)5.2 一鍵查詢鏈路耗時(shí)監(jiān)控每個(gè)適配器的查詢耗時(shí)必須拆開觀察。我在Grafana里建了十幾個(gè)看板但日常最常用的是三個(gè)總接口請(qǐng)求量及響應(yīng)時(shí)間曲線、各數(shù)據(jù)源平均耗時(shí)對(duì)比柱狀圖、各數(shù)據(jù)源超時(shí)次數(shù)統(tǒng)計(jì)表。每次發(fā)布新版本之后第一件事不是看功能對(duì)不對(duì)而是看適配器耗時(shí)有沒有異常波動(dòng)。如果某個(gè)源的平均耗時(shí)從200毫秒突增到800毫秒不管業(yè)務(wù)方怎么說“沒問題”都要主動(dòng)去查一下對(duì)方系統(tǒng)的負(fù)載。5.3 上線前必做的三件準(zhǔn)備工作第一件梳理清楚哪些數(shù)據(jù)源是強(qiáng)依賴、哪些是弱依賴。強(qiáng)依賴掛了整個(gè)搜索不可用弱依賴掛了可以容忍。這個(gè)梳理結(jié)果決定了超時(shí)和降級(jí)方案怎么設(shè)計(jì)。第二件建立一套全鏈路的自動(dòng)化回歸用例。針對(duì)每個(gè)數(shù)據(jù)源準(zhǔn)備標(biāo)準(zhǔn)查詢集預(yù)期結(jié)果集鎖定在固定基線里。每次代碼改動(dòng)先跑這組用例避免只修了A數(shù)據(jù)源卻把B數(shù)據(jù)源的適配邏輯弄壞了。第三件準(zhǔn)備好對(duì)賬腳本。我建議做兩級(jí)對(duì)賬數(shù)據(jù)記錄數(shù)對(duì)賬和字段級(jí)對(duì)賬。先比數(shù)量再比關(guān)鍵字段的哈希一致性這是防數(shù)據(jù)漂移的兜底。提示不要在下班前一小時(shí)首次灰度發(fā)布統(tǒng)一搜索項(xiàng)目。第一晚大概率會(huì)有各種數(shù)據(jù)源連接和權(quán)限的幺蛾子留足排查時(shí)間比什么都重要。6. 下一階段演進(jìn)方向UniSearch做到這里已經(jīng)能穩(wěn)定支撐日常查詢了。但如果業(yè)務(wù)量再往上走有幾個(gè)演進(jìn)點(diǎn)是我明確計(jì)劃要做的。第一個(gè)是引入真正的個(gè)人化排序基于用戶的歷史點(diǎn)擊、收藏行為訓(xùn)練一個(gè)輕量級(jí)的learning to rank模型把融合排序從手工加權(quán)升級(jí)為模型打分。第二個(gè)是增加搜索熱力統(tǒng)計(jì)從Redis熱詞出發(fā)把用戶每天的搜索詞、點(diǎn)擊結(jié)果、跳失率匯入數(shù)據(jù)倉庫形成業(yè)務(wù)洞察報(bào)表。第三個(gè)是更強(qiáng)的同義詞動(dòng)態(tài)挖掘現(xiàn)在用的靜態(tài)詞表維護(hù)成本高后續(xù)計(jì)劃基于用戶搜索日志里的共現(xiàn)詞挖掘同義詞實(shí)現(xiàn)詞表的自我更新。我個(gè)人在這整件事中最大的體會(huì)是做統(tǒng)一搜索難點(diǎn)從來不在搜索本身而在“統(tǒng)一”二字。統(tǒng)一意味著你要面對(duì)各種歷史系統(tǒng)的怪癖面對(duì)無法控制的字段命名面對(duì)每一個(gè)數(shù)據(jù)源獨(dú)有的查詢語法和限制。與其想著一套代碼適配全部不如把適配層的邊界劃清楚把統(tǒng)一查詢模型設(shè)計(jì)得足夠通用。只要這兩件事做踏實(shí)UniSearch這個(gè)名字才真正配得上。最后再分享一個(gè)小技巧上線那天先在測(cè)試環(huán)境用真實(shí)用戶搜索日志回放壓測(cè)一遍不要用模擬流量因?yàn)橹挥姓鎸?shí)搜索日志才會(huì)暴露出那些你完全想不到的奇葩查詢?cè)~和冷門字段組合這一條比任何架構(gòu)設(shè)計(jì)都更能幫你省去后續(xù)的救火時(shí)間。