當(dāng)當(dāng)網(wǎng)高可用移動入口與搜索技術(shù)架構(gòu)

1、 當(dāng)當(dāng)網(wǎng)高可用移動入口與搜索技術(shù)架構(gòu)聊聊架構(gòu) 微信號 archtime功能介紹 以架構(gòu)之“道”為基礎(chǔ)，呈現(xiàn)更多務(wù)實(shí)落地的架構(gòu)內(nèi)容。每年一次的互聯(lián)網(wǎng)電商的雙十一，是對一年工作的總結(jié)和洗禮，在 2017 年的雙十一到來之際，我們希望通過本文梳理一下當(dāng)當(dāng)?shù)囊恍┬兄行У姆椒?。面對爆發(fā)性增長的流量，首要任務(wù)是讓系統(tǒng)在大流量沖擊的情況下能夠先存活下來，通過應(yīng)用限流，您可以了解到當(dāng)當(dāng)如何在流量洪峰中保持現(xiàn)有系統(tǒng)的服務(wù)能力。在眾多的系統(tǒng)中，系統(tǒng)之間的交互過于繁雜，一套全方位的鏈路監(jiān)控系統(tǒng)，可以快速定位某個(gè)子系統(tǒng)的問題，通過 APM 系統(tǒng)，您將了解到當(dāng)當(dāng)在大量服務(wù)并存的情況下如何快速定位系統(tǒng)問題。MAPI 是

2、載當(dāng)當(dāng)大部分入口流量的移動端網(wǎng)關(guān)，通過 MAPI 對服務(wù)治理以及性能的分享，您將能夠以點(diǎn)帶面地一窺當(dāng)當(dāng)業(yè)務(wù)系統(tǒng)的設(shè)計(jì)思路。搜索系統(tǒng)的重要程度不言而喻，而且它與業(yè)務(wù)系統(tǒng)的側(cè)重點(diǎn)不盡相同，今年當(dāng)當(dāng)重點(diǎn)對搜索系統(tǒng)進(jìn)行了重構(gòu)，您可以通過對搜索新架構(gòu)的解讀一同探索技術(shù)的點(diǎn)點(diǎn)滴滴。應(yīng)用限流 電商平臺的流量因促銷、搶券、秒殺、熱銷品開賣等情況會出現(xiàn)大大小小的流量洪峰。流量洪峰的瞬時(shí)沖擊（比如雙十一零點(diǎn)的電商大促），可能導(dǎo)致系統(tǒng)響應(yīng)緩慢，甚至整體崩潰，將對公司帶來直接損失，因此大部分互聯(lián)網(wǎng)電商都會有自己的一套解決方案，比如：流量疏導(dǎo)、服務(wù)降級、應(yīng)用限流等。接下來介紹下當(dāng)當(dāng)在應(yīng)用限流的設(shè)計(jì)思路和一些做法。限流體

3、系的整體架構(gòu)圖如下：當(dāng)當(dāng)?shù)膽?yīng)用限流包含 3 個(gè)子系統(tǒng)：基于 Openresty/Nginx 的限流引擎，包含限流策略和限流算法?；?Prometheus 和 Grafana 的流量監(jiān)控模塊基于 Hadoop（計(jì)劃中）和 java Web 的配置中心下面分別介紹各子系統(tǒng)的一些設(shè)計(jì)經(jīng)驗(yàn)。限流引擎子系統(tǒng) 在實(shí)際業(yè)務(wù)中，絕大部分應(yīng)用服務(wù)器部署在反向代理服務(wù)器（Nginx）后面。一般情況下，Nginx 的性能不會成為瓶頸，后端的應(yīng)用服務(wù)器會由于各種原因（如數(shù)據(jù)庫緩慢、I/O 等待時(shí)間長、代碼自身的缺陷等）成為瓶頸，所以主要是根據(jù) Nginx 后端連接的應(yīng)用服務(wù)器的負(fù)載情況來決定采用何種策略對前面的 N

4、ginx 進(jìn)行限流。同時(shí)對應(yīng)用服務(wù)器層無需做任何調(diào)整即可實(shí)現(xiàn)流量控制，開發(fā)簡單，維護(hù)成本低。反向代理服務(wù)器使用的是 Openresty（），一個(gè)基于 Nginx 的 Lua 環(huán)境封裝，使用 LuaJIT 作為 Lua 編譯器，由于 Just-In-Time 的方式，比傳統(tǒng) Lua 運(yùn)行更高效。當(dāng)當(dāng)?shù)南蘖鬟壿嫽谒_發(fā)。首先介紹一下 限流算法，常用的擁塞控制算法有兩種：漏桶算法可以用在控制應(yīng)用服務(wù)器發(fā)送請求到其他應(yīng)用服務(wù)器的速率，確保一個(gè)穩(wěn)定的速率，主要用于控制回調(diào)洪峰（其他系統(tǒng)的調(diào)用）的，針對用戶洪峰更適合令牌桶算法。但是如果無差別拒絕請求，會導(dǎo)致用戶體驗(yàn)的嚴(yán)重下降，因此 需要策略組的配合，按

5、照一定的規(guī)則拒絕請求，比較合理的做法是：通過防刷算法，拒絕疑似攻擊的請求通過用戶識別碼、IP、所在區(qū)域、上網(wǎng)特征和接口特征等方式拒絕頻繁訪問的用戶，保證服務(wù)器資源能服務(wù)更多的用戶。盡量不影響已服務(wù)用戶的使用體驗(yàn)對于正在挑選商品的用戶（較多的單品頁、添加購物車等操作），要盡量保證不被限流擋住，否則會降低用戶的使用粘性?？梢宰龅姆椒ㄊ窃黾右粋€(gè)訪問令牌，記錄用戶一些重要操作時(shí)間，在流量不夠的情況下，優(yōu)先放行具備訪問令牌的用戶。盡量保證會員的使用體驗(yàn)平臺的會員尤其是高級會員一般是具備較大網(wǎng)購需求的用戶，他們往往更能影響平臺的口碑，所以平臺要服務(wù)好這部分的會員。其次將限流引擎中的參數(shù)進(jìn)行整理，對外提供

6、HTTP Rest 接口，可以熱更新限流策略和相關(guān)參數(shù)，對接應(yīng)用限流 - 配置中心子系統(tǒng)。值得注意的是，openresty 提供了一種 dict 的類型是子進(jìn)程內(nèi)存共享的，可以跨 worker 訪問，如果操作是進(jìn)程不安全操作記得加鎖，另外這種類型在聲明時(shí)需要提供開辟內(nèi)存大小，根據(jù)業(yè)務(wù)負(fù)載情況進(jìn)行指定，超過內(nèi)存大小會通過 LRU 算法進(jìn)行內(nèi)存回收。以下介紹了一些重要參數(shù)的說明：最后提供了 流量指標(biāo)上報(bào) 模塊，按照配置參數(shù)進(jìn)行定時(shí)數(shù)據(jù)上報(bào)，目前上報(bào)總流量、通過流量、拒絕流量、分流流量、主機(jī) IP、應(yīng)用名等實(shí)時(shí)信息。上報(bào)數(shù)據(jù)進(jìn)入流量監(jiān)控子系統(tǒng)，進(jìn)行實(shí)時(shí)流量監(jiān)控和離線分析，稍后會在流量監(jiān)控模塊詳細(xì)說明

7、。流量監(jiān)控子系統(tǒng) Prometheus 作為一種 time series 數(shù)據(jù)庫，很適合做實(shí)時(shí)業(yè)務(wù)監(jiān)控。因此根據(jù)上文上報(bào)數(shù)據(jù)的配置，經(jīng)過 Prometheus Push Gateway 將數(shù)據(jù)初步匯總，最終通過 Prometheus 拉取數(shù)據(jù)。Grafana 則接入 Prometheus 數(shù)據(jù)源，提供實(shí)時(shí)流量頁面和告警功能?？梢酝ㄟ^查詢各個(gè)應(yīng)用集群的流量分布，通過率低于閾值或者一定時(shí)間流量為 0 則直接告警。Grafana Config Update Daemon 則定時(shí)比對 Prometheus 和 Grafana 的配置差異，動態(tài)調(diào)整 Grafana 配置圖，能夠達(dá)到上下線主機(jī)和應(yīng)用時(shí)，不

8、需要手工維護(hù) Grafana Web，實(shí)現(xiàn)自動化運(yùn)維。配置中心子系統(tǒng) 通過 web 頁面調(diào)用推薦引擎子系統(tǒng)提供的接口，獲取當(dāng)前各個(gè)系統(tǒng)配置信息。并通過頁面進(jìn)行限流策略、限流閾值等信息的實(shí)時(shí)更新。未來計(jì)劃通過定時(shí)抓取 Prometheus 的數(shù)據(jù)，將數(shù)據(jù)存放在 Hadoop 中，基于 time series 預(yù)測算法訓(xùn)練模型數(shù)據(jù)，對未來大促進(jìn)行流量預(yù)判。通過提供的 Web 頁面，管理員可以查看歷史流量和流量預(yù)測數(shù)據(jù)，指導(dǎo)系統(tǒng)管理員優(yōu)化應(yīng)用限流配置的同時(shí)，也積累了寶貴的大促流量數(shù)據(jù)。為日后分析用戶行為，甚至市場運(yùn)營的判斷提供更廣闊的空間。APM 系統(tǒng) 如今的電商平臺隨著業(yè)務(wù)復(fù)雜化，包含的功能越來越

9、多，內(nèi)部系統(tǒng)間的調(diào)用關(guān)系也越來越多。針對一個(gè)用戶的一次購買流程（商品展示、搜索、購買、支付）可能需要調(diào)用數(shù)十次、甚至上百次的接口。首先如此龐大的調(diào)用鏈?zhǔn)崂沓蔀橐患芗值氖虑?，而更迫在眉睫的事情是針對用戶偶現(xiàn)的慢操作問題，無法快速定位到眾多調(diào)用中的哪一步導(dǎo)致的。因此急需一套完整的應(yīng)用性能治理系統(tǒng)APM（Application Performance Management）來解決這個(gè)問題。在 APM 產(chǎn)品選型時(shí)，我們考慮到當(dāng)當(dāng)目前系統(tǒng)的現(xiàn)狀，得出了以下的結(jié)論：APM 產(chǎn)品需要性能極高，嵌入線上系統(tǒng)的探針需要盡量少的資源來完成調(diào)用信息獲取，APM 自身也需要能承載百億量級的入庫和查詢操作的能力。A

10、PM 產(chǎn)品需要方便部署使用，盡量不改動或者輕微改動代碼即可實(shí)現(xiàn)系統(tǒng)追蹤。APM 系統(tǒng)可以提供系統(tǒng)依賴關(guān)系、SLA 指標(biāo)和調(diào)用耗時(shí)甘特圖。APM 產(chǎn)品方便定制開發(fā)，方便擴(kuò)展內(nèi)部不同語言的系統(tǒng)使用和提供各種的統(tǒng)計(jì)數(shù)據(jù)。最終我們選取了 OpenSkywalking 團(tuán)隊(duì)開發(fā)的 skywalking 產(chǎn)品（http:/skywalking.io）作為當(dāng)當(dāng) APM 系統(tǒng)，并進(jìn)行定制開發(fā)。Skywalking 是遵守 opentracing 規(guī)范（CNCF 基金會下，開源分布式服務(wù)追蹤標(biāo)準(zhǔn)）開發(fā)的，針對 java 支持使用字節(jié)碼增強(qiáng)技術(shù)，無需改動代碼即可實(shí)現(xiàn)系統(tǒng)追蹤。自動追蹤支持主流的 web 容器、中間

11、件、RPC 組件、數(shù)據(jù)庫和 NOSQL 等。架構(gòu)圖如下：Skywalking 每個(gè)節(jié)點(diǎn)都支持集群模式，可以無限水平擴(kuò)展，易用的 Java 探針自動上報(bào)數(shù)據(jù)，無需程序做任何改動。但是當(dāng)當(dāng)內(nèi)部系統(tǒng)使用語言眾多，除了 Java，包含 PHP、C、Python 和 Go 等語言開發(fā)的系統(tǒng)。對于 APM 系統(tǒng)來講，追蹤的調(diào)用軌跡只要一個(gè)節(jié)點(diǎn)沒有追蹤到，就會導(dǎo)致鏈路中斷，達(dá)不到預(yù)期效果，因此我們在 Skywalking 上針對不同語言開發(fā)了相應(yīng)的組件包 agent。agent 中為了盡量減少對業(yè)務(wù)系統(tǒng)的影響，使用寫文件的方式，再通過 Filebeat+Kafka 的方式將追蹤信息發(fā)給 collector，

12、改造完的架構(gòu)圖如下：如上圖所示，agent 只負(fù)責(zé)匯總收集數(shù)據(jù)，和 collector 保持啟動時(shí)候的注冊功能，數(shù)據(jù)上報(bào)功能則通過寫文件的方法，交給另一個(gè) Filebeat 進(jìn)程來完成。Filebeat 通過配置一個(gè) Kafka 的 Topic，將數(shù)據(jù)發(fā)送到 Kafka 集群，再通過 Kafka consumer 來拉取數(shù)據(jù)發(fā)送 skywalking collector。同時(shí) agent 提供管理服務(wù) API，可以通過管理 web 界面管理 agent 的運(yùn)行情況、開關(guān)、采樣率等信息，在 agent 工作影響線上服務(wù)性能時(shí)（比如大促之時(shí)），可以快速關(guān)閉探針采集和上報(bào)功能來保證系統(tǒng)最大性能；各個(gè)

13、系統(tǒng)也可以根據(jù)自身需要調(diào)節(jié)系統(tǒng)的采樣率，達(dá)到追蹤和性能影響的一個(gè)平衡點(diǎn)。改造后的優(yōu)缺點(diǎn)如下：優(yōu)點(diǎn)a) 異步 Filebeat 進(jìn)程發(fā)送數(shù)據(jù)，減少對業(yè)務(wù)進(jìn)程的影響b) 更好的支持異構(gòu)語言系統(tǒng)c) 探針支持熱變更，更適合線上業(yè)務(wù)系統(tǒng)缺點(diǎn)a) 部署成本和復(fù)雜度提高b) 數(shù)據(jù)計(jì)算會有更大延遲目前當(dāng)當(dāng) APM 系統(tǒng)已經(jīng)上線，在 MAPI、購物車、交易、促銷、TMS、搜索、價(jià)格、廣告等系統(tǒng)上嵌入，進(jìn)行 7*24 小時(shí)全天候監(jiān)控。在雙十一前的幾輪壓測中，通過 web 界面提供了整個(gè)系統(tǒng)的 SLA 指標(biāo)情況，對整體壓測是否通過，提供了簡單直觀的數(shù)據(jù)。再通過查看慢操作的甘特圖，可以快速定位具體的是哪個(gè)調(diào)用步驟比

14、較慢，指導(dǎo)業(yè)務(wù)系統(tǒng)開發(fā)者快速發(fā)現(xiàn)問題所在，解決可能存在的性能瓶頸問題，也給整個(gè)電商平臺性能更好的指導(dǎo)意見。MAPI 服務(wù) MAPI 是當(dāng)當(dāng)移動客戶端所有請求的流量總?cè)肟?。MAPI 需要對客戶端做安全、登錄等移動端校驗(yàn)后，才可以將客戶端真實(shí)的業(yè)務(wù)請求發(fā)送相應(yīng)的后端服務(wù)進(jìn)一步處理；MAPI 同時(shí)負(fù)責(zé)通過緩存機(jī)制減輕后端壓力；MAPI 的另一個(gè)職責(zé)是管理移動客戶端的用戶信息，如：Session、設(shè)備、賬號等，以及移動端的定制化服務(wù)，如：移動 APP 推送消息等。微服務(wù)統(tǒng)一 API 網(wǎng)關(guān) 為了保證對外服務(wù)的安全性，我們在服務(wù)端實(shí)現(xiàn)的大量服務(wù)接口均加入了權(quán)限校驗(yàn)機(jī)制，并且為了防止客戶端在發(fā)起請求時(shí)被篡改

15、，引入了簽名校驗(yàn)機(jī)制。我們遵循微服務(wù)架構(gòu)設(shè)計(jì)理念，將原本處于同一應(yīng)用中的多個(gè)模塊拆分為多個(gè)獨(dú)立應(yīng)用。為保證不同應(yīng)用提供的接口均需保證相同的校驗(yàn)邏輯，我們不得不在每個(gè)應(yīng)用中都實(shí)現(xiàn)同一套校驗(yàn)邏輯。隨著微服務(wù)規(guī)模的擴(kuò)大，校驗(yàn)邏輯愈加冗余，對它們的 BUG 修復(fù)或擴(kuò)展優(yōu)化則必須在每個(gè)應(yīng)用中分別修改。這不僅會引起開發(fā)人員的抱怨，更會加重測試人員的負(fù)擔(dān)。所以，我們需要一套機(jī)制解決此類問題。為此，我們采用了 API 網(wǎng)關(guān)架構(gòu)的解決方案。API 網(wǎng)關(guān)定位為設(shè)計(jì)模式中的 Facade 模式，它作為整個(gè)微服務(wù)架構(gòu)系統(tǒng)的門面，對所有的外部客戶端訪問進(jìn)行調(diào)度和過濾。它不僅具有請求路由、負(fù)載均衡、校驗(yàn)過濾等功能，還有服

16、務(wù)發(fā)現(xiàn)、熔斷、服務(wù)聚合等能力。系統(tǒng)架構(gòu)改造前：系統(tǒng)改造后：服務(wù)治理 服務(wù)降級 在大促期間，為了減少服務(wù)器壓力，會對一些相對消耗服務(wù)器計(jì)算資源，但并非核心流程的服務(wù)進(jìn)行降級?？蛻舳苏埱髸r(shí)，會請求降級服務(wù)，根據(jù)降級的配置來判斷是否需要做相應(yīng)的請求，如：購物車數(shù)量、單品緩存時(shí)間、請求收藏狀態(tài)等。熔斷 在微服務(wù)架構(gòu)中，我們將系統(tǒng)拆分成了很多服務(wù)單元，單元之間通過服務(wù)注冊與訂閱的方式互相依賴。依賴間通過遠(yuǎn)程調(diào)用（如：RPC/Restful API 等）的方式交互，這樣就有可能因?yàn)榫W(wǎng)絡(luò)原因或者依賴服務(wù)自身問題出現(xiàn)調(diào)用延遲或異常，最后就會因等待出現(xiàn)的故障的依賴方響應(yīng)形成請求積壓，最終導(dǎo)致服務(wù)自身的癱瘓。以互

17、聯(lián)網(wǎng)電商為例，系統(tǒng)會拆分為用戶、訂單、庫存、積分、評論等一系列服務(wù)。在用戶下單時(shí)，客戶端將通過 MAPI 接口的調(diào)用，請求訂單服務(wù)的創(chuàng)建訂單接口，訂單服務(wù)則會請求庫存接口。如果庫存或訂單服務(wù)因網(wǎng)絡(luò)延遲等原因造成響應(yīng)超時(shí)，MAPI 接口的線程將被掛起。高并發(fā)場景中會造成掛起線程的大量堆積，導(dǎo)致客戶經(jīng)過漫長等待而下單失敗。過多的客戶下單請求將產(chǎn)生雪崩效應(yīng)，導(dǎo)致服務(wù)不可用，甚至整個(gè)系統(tǒng)癱瘓。當(dāng)當(dāng)采用 Netflix 開源的 Hystrix 作為熔斷方案，以下對 Hystrix 進(jìn)行分析講解。下圖展示了用戶請求正常訪問下的一個(gè)情況：（圖片來源于 GitHub-Hystrix）當(dāng)其中的某一個(gè)系統(tǒng)發(fā)生延遲

18、，并阻塞用戶請求時(shí)，如下圖：（圖片來源于 GitHub-Hystrix）在高并發(fā)的請求的情況下，會造成所有的用戶請求發(fā)生延遲，最終整個(gè)消費(fèi)系統(tǒng)癱瘓而不可用，如下圖：（圖片來源于 GitHub-Hystrix）Hystrix 使用“艙壁模式”實(shí)現(xiàn)線程池的隔離，它會為每一個(gè)依賴服務(wù)創(chuàng)建一個(gè)獨(dú)立的線程池，這樣就算某個(gè)依賴服務(wù)出現(xiàn)延遲過高的情況，也只是對該依賴服務(wù)的調(diào)用產(chǎn)生影響，而不會拖慢其他的依賴服務(wù)。HHVM 提升服務(wù)性能 為了滿足快速的迭代開發(fā)，MAPI 中大部分采用 PHP5.6 來實(shí)現(xiàn)的，其中有一些使用了 Hack 的 IO 異步操作。我們經(jīng)過大量的壓測案例對比，發(fā)現(xiàn) HHVM 更加符合 M

19、API 業(yè)務(wù)，故我們采用 HHVM 虛擬機(jī)。同時(shí)，HHVM 的作者（Facebook 的同事）主動與當(dāng)當(dāng)進(jìn)行技術(shù)交流，更有效地提升了 HHVM 應(yīng)用層性能，使得業(yè)務(wù)高效運(yùn)行。HHVM 類似于 C# 的 CLR 和 Java 的 JVM。HHVM 是在 HPHPc 的基礎(chǔ)上構(gòu)建，它會將 PHP 代碼轉(zhuǎn)換成高級別的字節(jié)碼（一種中間語言），在運(yùn)行時(shí)即時(shí)（JIT）編譯器會將這些字節(jié)碼翻譯成機(jī)器碼，它比 open_cache （Zend 使用的）更穩(wěn)定，更高效。搜索新架構(gòu) 今年雙十一，當(dāng)當(dāng)網(wǎng)上線了搜索新架構(gòu)。平均響應(yīng)時(shí)間降低了一個(gè)數(shù)量級，QPS 提升了一個(gè)數(shù)量級，索引數(shù)據(jù)的實(shí)效性也有了大幅度的改善。可以

20、更加從容的應(yīng)對雙十一的流量，提升用戶的搜索體驗(yàn)。當(dāng)當(dāng)網(wǎng)的搜索引擎是典型的電商搜索引擎，索引量遠(yuǎn)小于互聯(lián)網(wǎng)搜索引擎，不會達(dá)到數(shù)百億，但有很多復(fù)雜的電商搜索邏輯，可以說是術(shù)業(yè)有專功。搜索引擎全部由當(dāng)當(dāng)自主研發(fā)，主要使用 C+ 語言，長期以來，支撐當(dāng)當(dāng)搜索業(yè)務(wù)的同時(shí)，也積累了一些技術(shù)債。為了快速響應(yīng)業(yè)務(wù)需求，導(dǎo)致業(yè)務(wù)邏輯的無序添加，由于缺乏有效的定期梳理，積重難返，搜索效果迭代的效率越來越低。16 年底，技術(shù)部啟動了搜索引擎的重構(gòu)項(xiàng)目。重構(gòu)的技術(shù)路線面臨多種選擇，在人力有限的情況下，是全面轉(zhuǎn)向開源技術(shù)，還是自主研發(fā)，存在爭議。在充分調(diào)研不同技術(shù)路線的風(fēng)險(xiǎn)和收益后，搜索引擎的不同子系統(tǒng)，采用了不同的方

21、式：搜索服務(wù)對性能和穩(wěn)定性有著極高的要求，現(xiàn)有開源框架不足以支撐，并且業(yè)務(wù)的定制能力也是一個(gè)問題，因此依然采用了全部自主研發(fā)的方式；離線系統(tǒng)對性能沒有過高的要求，全面轉(zhuǎn)向了開源技術(shù)，可以更加方便地實(shí)現(xiàn)業(yè)務(wù)邏輯、加快效果迭代的速度。搜索服務(wù)重構(gòu) 搜索服務(wù)在重構(gòu)之前是一個(gè)單機(jī)版的檢索程序，平均響應(yīng)時(shí)間、索引量都存在極限，無法水平擴(kuò)展。重構(gòu)后，采用了分布式架構(gòu)，拆分了搜索節(jié)點(diǎn)、query 分析節(jié)點(diǎn)、index 節(jié)點(diǎn)、摘要節(jié)點(diǎn)。各節(jié)點(diǎn)之間，沒有依賴關(guān)系的運(yùn)算可以并行，大幅度降低了平均響應(yīng)時(shí)間；index 節(jié)點(diǎn)拆分后，索引數(shù)據(jù)可以分層分片，索引量不再受單機(jī)限制。搜索新架構(gòu)沒有沿用舊系統(tǒng)的設(shè)計(jì)和代碼，重新

22、設(shè)計(jì)編寫了從底層倒排索引、索引合并、屬性篩選和匯總，到最終結(jié)果合并、排序的全部代碼。通過代碼的重新編寫全面梳理了業(yè)務(wù)邏輯，嚴(yán)格劃分了搜索框架和業(yè)務(wù)邏輯的代碼邊界。實(shí)現(xiàn)了一個(gè)通用的搜索框架，在這個(gè)框架之上，附加了當(dāng)當(dāng)網(wǎng)的全部搜索業(yè)務(wù)邏輯。搜索框架和業(yè)務(wù)邏輯的剝離，為效果迭代打下了堅(jiān)實(shí)的基礎(chǔ)。搜索服務(wù)重構(gòu)耗費(fèi)了很多時(shí)間，最終取得了明顯的收益，單機(jī)檢索性能有了大幅度的提升：平均響應(yīng)時(shí)間降低了一個(gè)數(shù)量級、QPS 提升了一個(gè)數(shù)量級。分布式架構(gòu)是一個(gè)因素，索引結(jié)構(gòu)、屬性篩選和匯總、排序方式的改變也是另一個(gè)重要因素。索引實(shí)時(shí)更新 電商搜索對于實(shí)時(shí)性有著極高的要求，尤其是雙十一，價(jià)格、庫存的變化需要及時(shí)更新到

23、索引中，商品的上下架、標(biāo)題等促銷信息的修改也需要快速生效，搜索新架構(gòu)充分考慮了這些應(yīng)用場景，做了專門的優(yōu)化。搜索舊系統(tǒng)在索引數(shù)據(jù)的更新上有 2 個(gè)問題：一個(gè)是更新需要加線程鎖，更新的瞬間全部查詢線程暫停；另一個(gè)是采用傳統(tǒng)的全量 + 增量索引，增量會顯著影響 term 的 doc 鏈合并速度，導(dǎo)致索引結(jié)構(gòu)劣化，一個(gè)全量周期內(nèi)，增量商品的數(shù)量不能太多，否則就會導(dǎo)致檢索耗時(shí)過長。搜索新架構(gòu)采用了新設(shè)計(jì)的索引結(jié)構(gòu)，更新不需要加線程鎖，可以在并發(fā)查詢的同時(shí)更新索引數(shù)據(jù)，大幅度提高了更新效率；同時(shí)采用全量 + 實(shí)時(shí)索引，替換了全量 + 增量索引，獨(dú)立的實(shí)時(shí)索引節(jié)點(diǎn)使得索引結(jié)構(gòu)不會劣化，增量商品的數(shù)量不會顯

24、著影響檢索耗時(shí)。新架構(gòu)的實(shí)時(shí)索引常駐內(nèi)存，由于需要動態(tài)增加商品，整體上是鏈?zhǔn)降?，采用跳?+ 數(shù)組加速。這里有一個(gè)平衡，全鏈?zhǔn)酱鎯π矢撸瑳]有內(nèi)存空間浪費(fèi)，缺點(diǎn)也很明顯，由于它是跳躍式的，CPU 的 cache 命中率極低，term 的 doc 鏈合并過程耗時(shí)過長；跳表 + 數(shù)組雖然耗費(fèi)內(nèi)存空間，但會明顯提升檢索效率和 CPU 的 cache 命中率，縮短檢索耗時(shí)。搜索新架構(gòu)的實(shí)時(shí)索引通過參數(shù)調(diào)整內(nèi)存耗用和檢索耗時(shí)，在索引量相同的情況下，對比全量索引，能夠控制在 2 倍的內(nèi)存空間耗用和 4 倍的檢索耗時(shí)。由于實(shí)時(shí)索引的能效比沒有顯著下降，仍在可接受的范圍內(nèi)，對于時(shí)效等級特別高的商品，可以去掉全量，全部用實(shí)時(shí)索引替代，簡化建庫、更新流程。離線系統(tǒng)重構(gòu) 搜索引擎的離線系統(tǒng)，負(fù)責(zé)收集搜索服務(wù)需要的全部數(shù)據(jù)，當(dāng)當(dāng)網(wǎng)搜索引擎的離線系統(tǒng)，需要匯集商品的全部信息：標(biāo)題、描述、價(jià)格、庫存、銷