有贊搜索系統(tǒng)的架構(gòu)演進(jìn)-創(chuàng)新互聯(lián)

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

成都創(chuàng)新互聯(lián)堅(jiān)持“要么做到,要么別承諾”的工作理念,服務(wù)領(lǐng)域包括:成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù),滿(mǎn)足客戶(hù)于互聯(lián)網(wǎng)時(shí)代的南陽(yáng)網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求,幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴!

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

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

Elasticsearch

Elasticsearch 是一個(gè)高可用分布式搜索引擎,一方面技術(shù)相對(duì)成熟穩(wěn)定,另一方面社區(qū)也比較活躍,因此我們?cè)诖罱ㄋ阉飨到y(tǒng)過(guò)程中也是選擇了 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ù)通過(guò) Canal 從 DB 同步到 Elasticsearch,大致架構(gòu)如下:

有贊搜索系統(tǒng)的架構(gòu)演進(jìn)

通過(guò)這種方式,在業(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 集群也沒(méi)有做物理隔離,有一次促銷(xiāo)活動(dòng)就因?yàn)榉劢z數(shù)據(jù)量過(guò)于龐大導(dǎo)致 Elasticsearch 進(jìn)程 heap 內(nèi)存耗盡而 OOM,使得集群內(nèi)全部索引都無(wú)法正常工作,這給我上了深深的一課。

架構(gòu) 2.0

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

有贊搜索系統(tǒng)的架構(gòu)演進(jìn)

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

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

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

有贊搜索系統(tǒng)的架構(gòu)演進(jìn)

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

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

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

有贊搜索系統(tǒng)的架構(gòu)演進(jìn)

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

問(wèn)題

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

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

目前的架構(gòu) 3.0

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

  1. 通過(guò)開(kāi)放接口接收用戶(hù)調(diào)用,與業(yè)務(wù)代碼完全解耦;

  2. 增加 proxy 用來(lái)對(duì)外服務(wù),預(yù)處理用戶(hù)請(qǐng)求并執(zhí)行必要的流控、緩存等操作;

  3. 提供管理平臺(tái)簡(jiǎn)化索引變更和集群管理 這樣的演變讓有贊搜索系統(tǒng)逐漸的平臺(tái)化,已經(jīng)初具了一個(gè)搜索平臺(tái)的架構(gòu):

有贊搜索系統(tǒng)的架構(gòu)演進(jìn)

Proxy

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

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

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

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

管理平臺(tái)

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

由于開(kāi)源 head 插件在效果展示上的不友好,以及暴露了部分粗暴功能:

有贊搜索系統(tǒng)的架構(gòu)演進(jìn)

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

ESWriter

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

挑戰(zhàn)

平臺(tái)化以及配套的文檔體系完善降低了用戶(hù)的接入門(mén)檻,隨著業(yè)務(wù)的快速增長(zhǎng),Elasticsearch 集群本身的運(yùn)維成本也讓我們逐漸不堪,雖然有物理隔離的多個(gè)集群,但不可避免的會(huì)有多個(gè)業(yè)務(wù)索引共享同一個(gè)物理集群,在不同業(yè)務(wù)間各有出入的生產(chǎn)標(biāo)準(zhǔn)上支持不佳,在同一個(gè)集群內(nèi)部署過(guò)多的索引也是生產(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)過(guò)程,不能及時(shí)響應(yīng)服務(wù)能力的不足。

未來(lái)的架構(gòu) 4.0

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

要解決共享集群應(yīng)對(duì)不同生產(chǎn)標(biāo)準(zhǔn)應(yīng)用的問(wèn)題,我們希望進(jìn)一步將平臺(tái)化的搜索服務(wù)提升為云化的服務(wù)申請(qǐng)機(jī)制,配合對(duì)業(yè)務(wù)的等級(jí)劃分,將核心應(yīng)用獨(dú)立部署為相互隔離的物理集群,而非核心應(yīng)用通過(guò)不同的應(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èn)題,而且云服務(wù)可以根據(jù)應(yīng)用運(yùn)行狀況及時(shí)進(jìn)行服務(wù)的伸縮容。

網(wǎng)站欄目:有贊搜索系統(tǒng)的架構(gòu)演進(jìn)-創(chuàng)新互聯(lián)
本文鏈接:http://muchs.cn/article6/cshgig.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供動(dòng)態(tài)網(wǎng)站網(wǎng)站排名、標(biāo)簽優(yōu)化網(wǎng)站建設(shè)、虛擬主機(jī)靜態(tài)網(wǎng)站

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話(huà):028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)

小程序開(kāi)發(fā)