京東零售系統(tǒng)在2018年實現(xiàn)前中臺架構(gòu)的調(diào)整與劃分。中臺實現(xiàn)基礎(chǔ)服務(wù)組件開發(fā)，前臺主要對接用戶請求，通過對中臺RPC數(shù)據(jù)的聚合，來滿足用戶多樣化需求。其前臺系統(tǒng)又分為首頁系統(tǒng)、單品系統(tǒng)、搜索系統(tǒng)、列表系統(tǒng)、訂單系統(tǒng)等等。

作為PC首頁研發(fā)，本文主要講解PC首頁的技術(shù)實現(xiàn)。

PC首頁業(yè)務(wù)邏輯從最初的模板渲染，到后來的SSI模塊加載以及現(xiàn)在的前后端分離。開發(fā)語言也從之前的ASP、PHP逐步過渡到以LUA為主的技術(shù)框架。通過技術(shù)迭代升級，首頁頁面打開速度從之前的200ms縮減到30ms內(nèi)，API性能從之前的500ms優(yōu)化至100ms左右。

京東零售系統(tǒng)，每天承載著億萬網(wǎng)民的購物需求。PC首頁又是京東商城的一級入口，所以系統(tǒng)必須達到以下3方面要求：頁面完整性(容災(zāi)、兜底、降級)；流暢的加載速度(高并發(fā)、頁面加載優(yōu)化、API加載優(yōu)化)；監(jiān)控&告警。

下面將根據(jù)系統(tǒng)設(shè)定目標(biāo)逐步講解首頁系統(tǒng)實現(xiàn)方案。

1.頁面完整性

頁面完整性指任何時候訪問頁面均需呈現(xiàn)正常的頁面樣式，不得出現(xiàn)天窗以及非200狀態(tài)碼(40x、50x等)。如下圖樓層，若將單模塊缺失直接呈現(xiàn)給用戶，將導(dǎo)致頁面天窗，影響體驗。在單模塊異常時，系統(tǒng)可對整樓層隱藏操作，優(yōu)先保證頁面完整顯示。

下面從6方面講解容災(zāi)降級的業(yè)務(wù)邏輯：

頁面的容災(zāi)：前端頁面主要承載頁面骨架，也會包含部分開關(guān)配置及必要的兜底數(shù)據(jù)，即使后端API服務(wù)異常，html依然可以提供基礎(chǔ)的用戶體驗。前端頁面由模板渲染生成，其中模板變量通過配置中心（蜂巢系統(tǒng)）維護，定時worker觸發(fā)生成前端頁面，然后推送到靜態(tài)資源服務(wù)器，最終通過CDN加速提供服務(wù)。其中在worker觸發(fā)生成html階段執(zhí)行多層驗證邏輯，保證html的完整性。

接口的容災(zāi)：一般接口邏輯均是優(yōu)先讀取緩存數(shù)據(jù)，若緩存失效則繼續(xù)讀取上游RPC數(shù)據(jù)來輸出。但上游系統(tǒng)均不保證100%可用，如何保證在上游異常的情況下提供可靠服務(wù)使頁面正常渲染呢？PC首頁系統(tǒng)在接口層面做了2方面工作：

第一、接口在讀取&聚合上游RPC數(shù)據(jù)后會保存兩部分緩存，一個為正常用戶加速緩存，一般會設(shè)置5min過期時間，一個是兜底緩存，永不過期。當(dāng)緩存或者上游RPC服務(wù)均不可用時，接口會讀取兜底緩存保證正常的數(shù)據(jù)輸出。

第二、如果API服務(wù)由于自身問題（例如宿主機異常、Redis服務(wù)異常、用戶網(wǎng)絡(luò)抖動等）導(dǎo)致無法提供正常的服務(wù)怎么辦。為了避免這個問題，系統(tǒng)為API提供了一條新的訪問途徑-CDN API。CDN API會訪問由Worker定時生成的靜態(tài)結(jié)果集（File）輸出數(shù)據(jù)。當(dāng)前端異步加載數(shù)據(jù)感知常規(guī)線路異常后自動觸發(fā)CDN API線路來保證接口可用性。

依據(jù)上面2種兜底邏輯，繪制如下流程圖，此邏輯將首頁API服務(wù)的可靠率提高至100%。

接口的降級：如下圖所示，正常情況接口通過讀取Cache、RPC數(shù)據(jù)、兜底Cache提供服務(wù)。但如果Cache和RPC服務(wù)均異常，接口的響應(yīng)時間就大大浪費在前兩階段（10ms+100ms）。為了避免此情況的發(fā)生，系統(tǒng)通過配置中心（蜂巢系統(tǒng)）設(shè)置降級開關(guān)，當(dāng)系統(tǒng)感知降級開關(guān)打開時，將直接讀取兜底Cache，保證API的響應(yīng)速度。

NGINX的容災(zāi)：NGINX容災(zāi)指系統(tǒng)監(jiān)控到接口非200狀態(tài)碼的時候在NGINX層面執(zhí)行兜底邏輯，此兜底邏輯可以讀?。ɑ虼恚┻h程靜態(tài)資源實現(xiàn)透明容災(zāi)。具體實現(xiàn)通過error_page指令完成，error_page指令可以在特定的狀態(tài)碼設(shè)置一個named location，并在其代碼塊中執(zhí)行相應(yīng)的兜底業(yè)務(wù)邏輯。樣例配置如下：

樓層容災(zāi)：在多模塊樓層，前端會調(diào)用多個API進行頁面渲染。如下圖所示，此樓層一共包含4個模塊，每個模塊均提供獨立的API接口。當(dāng)其中一個模塊API異常，即觸發(fā)樓層隱藏動作，避免天窗的出現(xiàn)。（這里執(zhí)行的是頁面可以有損但必須完整的策略）

終極容災(zāi)（頁面CDN兜底）：在2016年，啟動“永不消失的首頁”項目，即不論情況如何極端（包括Redis服務(wù)異常、服務(wù)器異常、RPC異常、網(wǎng)絡(luò)異常等等），系統(tǒng)均可快速響應(yīng)并切換至歷史頁面來保證頁面完整。

為實現(xiàn)歷史快照，項目借鑒爬蟲技術(shù)，定時抓取PC首頁的完整數(shù)據(jù)，并將快照數(shù)據(jù)推送至靜態(tài)服務(wù)器。當(dāng)監(jiān)控到系統(tǒng)異常時開啟降級開關(guān)將頁面及時回滾至特定歷史版本。此降級繞開正常的服務(wù)流程，直接讀取兜底的靜態(tài)資源。具體流程如下：

（此項目自上線后尚未觸發(fā)一次。在其他的業(yè)務(wù)場景中，需要考慮各自實際情況）

2.流暢的加載速度

既要保證頁面完整性，也要保證頁面以及API的加載速度。下面從性能方面講解系統(tǒng)的優(yōu)化方向。

技術(shù)選型

首頁是一種重性能、輕邏輯的業(yè)務(wù)場景，沒有過多的基礎(chǔ)服務(wù)依賴，主要與Redis和上游RPC做交互。系統(tǒng)通過讀取上游RPC數(shù)據(jù)后聚合、過濾、驗證后輸出，最終完成頁面展示。用戶請求簡化流程圖如下：

結(jié)合業(yè)務(wù)場景，京東首頁在2015年開始調(diào)研并嘗試使用OpenResty服務(wù)，基于NGINX的異步事件模型以及高性能的腳本語言LUA，OpenResty完美勝任京東首頁的高并發(fā)場景。經(jīng)過近幾年的沉淀，OpenResty成為京東首頁的基礎(chǔ)架構(gòu)，也以此沉淀了OpenLua開發(fā)框架。

如上圖所示，OpenResty(Nginx)服務(wù)的請求處理擁有11個階段之多，每個階段都有其特定的業(yè)務(wù)場景。在init_by_lua*階段，框架初始化環(huán)境變量、init_worker_by_lua*階段初始化降級開關(guān)以及基礎(chǔ)配置，并將其同步至共享cache(ngx.shared.DICT)、 init_write_by_lua*階段初始化路由策略、access_by_lua*階段實現(xiàn)訪問權(quán)限驗證，加解密等、content_by_lua*階段實現(xiàn)主體業(yè)務(wù)邏輯、log_by_lua*階段實現(xiàn)日志以及Ump信息的輸出。

Redis HotKey（熱key）優(yōu)化：在多數(shù)的業(yè)務(wù)場景中都使用Redis集群為服務(wù)加速，通過集群的橫向擴展能力增加系統(tǒng)吞吐率。但在特殊的業(yè)務(wù)場景會有熱點數(shù)據(jù)的出現(xiàn)，導(dǎo)致流量傾斜，增加單個分片的壓力，這樣就極大制約API的效率，極端情況甚至可以拖垮Redis集群。如何避免熱點數(shù)據(jù)有2種方案：1、通過復(fù)制熱點數(shù)據(jù)將數(shù)據(jù)存放到不同的Redis分片，每次通過隨機算法讀??；2、熱點數(shù)據(jù)前置、減少Redis的壓力。由于第一種方案實現(xiàn)繁瑣，系統(tǒng)使用第二種方案解決熱點數(shù)據(jù)，也就是將發(fā)現(xiàn)的熱點數(shù)據(jù)存儲到本地cache中(ngx.shard.DICT),通過本地cache服務(wù)直接對外提供服務(wù)，由于ngx.shard.DICT效率極高，極大優(yōu)化API的響應(yīng)時間。

Redis BigKey優(yōu)化：項目開發(fā)中BigKey是不可忽略的性能點，可能在前期開發(fā)以及壓測時均可以完美達到設(shè)定值，但是線上環(huán)境效率不理想，這時候就要考慮bigkey的因素了。由于bigkey占用內(nèi)存較多，不但會使網(wǎng)卡成為瓶頸，在set、get也會阻塞其他操作，直接導(dǎo)致Redis吞吐量下降。

在PC首頁系統(tǒng)bigkey的定義范圍為>5k,只要key的值大于5k均需要單獨處理。處理方案依然是2種。1、業(yè)務(wù)上做切割。例如一個業(yè)務(wù)場景需要將一個大的商品列表放到Cache中， 一般做法是通過kv（set key value）保存到Redis中。這時業(yè)務(wù)優(yōu)化方案是將一個key擴展到1+n個key，一個key存儲id list，其余n個key存儲id對應(yīng)的詳情信息，這樣就將bigkey打散為多個key。2、技術(shù)上做切割。例如系統(tǒng)定義的bigkey為5k，通過算法將value以5k的界限做切割，然后系統(tǒng)存儲一個關(guān)系key以及n個小key實現(xiàn)bigkey轉(zhuǎn)小key的過程。

不管使用哪個方案，目標(biāo)是一致的，避免bigkey的出現(xiàn)。在將bigkey轉(zhuǎn)小key的過程中，合理使用管道技術(shù)減少redis的網(wǎng)路消耗。

分布式任務(wù)的使用：隨著個性化推薦算法的推廣，商城首頁全面接入推薦算法。由于個性化算法基于實時計算，耗時較高，為了保證用戶瀏覽的流暢度，系統(tǒng)引入分布式服務(wù)。如下圖所示，用戶在請求第一屏的時候?qū)⒂脩粜畔ush到分布式任務(wù)系統(tǒng)，分布式任務(wù)利用時間差計算下面樓層的個性化數(shù)據(jù)并存儲到Redis。當(dāng)用戶訪問到特定樓層即可快速加載數(shù)據(jù)。

并發(fā)請求：每個API都會涉及多個上游RPC服務(wù)，為了避免串行請求帶來的耗時累加，系統(tǒng)將每個上游RPC封裝成單個子API服務(wù)，然后通過ngx.location.capture_multi命令實現(xiàn)并發(fā)請求來優(yōu)化API耗時。

磁盤IO優(yōu)化：為了減少磁盤io，系統(tǒng)日志模塊使用批量寫入策略來減少磁盤io的消耗。在OpenResty中每個請求（包含自請求）都會初始化一個 ngx.ctx全局表，首頁應(yīng)用將當(dāng)前請求在不同階段產(chǎn)生的日志內(nèi)容統(tǒng)一寫入ngx.ctx.Log表中，并在log_by_lua*階段統(tǒng)一觸發(fā)io操作將日志寫入文件系統(tǒng)。

圖片優(yōu)化：電商系統(tǒng)頁面會引入大量的圖片，雖然圖片系統(tǒng)引入CDN服務(wù)，但單個域在高并發(fā)的時候依然會有堵塞。為了解決單域問題，我們將圖片部署到多個域上，例如img10.360buyimg.com、img11.360buyimg.com、img12.360buyimg.com等等。但多域會疊加DNS解析耗時，此時頁面可以引入預(yù)解析指令(dns-prefetch)來減少dns的解析時間，提高圖片加載速度。另外使用懶加載也是優(yōu)化的一個技巧。

3.監(jiān)控&報警

原有的報警信息通過 “系統(tǒng)日志->研發(fā)->產(chǎn)品->運營”的方式層層傳遞，不但處理問題時效長，而且占用研發(fā)資源。為了簡化報警流程，現(xiàn)有系統(tǒng)直接將報警信息同步給產(chǎn)品&運營，減少信息流通環(huán)節(jié)，提高效率。

增加報警邏輯的同時不影響系統(tǒng)性能，系統(tǒng)通過異步非阻塞的ngx.socket.tcp組件實現(xiàn)消息同步。具體流程為系統(tǒng)將日志通過ngx.socket.tcp組件傳遞給分布式任務(wù)，分布式任務(wù)通過異步方式將日志同步到Elastic集群。報警系統(tǒng)根據(jù)報警規(guī)則觸發(fā)報警信息發(fā)送。（注：使用ngx.socket.tcp組件請合理使用連接池，避免頻繁建立連接）

隨著首頁系統(tǒng)的迭代升級，團隊沉淀了蜂巢系統(tǒng)平臺以及OpenLua框架。蜂巢系統(tǒng)通過積木賦能、組件化思想搭建，可快速響應(yīng)業(yè)務(wù)需求。OpenLua框架實現(xiàn)Lua的MVC分層結(jié)構(gòu)，并融入京東內(nèi)部組件，在滿足API性能的同時提升開發(fā)效率。

繼續(xù)前行，永不止步。在之后的的研發(fā)道路上，將繼續(xù)沉淀業(yè)務(wù)需求，強化組件化、標(biāo)準(zhǔn)化思想，深耕蜂巢系統(tǒng)、OpenLua框架，使之更加靈活、高效、易用。