為什么80%的碼農都做不了架構師？>>> ??

王向維，京東商城三級列表頁架構師。工作期間，完成了京東三級列表頁由Node.js版本到Nginx+Lua版本的變遷，并針對三級列表頁前端即服務器端做了大量的優化工作。

1. 京東三級列表頁

三級列表頁是什么

列表頁是京東商城的三大核心系統之一。京東三級列表頁是用戶選取商品類型后，展示同類商品的頁面，具體如下圖所示。

(點擊放大圖像)

如何進入三級列表頁

用戶在首頁左側的導航樹中（如下圖所示）、全部商品分類列表頁或者頂部面包屑導航中，選擇到商品的最小分類級別后，就可以到達三級列表頁。

(點擊放大圖像)

相關廠商內容

通過探針技術，實現Java應用程序自我防護

新Java，新未來

你離成為一位合格的技術領導者還有多遠？

你了解技術領導與技術管理的差別嗎？

QCon全球軟件開發大會上海站，10月20日-22日，上海·寶華萬豪酒店！

相關贊助商

QCon全球軟件開發大會上海站，2016年10月20日-22日，上海寶華萬豪酒店，精彩內容搶先看！

三級列表頁的作用

該頁面根據用戶選擇的商品類目進行檢索，將結果以列表的形式展現在頁面上。使用戶快速地找到自己需要的產品，提高用戶購買轉化率。

三級列表頁的業務特點

涉及到多維度多因子質量分綜合排序，排序質量的效果直接關系到轉化率，客單價，進而影響到GMV，實質上是數據挖掘和機器學習技術在海量數據上的應用。

在不同三級類目下，通過復雜不確定的查詢條件、屬性區域和列表查詢結果的實時聯動，以及跟區域相關的庫存、京東配送、貨到付款等復雜業務邏輯下，做到高并發實時計算。

2. 優化原因

三級列表頁的頁面周圍依賴的內部系統太多，要做到異步化展示，阻塞可降級。

在持續開發一個核心系統過程中，除了滿足業務需求外，還應該考慮系統未來的架構，追求極致的系統的可用性、高性能和穩定性。這個過程是一個長期積累和重構的過程，京東三級列表頁的優化工作，就是這個過程的一部分。

優化前的狀況

優化前的三級列表頁有以下特點：

• 基于搜索實現；
• 全量數據，搜索結果不理想；
• 接口響應時間長，影響了用戶體驗；
• 沒法針對數據做二次優化；
• 轉化率相對較低；

基于以上原因，需要對三級列表頁做出改變，也就是對老版本進行重構。

重構版本目的

通過優化，希望達到以下目的：

• 非全量數據，線下異步根據數據模型進行進行篩選部分最優數據；
• 要求實時過濾計算，接口響應時間要快，保證用戶體驗；
• 數據進行優化，提高轉換率，提搞GMV；
• 實現前端降級和異步模塊出錯上報

3. 優化原則

每個應用都要滿足自己特定的需求，因為其商業條件、應用場景、用戶期望，以及功能復雜性各不相同。盡管如此，如果應用必須對用戶作出響應，那我們就必須從用戶角度來考慮可感知的處理時間這個常量。事實上，雖然生活節奏越來越快（至少我們感覺如此），但人類的感知和反應時間則一直都沒有變過：

下面這個表格展示了Web性能社區總結的經驗法則：必須在250 ms內渲染頁面，或者至少提供視覺反饋，才能保證用戶不走開。如果想讓人感覺很快，就必須在幾百ms 內響應用戶操作。超過1s，用戶的預期流程就會中斷，心思就會向其他任務轉移，而超過10s，除非你有反饋，否則用戶基本上就會終止任務！

(點擊放大圖像)

此次的優化工作遵循以下四個原則：

• 首屏優先：精簡和瘦身頁面，首屏優先展示出來；
• 惰性交互：需用戶交互的部分惰性加載；
• 惰性執行：能不執行的先別執行，惰性執行；
• 惰性滾屏：滾屏惰性加載。

遵循這四個原則，進行了優化工作。

4. 主要優化工作

（1）首屏優先

為了保證首屏優先展示，HTML文檔進行了適當精簡。

目的：盡快渲染出頁面并達到可交互的狀態。

方法：

• 如果非必須，盡量只生成首屏需要的HTML數據。
• 優先獲取資源、提前解析。如首屏需要的CSS和JS；如果不考慮維護成本，可以把首屏需要的CSS和JS放到文檔中。
• 發現和優先安排關鍵網絡資源，盡早分派請求并取得頁面。
• 文檔精簡后，服務端生成程序耗時短，性能才會好。

如下圖所示，列表頁的頭、面包屑、品牌區、屬性篩選區、60個商品主圖數據，這些是服務端模板渲染輸出；而剩余部分是在前端JS惰性加載或生成。

(點擊放大圖像)

（2）惰性交互

惰性交互，即對需用戶交互的部分進行惰性加載。

對于三級列表頁品牌區，服務端只渲染18個品牌，用戶在點更多時，AJAX異步加載其他的。對于整個屬性是篩選區服務端只渲染5行，其他行用戶在點更多時，JS從文檔嵌入資源中取到數據，并渲染成HTML。這樣做可以保證服務端計算量少，提升服務端性能，減少數據傳輸。

如下圖，點“更多”時才加載更多的品牌，因為有些三級類目有非常多品牌，如果不采用這種方式，整個頁面渲染非常慢。

(點擊放大圖像)

因為需要SEO的原因，京東三級列表頁不能使用BigPipe等技術來進行更優的處理。

（3）惰性執行

能不執行的先別執行，惰性執行。

上圖是三級列表頁最重要的商品區（商品主圖+N個關聯商品小圖），每個商品的區域都是完全一樣的；如果在服務端拼裝整個商品區域的話，尤其涉及到小圖部分，會有非常多的重復HTML元素。

(點擊放大圖像)

我們把體驗和減少頁面內容進行了折中處理：服務端渲染輸出商品主圖部分；小圖部分通過Json數據嵌入到頁面，然后通過JS惰性執行渲染。這樣可以很好地對頁面進行瘦身。而且小圖資源是頁面嵌入的，非異步加載；沒有網絡請求。因此，用戶基本感知不到異步帶來的渲染閃動問題。

下圖就是頁面嵌入的小圖Json數據。

(點擊放大圖像)

（4）惰性滾屏

三級列表頁的60個商品區域的圖片和頁尾都是當用戶向下滾動頁面時，才去加載當前屏幕中的圖片和模塊。這樣可以節省服務器帶寬和壓力，提升頁面整體渲染時間。

5. 細節優化工作

在實際優化過程中，還涉及到非常多的優化細節。

將一些JS/CSS資源直接嵌入頁面

把資源嵌入文檔可以減少請求的次數。比如頁面需要的JS、CSS數據。如下圖所示:

(點擊放大圖像)

上圖中的這些JS對象，是后端渲染輸出的，因此不適合放入單獨的JS文件，直接在頁面中嵌入輸出會更好些。slaveWareList是小圖的列表對象。如果放在服務端模板渲染輸出的話，首先需要進行一些循環拼裝頁面；另外會使頁面體積變得非常大。

權衡之后決定放到前端JS渲染輸出。這樣也帶來了一些好處：

• 減輕服務端壓力，提升渲染模板性能和減少服務端執行時間；
• 服務端不用生成HTML，文檔減少上百個div，減少頁面大小和網絡開銷；
• 提前放到文檔中，不用異步調用；
• 用戶基本感知不到渲染過程。

對引入的資源排定優先次序

根據自己系統的業務，對每種資源定優先級：對必需的資源優先加載，而低優先級的請求保存在隊列中延時加載或等待必需資源加載完再加載；如：搜索推薦熱詞、頂部三個熱賣商品接口、60個主商品的圖片、價格優先加載。而對于庫存、促銷信息、廣告詞、預售商品、店鋪信息等，延后加載。對于點擊流，廣告統計數據則延時兩秒再加載。

應用JS緩存來存儲公有屬性和商品信息屬性

三級列表頁中的每個商品都是一個對象，存放在一個Map中，通過AJAX接口異步填充和維護商品的屬性。用于后續用戶交互用。同時維護成本也會降低；即頁面中用到的每個商品數據放入一個map中，如果沒有則異步加載；如果有直接使用；即這些數據是公共數據。

(點擊放大圖像)

AJAX接口最優調用

頁面往往依賴很多的異步接口，因此要對異步接口進行壓測，找出接口的最優調用方式。如京東三級列表頁依賴價格、庫存、廣告詞、店鋪信息等異步調用接口。而頁面有時候會出現多達300多個商品，如果用一個get請求把這些sku做參數，性能非常慢，那么就要采用分組分批調用。如頁面商品在300個時，價格接口分六組，第一組30個，第二組30個，第三組60個，第四組60個，第五組100個，第六組100個。

DNS預解析

對可能的域名進行提前解析，避免將來HTTP請求時的DNS延遲。如對價格、庫存、圖片、單品頁等服務預解析。

(點擊放大圖像)

>

減少HTTP重定向

HTTP 重定向極費時間，特別是不同域名之間的重定向，更加費時；這里面既有額外的DNS 查詢、TCP 握手，還有其他延遲。最佳的重定向次數為零。比如三級列表頁以前是http://list.jd.com/9987-653-655.html，而現在是http://list.jd.com/list.html?cat=9987,653,655；在過渡期間可以重定向，但是過渡完成后就沒必要重定向了。

使用CDN（內容分發網絡）

把數據放到離用戶地理位置更近的地方，可以顯著減少每次TCP連接的網絡延遲，增大吞吐量。比如京東三級列表頁、商品詳情頁、公共JS、CSS。

傳輸壓縮過的內容（Gzip壓縮）

傳輸前應該壓縮應用資源，把要傳輸的字節減至最少：確保對每種要傳輸的資源采用最好的壓縮手段。所有文本資源都應該使用Gzip壓縮，然后再在客戶端與服務端間傳輸。一般來說，Gzip可以減少60%~80%的文件大小，也是一個相對簡單（只要在服務器上配置一個選項），但優化效果較好的舉措。(對于壓縮級別，經過不同服務器多次壓測，建議Nginx設置為1-4)

去掉不必要的資源

任何請求都不如沒有請求快，把一些非必須的或者可異步的，或者可延遲的盡量延遲請求。

在客戶端緩存資源

應該緩存應用資源，從而避免每次請求都發送相同的內容。

對靜態資源CSS/JS或變化不頻繁的HTML塊，可以放到前端localstorage。因為每次都傳輸一些不變的靜態文件或者HTML，實在是太浪費了。

無狀態域名

Cookie 在很多應用中都是常見的性能瓶頸，很多開發者都會忽略它給每次請求增加的額外負擔；減少請求的HTTP首部數據（比如HTTP cookie），節省的時間相當于幾次往返的延遲時間。如列表頁依賴的價格、庫存接口，采用3.cn無狀態域名，從而減少主域下cookie傳輸。

并行處理請求和響應

請求和響應的排隊都會導致延遲，無論是客戶端還是服務器端。這一點經常被忽視，但卻會無謂地導致很長延遲。

域名分區

當頁面中非常多請求都是一個域名下資源時，由于瀏覽器同時只能打開6個連接池，而且每個鏈接池是對不同域名起作用，所以很多請求一個域名會出現排隊現象。如果把這些請求域名分區，讓請求并行，從而加快資源下載。如：頁面需要下載上百張圖片，對圖片進行域名分區調用。京東大部分頁面都對圖片進行了域名分區調用：

• http://img10.360buyimg.com/
• http://img11.360buyimg.com/
• http://img12.360buyimg.com/
• http://img13.360buyimg.com/
• http://img14.360buyimg.com/

拼合和連接

合并鏈接：把多個JavaScript 或CSS 文件組合為一個文件。

拼合：把多張圖片組合為一個更大的復合的圖片（CSS Sprites）。

服務端寫相關信息到header

把服務器IP后兩位寫到header，如果有問題，方便定位哪臺服務器。ups：后端路由的所有服務器都取到。把緩存命中信息或異常走兜底了，把后端運行狀態寫到header。Head-status:命中、未命中、異常等狀態。

(點擊放大圖像)

5. 降級方案和異步模塊出錯上報功能的實現

降級方案

• 主動降級

頁面依賴很多AJAX異步接口服務，難免保證這些服務從不出錯。所以在調用這些接口服務時都提前判斷該接口開關是否開啟，如果開關關閉則不調用該接口服務。頁面不展示相關模塊。保證在一個接口服務出問題時，我們可以快速降級。

• 被動降級

當某個異步接口服務返回非200狀態碼、請求超時、數據格式不正確等異常，就會被動隱藏或不展示相應模塊。最上面三個熱賣商品依賴的廣告服務出問題時，會把每個三級分類對應的三個兜底商品展示出來，防止開天窗。對于其他模塊因為是商品的屬性，暫時做隱藏處理。

上報模塊錯誤

當頁面被動降級了，js就會上報該模塊，后臺程序記錄并報警。同時也會上報js運行中出錯的信息。記錄什么瀏覽器，哪個版本，什么錯誤。我們會對這些問題驗證和修改。保證每個用戶都能訪問。

Web性能監控

為什么要做Web性能監控，因為頁面可能放在CDN，前端JS執行很多業務邏輯不知道運行情況，整個鏈路網絡偶爾不穩定、頁面依賴的模塊和第三方異步服務多人工難以實時監控等，這些情況請求還沒有到后端就可能出問題，所以后端監控無能為力。

前端監控分兩個方向：用WebKit內核模擬瀏覽器，定時抓取設定的頁面；前端JS植入監控。

• 用WebKit內核模擬瀏覽器，定時抓取設定的頁面

該Web監控項目采用一個中心服務，多個終端服務來完成大量頁面抓取和校驗。

部署到全國各個機房，實時監控頁面是否打開正常（請求超時、返回非200）、頁面HTML關鍵元素是否丟失，頁面是否出現亂碼等。

每個終端定時向中心服務請求需要處理的頁面URL和該頁面需要驗證的規則。如果驗證不通過，則記錄下來并報警。同時會保存現場（HTML文檔、頁面截圖）。

該項目在這次618起到很重要的作用，頁面出現任何問題，都會提前檢測出來。

• 前端JS植入監控

該JS統計頁面白屏時間、首屏加載時間、每個AJAX異步方法調用耗時和請求狀態碼。
同時也會上報異步模塊降級了，JS運行中錯誤信息等。

埋點統計

京東列表頁的埋點主要是來統計用戶點擊當前頁面位置記數，幫助廣告系統、業務、產品經理后續的工作。

埋點數據上報，就是通過onclick發送AJAX請求到后端服務。

其中對于點擊后刷新當前頁面的情況，需要在新頁面記錄上次點擊的位置。因為在當前頁面點擊后上報AJAX方法還沒執行就關閉當前窗口加載點擊后的URL了。

下圖是點擊流插件的統計，數據敏感不做展示，大家只看功能。

(點擊放大圖像)

6. 總結

用時

此次重構的時間段為：2014年12月到2015年4月。

效果

京東三級列表頁從優化到上線，已經經歷了兩個618和一個雙11的考驗，每天有上億的訪問量，頁面打開時間在20~80毫秒（在某些地區或低帶寬下會大于100ms）。

(點擊放大圖像)

后端方法調用tp99的性能數據如下圖所示。

(點擊放大圖像)

心得

列表頁從開始200+ms到現在100ms內，QPS單臺機器幾百到現在的近萬，頁面從1MB到現在200KB內，包擴后臺系統的拆分，邏輯算法后移、后臺實時計算等優化。是需要有匠人的精神精雕細琢。

列表頁每周都會根據業務方和產品經理的需求在開發功能。對于每個功能點都要深入思考，列出多種方案，最終選擇一個簡單、易維護、不影響系統性能、不降低用戶體驗的方案。這個過程要不斷思考、或請教有這方面經驗的人、包括參考外部公司的方案。有趣的是可能晚上突發奇想就有更好的方案。

中間也遇到無數的坑。對于每次遇到各種問題，必須想方案避免再次出現。同時要分析Nginx日志，分析每個請求，進而對爬蟲、惡意參數訪問、惡意請求做相應處理。這些都是前端服務必做的。當然后端服務也是非常重要的，后續會有列表頁量身打造的緩存（加速、抗大流量、多樣化兜底基礎數據）、服務端架構、自動降級、架構高可用等方案。

轉載于:https://my.oschina.net/fdhay/blog/729346

總結

以上是生活随笔為你收集整理的京东前端：三级列表页持续架构优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。