來源：公眾號有贊coder文 | hehua on PaaS

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

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

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

Elasticsearch

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

架構1.0

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

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

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

架構 2.0

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

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

高級搜索（Advanced Search）

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

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

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

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

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

問題

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

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

目前的架構 3.0

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

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

Proxy

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

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

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

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

管理平臺

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

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

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

ESWriter

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

挑戰(zhàn)

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

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

未來的架構 4.0

當前架構通過開放接口接受用戶的數(shù)據(jù)同步需求，雖然實現(xiàn)了與業(yè)務解耦，降低了我們團隊自身的開發(fā)成本，但是相對的用戶開發(fā)成本也變高了，數(shù)據(jù)從數(shù)據(jù)庫到索引需要經(jīng)歷從數(shù)據(jù)總線獲取數(shù)據(jù)、同步應用處理數(shù)據(jù)、調(diào)用搜索平臺開放接口寫入數(shù)據(jù)三個步驟，其中從數(shù)據(jù)總線獲取數(shù)據(jù)與寫入搜索平臺這兩個步驟在多個業(yè)務的同步程序中都會被重復開發(fā)，造成資源浪費。這里我們目前也準備與 PaaS 團隊內(nèi)自研的DTS（Data Transporter，數(shù)據(jù)同步服務）進行集成，通過配置化的方式實現(xiàn) Elasticsearch 與多種數(shù)據(jù)源之間的自動化數(shù)據(jù)同步。

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

小結

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