本文從架構上介紹了有贊搜索系統演進產生的背景以及希望解決的問題。

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

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

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

我們搜索團隊目前主要負責平臺的性能、可擴展性和可靠性方面的問題，并盡可能降低平臺的運維成本以及業務的開發成本。

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

架構 1.0

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

 

通過這種方式，在業務量較小時，可以低成本的快速為不同業務索引創建同步應用，適合業務快速發展時期。

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

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

架構 2.0

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

 

首先數據總線將數據變更消息同步到 MQ，同步應用通過消費 MQ 消息來同步業務庫數據，借數據總線實現與業務庫的解耦，引入數據總線也可以避免多個 Canal 監聽消費同一張表 Binlog 的虛耗。

高級搜索(Advanced Search)

隨著業務發展，我們也逐漸出現了一些比較中心化的流量入口，比如分銷、精選等。

這時普通的 Bool 查詢并不能滿足我們對搜索結果的細粒率排序控制需求，將復雜的 function_score 之類專業性較強的高級查詢編寫和優化工作交給業務開發負責顯然是個不可取的選項。

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

 

這里另外做的一點優化是加入了搜索結果緩存，常規的文本檢索查詢 Match 每次執行都需要實時計算。

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

在中間件做一次結果緩存可以避免重復查詢反復執行的虛耗，同時提升中間件響應速度。

大數據集成

搜索應用和大數據密不可分，除了通過日志分析來挖掘用戶行為的更多價值之外，離線計算排序綜合得分也是優化搜索應用體驗不可缺少的一環。

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

 

通過 Flume 收集搜索日志存儲到 HDFS 供后續分析，也可以在通過 Hive 分析后導出作為搜索提示詞，當然大數據為搜索業務提供的遠不止于此，這里只是簡單列舉了幾項功能。

遇到的問題

這樣的架構支撐了搜索系統一年多的運行，但是也暴露出了許多問題，首當其沖的是越發高昂的維護成本。

除去 Elasticsearch 集群維護和索引本身的配置、字段變更，雖然已經通過數據總線與業務庫解耦，但是耦合在同步程序中的業務代碼依舊為團隊帶來了極大的維護負擔。

消息隊列雖然一定程序上減輕了我們與業務的耦合，但是帶來的消息順序問題也讓不熟悉業務數據狀態的我們很難處理。

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

目前的架構 3.0

 

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

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

Proxy

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

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

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

我們在緩存上做了一點小小的優化，由于查詢結果緩存通常來說帶有源文檔內容會比較大，為了避免流量高峰頻繁訪問導致 Codis 集群網絡擁堵，我們在 Proxy 上實現了一個簡單的本地緩存，在流量高峰時自動降級。

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

一方面簡化業務編排 DSL 的負擔，另一方面還可以通過編輯查詢模板 Template，利用默認值、可選條件等手段在服務端進行線上查詢性能調優。

管理平臺

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

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

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

 

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

如果字段數據量比較大，很容易導致 Heap 內存占滿引發 Full GC 甚至 OOM。

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

ESWriter

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

為了解決這種離線讀寫流量上的不可控，我們在現有的 DataX 基礎上開發了一個 ESWriter 插件，能夠實現記錄條數或者流量大小的秒級控制。

面臨挑戰

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

雖然有物理隔離的多個集群，但不可避免的會有多個業務索引共享同一個物理集群，在不同業務間各有出入的生產標準上支持不佳，在同一個集群內部署過多的索引也是生產環境穩定運行的一個隱患。

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

未來的架構 4.0

當前架構通過開放接口接受用戶的數據同步需求，雖然實現了與業務解耦，降低了我們團隊自身的開發成本，但是相對的用戶開發成本也變高了。

數據從數據庫到索引需要經歷從數據總線獲取數據、同步應用處理數據、調用搜索平臺開放接口寫入數據三個步驟。

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

這里我們目前也準備與 PaaS 團隊內自研的 DTS(Data Transporter，數據同步服務)進行集成，通過配置化的方式實現 Elasticsearch 與多種數據源之間的自動化數據同步。

要解決共享集群應對不同生產標準應用的問題，我們希望進一步將平臺化的搜索服務提升為云化的服務申請機制，配合對業務的等級劃分，將核心應用獨立部署為相互隔離的物理集群。

而非核心應用通過不同的應用模板申請基于 K8S 運行的 Elasticsearch 云服務。

應用模板中會定義不同應用場景下的服務配置，從而解決不同應用的生產標準差異問題，而且云服務可以根據應用運行狀況及時進行服務的伸縮容。