本文從架構(gòu)上介紹了有贊搜索系統(tǒng)演進(jìn)產(chǎn)生的背景以及希望解決的問題。

有贊搜索平臺是一個面向公司內(nèi)部各項(xiàng)搜索應(yīng)用以及部分 NoSQL 存儲應(yīng)用的 PaaS 產(chǎn)品，幫助應(yīng)用合理高效的檢索和多維過濾功能。有贊搜索平臺目前支持了大大小小一百多個檢索業(yè)務(wù)，服務(wù)于近百億數(shù)據(jù)。

在為傳統(tǒng)的搜索應(yīng)用提供高級檢索和大數(shù)據(jù)交互能力的同時，有贊搜索平臺還需要為其他比如商品管理、訂單檢索、粉絲篩選等海量數(shù)據(jù)過濾提供支持。

從工程的角度看，如何擴(kuò)展平臺以支持多樣的檢索需求是一個巨大的挑戰(zhàn)。

我們搜索團(tuán)隊(duì)目前主要負(fù)責(zé)平臺的性能、可擴(kuò)展性和可靠性方面的問題，并盡可能降低平臺的運(yùn)維成本以及業(yè)務(wù)的開發(fā)成本。

Elasticsearch 是一個高可用分布式搜索引擎，一方面技術(shù)相對成熟穩(wěn)定，另一方面社區(qū)也比較活躍，因此我們在搭建搜索系統(tǒng)過程中也是選擇了 Elasticsearch 作為我們的基礎(chǔ)引擎。

架構(gòu) 1.0

時間回到 2015 年，彼時運(yùn)行在生產(chǎn)環(huán)境的有贊搜索系統(tǒng)是一個由幾臺高配虛擬機(jī)組成的 Elasticsearch 集群，主要運(yùn)行商品和粉絲索引，數(shù)據(jù)通過 Canal 從 DB 同步到 Elasticsearch，大致架構(gòu)如下圖：

 

通過這種方式，在業(yè)務(wù)量較小時，可以低成本的快速為不同業(yè)務(wù)索引創(chuàng)建同步應(yīng)用，適合業(yè)務(wù)快速發(fā)展時期。

但相對的每個同步程序都是單體應(yīng)用，不僅與業(yè)務(wù)庫地址耦合，需要適應(yīng)業(yè)務(wù)庫快速的變化，如遷庫、分庫分表等，而且多個 Canal 同時訂閱同一個庫，也會造成數(shù)據(jù)庫性能的下降。

另外 Elasticsearch 集群也沒有做物理隔離，有一次促銷活動就因?yàn)榉劢z數(shù)據(jù)量過于龐大導(dǎo)致 Elasticsearch 進(jìn)程 Heap 內(nèi)存耗盡而 OOM，使得集群內(nèi)全部索引都無法正常工作，這給我上了深深的一課。

架構(gòu) 2.0

我們在解決以上問題的過程中，也自然的沉淀出了有贊搜索的 2.0 版架構(gòu)，大致架構(gòu)如下圖：

 

首先數(shù)據(jù)總線將數(shù)據(jù)變更消息同步到 MQ，同步應(yīng)用通過消費(fèi) MQ 消息來同步業(yè)務(wù)庫數(shù)據(jù)，借數(shù)據(jù)總線實(shí)現(xiàn)與業(yè)務(wù)庫的解耦，引入數(shù)據(jù)總線也可以避免多個 Canal 監(jiān)聽消費(fèi)同一張表 Binlog 的虛耗。

高級搜索(Advanced Search)

隨著業(yè)務(wù)發(fā)展，我們也逐漸出現(xiàn)了一些比較中心化的流量入口，比如分銷、精選等。

這時普通的 Bool 查詢并不能滿足我們對搜索結(jié)果的細(xì)粒率排序控制需求，將復(fù)雜的 function_score 之類專業(yè)性較強(qiáng)的高級查詢編寫和優(yōu)化工作交給業(yè)務(wù)開發(fā)負(fù)責(zé)顯然是個不可取的選項(xiàng)。

這里我們考慮的是通過一個高級查詢中間件攔截業(yè)務(wù)查詢請求，在解析出必要的條件后重新組裝為高級查詢交給引擎執(zhí)行，大致架構(gòu)如下：

 

這里另外做的一點(diǎn)優(yōu)化是加入了搜索結(jié)果緩存，常規(guī)的文本檢索查詢 Match 每次執(zhí)行都需要實(shí)時計(jì)算。

在實(shí)際的應(yīng)用場景中這并不是必須的，用戶在一定時間段內(nèi)(比如 15 或 30 分鐘)通過同樣的請求訪問到同樣的搜索結(jié)果是完全可以接受的。

在中間件做一次結(jié)果緩存可以避免重復(fù)查詢反復(fù)執(zhí)行的虛耗，同時提升中間件響應(yīng)速度。

大數(shù)據(jù)集成

搜索應(yīng)用和大數(shù)據(jù)密不可分，除了通過日志分析來挖掘用戶行為的更多價值之外，離線計(jì)算排序綜合得分也是優(yōu)化搜索應(yīng)用體驗(yàn)不可缺少的一環(huán)。

在 2.0 階段我們通過開源的 ES-Hadoop 組件搭建 Hive 與 Elasticsearch 之間的交互通道，大致架構(gòu)如下：

 

通過 Flume 收集搜索日志存儲到 HDFS 供后續(xù)分析，也可以在通過 Hive 分析后導(dǎo)出作為搜索提示詞，當(dāng)然大數(shù)據(jù)為搜索業(yè)務(wù)提供的遠(yuǎn)不止于此，這里只是簡單列舉了幾項(xiàng)功能。

遇到的問題

這樣的架構(gòu)支撐了搜索系統(tǒng)一年多的運(yùn)行，但是也暴露出了許多問題，首當(dāng)其沖的是越發(fā)高昂的維護(hù)成本。

除去 Elasticsearch 集群維護(hù)和索引本身的配置、字段變更，雖然已經(jīng)通過數(shù)據(jù)總線與業(yè)務(wù)庫解耦，但是耦合在同步程序中的業(yè)務(wù)代碼依舊為團(tuán)隊(duì)帶來了極大的維護(hù)負(fù)擔(dān)。

消息隊(duì)列雖然一定程序上減輕了我們與業(yè)務(wù)的耦合，但是帶來的消息順序問題也讓不熟悉業(yè)務(wù)數(shù)據(jù)狀態(tài)的我們很難處理。

除此之外，流經(jīng) Elasticsearch 集群的業(yè)務(wù)流量對我們來說呈半黑盒狀態(tài)，可以感知，但不可預(yù)測，也因此出現(xiàn)過線上集群被內(nèi)部大流量錯誤調(diào)用壓到 CPU 占滿不可服務(wù)的故障。

目前的架構(gòu) 3.0

 

針對 2.0 時代的問題，我們在 3.0 架構(gòu)中做了一些針對性調(diào)整，列舉主要的幾點(diǎn)：

• 通過開放接口接收用戶調(diào)用，與業(yè)務(wù)代碼完全解耦。
• 增加 Proxy 用來對外服務(wù)，預(yù)處理用戶請求并執(zhí)行必要的流控、緩存等操作。
• 提供管理平臺簡化索引變更和集群管理，這樣的演變讓有贊搜索系統(tǒng)逐漸的平臺化，已經(jīng)初具了一個搜索平臺的架構(gòu)。

Proxy

作為對外服務(wù)的出入口，Proxy 除了通過 ESLoader 提供兼容不同版本 Elasticsearch 調(diào)用的標(biāo)準(zhǔn)化接口之外，也內(nèi)嵌了請求校驗(yàn)、緩存、模板查詢等功能模塊。

請求校驗(yàn)主要是對用戶的寫入、查詢請求進(jìn)行預(yù)處理，如果發(fā)現(xiàn)字段不符、類型錯誤、查詢語法錯誤、疑似慢查詢等操作后，以 Fast Fail 的方式拒絕請求或者以較低的流控水平執(zhí)行，避免無效或低效能操作對整個 Elasticsearch 集群的影響。

緩存和 ESLoader 主要是將原先高級搜索中的通用功能集成進(jìn)來，使得高級搜索可以專注于搜索自身的查詢分析和重寫排序功能，更加內(nèi)聚。

我們在緩存上做了一點(diǎn)小小的優(yōu)化，由于查詢結(jié)果緩存通常來說帶有源文檔內(nèi)容會比較大，為了避免流量高峰頻繁訪問導(dǎo)致 Codis 集群網(wǎng)絡(luò)擁堵，我們在 Proxy 上實(shí)現(xiàn)了一個簡單的本地緩存，在流量高峰時自動降級。

這里提一下模板查詢，在查詢結(jié)構(gòu)(DSL)相對固定又比較冗長的情況下，比如商品類目篩選、訂單篩選等，可以通過模板查詢(Search Template)來實(shí)現(xiàn)。

一方面簡化業(yè)務(wù)編排 DSL 的負(fù)擔(dān)，另一方面還可以通過編輯查詢模板 Template，利用默認(rèn)值、可選條件等手段在服務(wù)端進(jìn)行線上查詢性能調(diào)優(yōu)。

管理平臺

為了降低日常的索引增刪、字段修改、配置同步上的維護(hù)成本，我們基于 Django 實(shí)現(xiàn)了最初版本的搜索管理平臺。

主要提供一套索引變更的審批流以及向不同集群同步索引配置的功能，以可視化的方式實(shí)現(xiàn)索引元數(shù)據(jù)的管理，減少我們在平臺日常維護(hù)上的時間成本。

由于開源 Head 插件在效果展示上的不友好，以及暴露了部分粗暴功能：

 

如上圖，可以通過點(diǎn)按字段使得索引按指定字段排序展示結(jié)果，在早期版本 Elasticsearch 會通過 Fielddata 加載需要排序的字段內(nèi)容。

如果字段數(shù)據(jù)量比較大，很容易導(dǎo)致 Heap 內(nèi)存占滿引發(fā) Full GC 甚至 OOM。

為了避免重復(fù)出現(xiàn)此類問題，我們也提供了定制的可視化查詢組件以支持用戶瀏覽數(shù)據(jù)的需求。

ESWriter

由于 ES-Hadoop 僅能通過控制 Map-Reduce 個數(shù)來調(diào)整讀寫流量，實(shí)際上 ES-Hadoop 是以 Elasticsearch 是否拒絕請求來調(diào)整自身行為，對線上工作的集群相當(dāng)不友好。

為了解決這種離線讀寫流量上的不可控，我們在現(xiàn)有的 DataX 基礎(chǔ)上開發(fā)了一個 ESWriter 插件，能夠?qū)崿F(xiàn)記錄條數(shù)或者流量大小的秒級控制。

面臨挑戰(zhàn)

平臺化以及配套的文檔體系完善降低了用戶的接入門檻，隨著業(yè)務(wù)的快速增長，Elasticsearch 集群本身的運(yùn)維成本也讓我們逐漸不堪。

雖然有物理隔離的多個集群，但不可避免的會有多個業(yè)務(wù)索引共享同一個物理集群，在不同業(yè)務(wù)間各有出入的生產(chǎn)標(biāo)準(zhǔn)上支持不佳，在同一個集群內(nèi)部署過多的索引也是生產(chǎn)環(huán)境穩(wěn)定運(yùn)行的一個隱患。

另外集群服務(wù)能力的彈性伸縮相對困難，水平擴(kuò)容一個節(jié)點(diǎn)都需要經(jīng)歷機(jī)器申請、環(huán)境初始化、軟件安裝等步驟，如果是物理機(jī)還需要更長時間的機(jī)器采購過程，不能及時響應(yīng)服務(wù)能力的不足。

未來的架構(gòu) 4.0

當(dāng)前架構(gòu)通過開放接口接受用戶的數(shù)據(jù)同步需求，雖然實(shí)現(xiàn)了與業(yè)務(wù)解耦，降低了我們團(tuán)隊(duì)自身的開發(fā)成本，但是相對的用戶開發(fā)成本也變高了。

數(shù)據(jù)從數(shù)據(jù)庫到索引需要經(jīng)歷從數(shù)據(jù)總線獲取數(shù)據(jù)、同步應(yīng)用處理數(shù)據(jù)、調(diào)用搜索平臺開放接口寫入數(shù)據(jù)三個步驟。

其中從數(shù)據(jù)總線獲取數(shù)據(jù)與寫入搜索平臺這兩個步驟在多個業(yè)務(wù)的同步程序中都會被重復(fù)開發(fā)，造成資源浪費(fèi)。

這里我們目前也準(zhǔn)備與 PaaS 團(tuán)隊(duì)內(nèi)自研的 DTS(Data Transporter，數(shù)據(jù)同步服務(wù))進(jìn)行集成，通過配置化的方式實(shí)現(xiàn) Elasticsearch 與多種數(shù)據(jù)源之間的自動化數(shù)據(jù)同步。

要解決共享集群應(yīng)對不同生產(chǎn)標(biāo)準(zhǔn)應(yīng)用的問題，我們希望進(jìn)一步將平臺化的搜索服務(wù)提升為云化的服務(wù)申請機(jī)制，配合對業(yè)務(wù)的等級劃分，將核心應(yīng)用獨(dú)立部署為相互隔離的物理集群。

而非核心應(yīng)用通過不同的應(yīng)用模板申請基于 K8S 運(yùn)行的 Elasticsearch 云服務(wù)。

應(yīng)用模板中會定義不同應(yīng)用場景下的服務(wù)配置，從而解決不同應(yīng)用的生產(chǎn)標(biāo)準(zhǔn)差異問題，而且云服務(wù)可以根據(jù)應(yīng)用運(yùn)行狀況及時進(jìn)行服務(wù)的伸縮容。