來源：公眾號(hào)有贊coder文 | hehua on PaaS

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

在為傳統(tǒng)的搜索應(yīng)用提供高級(jí)檢索和大數(shù)據(jù)交互能力的同時(shí)，有贊搜索平臺(tái)還需要為其他比如商品管理、訂單檢索、粉絲篩選等海量數(shù)據(jù)過濾提供支持，從工程的角度看，如何擴(kuò)展平臺(tái)以支持多樣的檢索需求是一個(gè)巨大的挑戰(zhàn)。

我是有贊搜索團(tuán)隊(duì)的第一位員工，也有幸負(fù)責(zé)設(shè)計(jì)開發(fā)了有贊搜索平臺(tái)到目前為止的大部分功能特性，我們搜索團(tuán)隊(duì)目前主要負(fù)責(zé)平臺(tái)的性能、可擴(kuò)展性和可靠性方面的問題，并盡可能降低平臺(tái)的運(yùn)維成本以及業(yè)務(wù)的開發(fā)成本。

Elasticsearch

Elasticsearch 是一個(gè)高可用分布式搜索引擎，一方面技術(shù)相對(duì)成熟穩(wěn)定，另一方面社區(qū)也比較活躍，因此我們?cè)诖罱ㄋ阉飨到y(tǒng)過程中也是選擇了 Elasticsearch 作為我們的基礎(chǔ)引擎。

架構(gòu)1.0

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

通過這種方式，在業(yè)務(wù)量較小時(shí)，可以低成本的快速為不同業(yè)務(wù)索引創(chuàng)建同步應(yīng)用，適合業(yè)務(wù)快速發(fā)展時(shí)期，但相對(duì)的每個(gè)同步程序都是單體應(yīng)用，不僅與業(yè)務(wù)庫(kù)地址耦合，需要適應(yīng)業(yè)務(wù)庫(kù)快速的變化，如遷庫(kù)、分庫(kù)分表等，而且多個(gè) canal 同時(shí)訂閱同一個(gè)庫(kù)，也會(huì)造成數(shù)據(jù)庫(kù)性能的下降。

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

架構(gòu) 2.0

我們?cè)诮鉀Q以上問題的過程中，也自然的沉淀出了有贊搜索的 2.0 版架構(gòu)，大致架構(gòu)如下：

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

高級(jí)搜索（Advanced Search）

隨著業(yè)務(wù)發(fā)展，我們也逐漸出現(xiàn)了一些比較中心化的流量入口，比如分銷、精選等，這時(shí)普通的 bool 查詢并不能滿足我們對(duì)搜索結(jié)果的細(xì)粒率排序控制需求，將復(fù)雜的 function_score 之類專業(yè)性較強(qiáng)的高級(jí)查詢編寫和優(yōu)化工作交給業(yè)務(wù)開發(fā)負(fù)責(zé)顯然是個(gè)不可取的選項(xiàng)，這里我們考慮的是通過一個(gè)高級(jí)查詢中間件攔截業(yè)務(wù)查詢請(qǐng)求，在解析出必要的條件后重新組裝為高級(jí)查詢交給引擎執(zhí)行，大致架構(gòu)如下：

這里另外做的一點(diǎn)優(yōu)化是加入了搜索結(jié)果緩存，常規(guī)的文本檢索查詢 match 每次執(zhí)行都需要實(shí)時(shí)計(jì)算，在實(shí)際的應(yīng)用場(chǎng)景中這并不是必須的，用戶在一定時(shí)間段內(nèi)（比如 15 或 30 分鐘）通過同樣的請(qǐng)求訪問到同樣的搜索結(jié)果是完全可以接受的，在中間件做一次結(jié)果緩存可以避免重復(fù)查詢反復(fù)執(zhí)行的虛耗，同時(shí)提升中間件響應(yīng)速度，對(duì)高級(jí)搜索比較感興趣的同學(xué)可以閱讀另外一篇文章《有贊搜索引擎實(shí)踐（工程篇）》（見技術(shù)博客），這里不再細(xì)述。

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

搜索應(yīng)用和大數(shù)據(jù)密不可分，除了通過日志分析來挖掘用戶行為的更多價(jià)值之外，離線計(jì)算排序綜合得分也是優(yōu)化搜索應(yīng)用體驗(yàn)不可缺少的一環(huán)，在 2.0 階段我們通過開源的 es-hadoop 組件搭建 hive 與 Elasticsearch 之間的交互通道，大致架構(gòu)如下：

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

問題

這樣的架構(gòu)支撐了搜索系統(tǒng)一年多的運(yùn)行，但是也暴露出了許多問題，首當(dāng)其沖的是越發(fā)高昂的維護(hù)成本，除去 Elasticsearch 集群維護(hù)和索引本身的配置、字段變更，雖然已經(jīng)通過數(shù)據(jù)總線與業(yè)務(wù)庫(kù)解耦，但是耦合在同步程序中的業(yè)務(wù)代碼依舊為團(tuán)隊(duì)帶來了極大的維護(hù)負(fù)擔(dān)。消息隊(duì)列雖然一定程序上減輕了我們與業(yè)務(wù)的耦合，但是帶來的消息順序問題也讓不熟悉業(yè)務(wù)數(shù)據(jù)狀態(tài)的我們很難處理。這些問題我總結(jié)在之前寫過的一篇文章。

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

目前的架構(gòu) 3.0

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

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

Proxy

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

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

緩存和 ESLoader 主要是將原先高級(jí)搜索中的通用功能集成進(jìn)來，使得高級(jí)搜索可以專注于搜索自身的查詢分析和重寫排序功能，更加內(nèi)聚。我們?cè)诰彺嫔献隽艘稽c(diǎn)小小的優(yōu)化，由于查詢結(jié)果緩存通常來說帶有源文檔內(nèi)容會(huì)比較大，為了避免流量高峰頻繁訪問導(dǎo)致 codis 集群網(wǎng)絡(luò)擁堵，我們?cè)?proxy 上實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的本地緩存，在流量高峰時(shí)自動(dòng)降級(jí)。

這里提一下模板查詢，在查詢結(jié)構(gòu)（DSL）相對(duì)固定又比較冗長(zhǎng)的情況下，比如商品類目篩選、訂單篩選等，可以通過模板查詢（search template）來實(shí)現(xiàn)，一方面簡(jiǎn)化業(yè)務(wù)編排DSL的負(fù)擔(dān)，另一方面還可以通過編輯查詢模板 template，利用默認(rèn)值、可選條件等手段在服務(wù)端進(jìn)行線上查詢性能調(diào)優(yōu)。

管理平臺(tái)

為了降低日常的索引增刪、字段修改、配置同步上的維護(hù)成本，我們基于 Django 實(shí)現(xiàn)了最初版本的搜索管理平臺(tái)，主要提供一套索引變更的審批流以及向不同集群同步索引配置的功能，以可視化的方式實(shí)現(xiàn)索引元數(shù)據(jù)的管理，減少我們?cè)谄脚_(tái)日常維護(hù)上的時(shí)間成本。

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

如圖，可以通過點(diǎn)按字段使得索引按指定字段排序展示結(jié)果，在早期版本 Elasticsearch 會(huì)通過 fielddata 加載需要排序的字段內(nèi)容，如果字段數(shù)據(jù)量比較大，很容易導(dǎo)致 heap 內(nèi)存占滿引發(fā) full gc 甚至 OOM，為了避免重復(fù)出現(xiàn)此類問題，我們也提供了定制的可視化查詢組件以支持用戶瀏覽數(shù)據(jù)的需求。

ESWriter

由于 es-hadoop 僅能通過控制 map-reduce 個(gè)數(shù)來調(diào)整讀寫流量，實(shí)際上 es-hadoop 是以 Elasticsearch 是否拒絕請(qǐng)求來調(diào)整自身行為，對(duì)線上工作的集群相當(dāng)不友好。為了解決這種離線讀寫流量上的不可控，我們?cè)诂F(xiàn)有的 DataX 基礎(chǔ)上開發(fā)了一個(gè) ESWriter 插件，能夠?qū)崿F(xiàn)記錄條數(shù)或者流量大小的秒級(jí)控制。

挑戰(zhàn)

平臺(tái)化以及配套的文檔體系完善降低了用戶的接入門檻，隨著業(yè)務(wù)的快速增長(zhǎng)，Elasticsearch 集群本身的運(yùn)維成本也讓我們逐漸不堪，雖然有物理隔離的多個(gè)集群，但不可避免的會(huì)有多個(gè)業(yè)務(wù)索引共享同一個(gè)物理集群，在不同業(yè)務(wù)間各有出入的生產(chǎn)標(biāo)準(zhǔn)上支持不佳，在同一個(gè)集群內(nèi)部署過多的索引也是生產(chǎn)環(huán)境穩(wěn)定運(yùn)行的一個(gè)隱患。

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

未來的架構(gòu) 4.0

當(dāng)前架構(gòu)通過開放接口接受用戶的數(shù)據(jù)同步需求，雖然實(shí)現(xiàn)了與業(yè)務(wù)解耦，降低了我們團(tuán)隊(duì)自身的開發(fā)成本，但是相對(duì)的用戶開發(fā)成本也變高了，數(shù)據(jù)從數(shù)據(jù)庫(kù)到索引需要經(jīng)歷從數(shù)據(jù)總線獲取數(shù)據(jù)、同步應(yīng)用處理數(shù)據(jù)、調(diào)用搜索平臺(tái)開放接口寫入數(shù)據(jù)三個(gè)步驟，其中從數(shù)據(jù)總線獲取數(shù)據(jù)與寫入搜索平臺(tái)這兩個(gè)步驟在多個(gè)業(yè)務(wù)的同步程序中都會(huì)被重復(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ù)源之間的自動(dòng)化數(shù)據(jù)同步。

要解決共享集群應(yīng)對(duì)不同生產(chǎn)標(biāo)準(zhǔn)應(yīng)用的問題，我們希望進(jìn)一步將平臺(tái)化的搜索服務(wù)提升為云化的服務(wù)申請(qǐng)機(jī)制，配合對(duì)業(yè)務(wù)的等級(jí)劃分，將核心應(yīng)用獨(dú)立部署為相互隔離的物理集群，而非核心應(yīng)用通過不同的應(yīng)用模板申請(qǐng)基于 k8s 運(yùn)行的 Elasticsearch 云服務(wù)。應(yīng)用模板中會(huì)定義不同應(yīng)用場(chǎng)景下的服務(wù)配置，從而解決不同應(yīng)用的生產(chǎn)標(biāo)準(zhǔn)差異問題，而且云服務(wù)可以根據(jù)應(yīng)用運(yùn)行狀況及時(shí)進(jìn)行服務(wù)的伸縮容。

小結(jié)

本文從架構(gòu)上介紹了有贊搜索系統(tǒng)演進(jìn)產(chǎn)生的背景以及希望解決的問題，涉及具體技術(shù)細(xì)節(jié)的內(nèi)容我們將會(huì)在本系列的下一篇文章中更新。