[[176929]]

承接上篇《京東三級(jí)列表頁持續(xù)架構(gòu)優(yōu)化—前端優(yōu)化實(shí)踐》。

分類列表入口

分類列表入口，可以通過京東首頁首屏左側(cè)導(dǎo)航進(jìn)入，是用戶購買商品的幾大入口之一。

分類列表，展示各個(gè)分類的商品，有綜合排序、價(jià)格排序、銷量排序、上架時(shí)間排序、圖書還有出版時(shí)間排序?？梢园凑掌放?、價(jià)格和各種擴(kuò)展屬性篩選出想要的商品。下圖以空調(diào)列表為例。

分類列表特點(diǎn)

• 分類多，全站大概幾千個(gè)分類;
• 商品多，每個(gè)分類商品多，有的分類達(dá)上千萬的商品;
• 需求多樣化，不同分類需求不一樣，例如大家電、圖書需求各不一樣;
• 請求量大，實(shí)時(shí)性要求高。

舊架構(gòu)

舊架構(gòu)，前端是用nodejs做模板渲染，后端服務(wù)是調(diào)用搜索接口。舊架構(gòu)缺點(diǎn)：

• 響應(yīng)時(shí)間比較長;
• 因?yàn)槭撬阉鞣祷氐臄?shù)據(jù)，數(shù)據(jù)二次加工不方便。

升級(jí)新架構(gòu)

* 新架構(gòu)設(shè)計(jì)目標(biāo)

• 分布式，數(shù)據(jù)可以做多個(gè)分片，服務(wù)各層可以做到水平擴(kuò)容;
• 高可用，雙機(jī)房雙活部署;
• 響應(yīng)迅速;
• 數(shù)據(jù)閉環(huán)，線上服務(wù)主要數(shù)據(jù)不依賴于外部API;
• 運(yùn)維便捷，方便切換集群，方便分類管理配置;
• 數(shù)據(jù)提升，通過優(yōu)化排序算法，提升GMV、訂單轉(zhuǎn)化率、客單價(jià)等。

* 新架構(gòu)

新架構(gòu)功能模塊如上圖所示：

• 頁面渲染：采用OpenResty(Nginx+Lua)來作模板渲染，方便頁面邏輯的調(diào)整;
• 業(yè)務(wù)處理：采用golang，所有的篩選、過濾邏輯都是在這一層處理的;
• 數(shù)據(jù)異構(gòu)：頁面渲染需要相關(guān)的數(shù)據(jù)、過濾篩選需要的數(shù)據(jù)，都是通過異構(gòu)過來的;
• 消息處理：通過接入MQ消息，可以實(shí)時(shí)處理商品上下架、庫存更新、價(jià)格修改等消息;
• 質(zhì)量分計(jì)算：通過大數(shù)據(jù)平臺(tái)計(jì)算商品質(zhì)量分，為綜合排序提供依據(jù);
• 配置管理中心：負(fù)責(zé)后臺(tái)調(diào)度、分類配置等。

新架構(gòu)線上流程如下圖所示

新架構(gòu)離線數(shù)據(jù)流如下圖所示

其中：

• 數(shù)據(jù)集市，使用的是京東的大數(shù)據(jù)平臺(tái);
• JSS，是京東自研分布式文件存儲(chǔ)系統(tǒng);
• JIMDB，是京東自研KV存儲(chǔ)系統(tǒng)，可當(dāng)分布式Redis使用。

詳解各個(gè)模塊

* 質(zhì)量分計(jì)算

由于每個(gè)分類的商品非常多，個(gè)別分類達(dá)千萬量級(jí)的SKU，而用戶瀏覽的SKU有限，我們需要將用戶最可能買商品排在前面;為每個(gè)分類的所有sku進(jìn)行質(zhì)量分計(jì)算，涉及到幾十個(gè)指標(biāo)(包括銷量、評(píng)價(jià)、瀏覽、轉(zhuǎn)化率等);根據(jù)質(zhì)量分的高低進(jìn)行排序;由于涉及數(shù)據(jù)量很大，所有計(jì)算都在大數(shù)據(jù)平臺(tái)完成;將計(jì)算結(jié)果推送到JSS。

由于還有一些特殊規(guī)則，例如品牌穿插、店鋪穿插、特殊排序等，這些規(guī)則的實(shí)現(xiàn)是通過worker實(shí)現(xiàn)，讀取jss，并進(jìn)行特殊規(guī)則處理。將處理后的數(shù)據(jù)推送到MYSQL。

* 異構(gòu)服務(wù)

異構(gòu)服務(wù)主要是異構(gòu)過濾和展示需要的商品數(shù)據(jù);調(diào)用外部各個(gè)接口，形成一張商品寬表。如下圖所示：

* 業(yè)務(wù)處理子系統(tǒng)

上圖展示了列表各種篩選邏輯，排序邏輯。

業(yè)務(wù)處理子系統(tǒng)提供前端所需要的所有過濾篩選接口，以及展示數(shù)據(jù)。該系統(tǒng)采用golang開發(fā)，所有篩選數(shù)據(jù)都存在內(nèi)存中，提高檢索速度;展示的數(shù)據(jù)都放在jimdb中，目的減少占用內(nèi)存大小，縮短golang的GC時(shí)間。下圖展示了內(nèi)存中存儲(chǔ)的數(shù)據(jù)。

* 消息處理系統(tǒng)

該系統(tǒng)接收處理相關(guān)消息(商品變更，上下架，價(jià)格變更，庫存變更)，并實(shí)時(shí)更新到線上，如下圖所示：

* 頁面展示子系統(tǒng)

頁面展示子系統(tǒng)，采用Nginx+Lua實(shí)現(xiàn)，負(fù)責(zé)模板的渲染，如下圖所示。

為了提高頁面的渲染速度，有一部分頁面采用異步渲染，例如：頁面小圖聚合的可以讓js渲染小圖;超過5個(gè)的擴(kuò)展屬性，讓js異步渲染。頁面需要的價(jià)格數(shù)據(jù)、庫存數(shù)據(jù)、廣告數(shù)據(jù)，采用異步加載;保證這些數(shù)據(jù)的實(shí)時(shí)性。

頁面渲染優(yōu)化：

• HTML文檔精簡，越簡單渲染越快，性能越好;例如：頁面小圖聚合的可以讓js渲染小圖;超過5個(gè)的擴(kuò)展屬性，讓js 異步渲染;
• 懶加載數(shù)據(jù)，例如：滾屏加載圖片和頁尾;
• 資源加載排序，對(duì)每種資源定優(yōu)先級(jí)，對(duì)必需的資源優(yōu)先加載，而低優(yōu)先級(jí)的請求保存在隊(duì)列中延時(shí)加載或等必需資源加載完再加載。例如：搜索推薦熱詞、頂部三個(gè)熱賣商品接口、價(jià)格優(yōu)先加載。對(duì)于庫存、促銷信息、廣告詞、預(yù)售商品、店鋪信息等，延后加載; 對(duì)于點(diǎn)擊流，廣告統(tǒng)計(jì)數(shù)據(jù)則延時(shí)兩秒再加載;
• 頁面更多優(yōu)化參考：《京東三級(jí)列表頁持續(xù)架構(gòu)優(yōu)化—前端優(yōu)化實(shí)踐》。

Golang+Lua(OpenResty)的應(yīng)用

* Golang–遇到的坑

• JSON的序列化性能低下：Golang內(nèi)置的encoding/json、encoding/gob，采用ffjson;
• GC問題：減少內(nèi)存對(duì)象。減少對(duì)象申請，兩個(gè)作用：減少內(nèi)存使用，減少內(nèi)存碎片;
• 字符串拼接：盡量使用byte數(shù)組，不要用String，由于String會(huì)創(chuàng)建新對(duì)象;
• Go占用OS內(nèi)存釋放慢：執(zhí)行：debug.freeOSMemory();
• Goroutine閃退：goroutine閃退，導(dǎo)致應(yīng)用進(jìn)程閃退，異常捕獲;
• 并發(fā)處理map：必須加讀寫鎖(sync.RWMutex)。

* 選擇Lua(OpenResty)

• Lua：輕量級(jí)、協(xié)程、嵌入式、開發(fā)效率高;
• OpenResty：OpenResty將Nginx核心、LuaJIT、許多有用的Lua庫和Nginx第三方模塊打包在一起的web應(yīng)用開發(fā)框架。

** 模板渲染

使用的模板引擎https://github.com/bungle/lua-resty-template。Nginx配置如下所示。

模板如下所示。

** 緩存

緩存：

• 為后端服務(wù)異常提供托底數(shù)據(jù);
• 當(dāng)流量太大時(shí)，可以開啟緩存，減少后端服務(wù)壓力。
• 緩存流程：
• 解析url，對(duì)url做hash，得到相應(yīng)的key，從后端服務(wù)獲取數(shù)據(jù)，如果數(shù)據(jù)完整，則渲染模版，將對(duì)應(yīng)的數(shù)據(jù)放入對(duì)應(yīng)的緩存，并將key放入keycache，并設(shè)置緩存時(shí)間;
• 頁面緩存是永不過期的，當(dāng)key過期時(shí)，主動(dòng)替換掉;
• 為什么分為兩類緩存：firstpage cache只緩存每個(gè)分類首頁的數(shù)據(jù)，這樣可以緩存全部分類的首頁，保證所有分類都有托底數(shù)據(jù)。Otherpage cache 緩存除首頁以外頁面，這樣保證熱點(diǎn)數(shù)據(jù)都在緩存中。如果超過容量，通過lru淘汰;
• 為什么每類緩存多個(gè)分片：因?yàn)閘ua_shared_dict存在自旋鎖，單片讀寫壓力大時(shí)，會(huì)有一定的瓶頸，因此采用多個(gè)分片，每個(gè)分片大小設(shè)置，根據(jù)具體緩存數(shù)據(jù)來定;
• Firstpage和otherpage 是緩存在每臺(tái)nginx服務(wù)器上，緩存的內(nèi)容有限;
• Redis緩存，可以集中緩存，能夠緩存更多的數(shù)據(jù);

** 異常處理

異常處理分為兩層托底，保證每層報(bào)錯(cuò)，均可對(duì)異常進(jìn)行處理，無5xx等錯(cuò)誤，提高用戶體驗(yàn)，第一層托底，展示各個(gè)分類首頁的緩存;第二層托底，跳轉(zhuǎn)京東首頁。

Lua執(zhí)行問題，通過nginx配置error_page，進(jìn)入異常處理。接口響應(yīng)問題，通過ngx.exec內(nèi)部跳轉(zhuǎn)，進(jìn)入異常處理。

注：error_page默認(rèn)只匹配一次，匹配多次需配置recursive_error_pageson;

ngx.exec為內(nèi)部跳轉(zhuǎn)，類似于流水線，數(shù)據(jù)流動(dòng)方向單一，無額外http請求。

新版性能

* 頁面渲染性能

頁面響應(yīng)時(shí)間：模板渲染+業(yè)務(wù)篩選接口(go)，平均在30ms左右，tp99在80ms以內(nèi)，提高6倍以上;頁面渲染(NGINX+LUA)TPS，在并發(fā)100時(shí)，16核單機(jī)在3500筆/秒，提高10倍左右。

* 業(yè)務(wù)篩選接口(GO)性能

業(yè)務(wù)篩選接口(GO)：平均在10ms以內(nèi)，tp99在50ms左右，響應(yīng)時(shí)間提高6倍以上。

作者：謝剛，京東商城架構(gòu)師，負(fù)責(zé)京東分類列表、鳳凰等系統(tǒng)的架構(gòu)開發(fā)工作;之前在搜狐視頻負(fù)責(zé)UGC視頻架構(gòu)開發(fā)工作。

【本文來自51CTO專欄作者張開濤的微信公眾號(hào)(開濤的博客)，公眾號(hào)id: kaitao-1234567】