整合營(yíng)銷(xiāo)服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
家好，今天分享的是仿京東登錄頁(yè)面的簡(jiǎn)單實(shí)現(xiàn)方法（結(jié)構(gòu)與樣式），首先我們依舊是先看下效果圖
下面是HTML結(jié)構(gòu)
下面是CSS樣式
PS:本人也是小白一枚，自學(xué)沒(méi)幾天，疏漏之處在所難免，請(qǐng)多擔(dān)待！
東零售系統(tǒng)在2018年實(shí)現(xiàn)前中臺(tái)架構(gòu)的調(diào)整與劃分。中臺(tái)實(shí)現(xiàn)基礎(chǔ)服務(wù)組件開(kāi)發(fā)，前臺(tái)主要對(duì)接用戶請(qǐng)求，通過(guò)對(duì)中臺(tái)RPC數(shù)據(jù)的聚合，來(lái)滿足用戶多樣化需求。其前臺(tái)系統(tǒng)又分為首頁(yè)系統(tǒng)、單品系統(tǒng)、搜索系統(tǒng)、列表系統(tǒng)、訂單系統(tǒng)等等。
作為PC首頁(yè)研發(fā)，本文主要講解PC首頁(yè)的技術(shù)實(shí)現(xiàn)。
PC首頁(yè)業(yè)務(wù)邏輯從最初的模板渲染，到后來(lái)的SSI模塊加載以及現(xiàn)在的前后端分離。開(kāi)發(fā)語(yǔ)言也從之前的ASP、PHP逐步過(guò)渡到以LUA為主的技術(shù)框架。通過(guò)技術(shù)迭代升級(jí)，首頁(yè)頁(yè)面打開(kāi)速度從之前的200ms縮減到30ms內(nèi)，API性能從之前的500ms優(yōu)化至100ms左右。
京東零售系統(tǒng)，每天承載著億萬(wàn)網(wǎng)民的購(gòu)物需求。PC首頁(yè)又是京東商城的一級(jí)入口，所以系統(tǒng)必須達(dá)到以下3方面要求：頁(yè)面完整性(容災(zāi)、兜底、降級(jí))；流暢的加載速度(高并發(fā)、頁(yè)面加載優(yōu)化、API加載優(yōu)化)；監(jiān)控&告警。
下面將根據(jù)系統(tǒng)設(shè)定目標(biāo)逐步講解首頁(yè)系統(tǒng)實(shí)現(xiàn)方案。
1.頁(yè)面完整性
頁(yè)面完整性指任何時(shí)候訪問(wèn)頁(yè)面均需呈現(xiàn)正常的頁(yè)面樣式，不得出現(xiàn)天窗以及非200狀態(tài)碼(40x、50x等)。如下圖樓層，若將單模塊缺失直接呈現(xiàn)給用戶，將導(dǎo)致頁(yè)面天窗，影響體驗(yàn)。在單模塊異常時(shí)，系統(tǒng)可對(duì)整樓層隱藏操作，優(yōu)先保證頁(yè)面完整顯示。
下面從6方面講解容災(zāi)降級(jí)的業(yè)務(wù)邏輯：
頁(yè)面的容災(zāi)：前端頁(yè)面主要承載頁(yè)面骨架，也會(huì)包含部分開(kāi)關(guān)配置及必要的兜底數(shù)據(jù)，即使后端API服務(wù)異常，html依然可以提供基礎(chǔ)的用戶體驗(yàn)。前端頁(yè)面由模板渲染生成，其中模板變量通過(guò)配置中心（蜂巢系統(tǒng)）維護(hù)，定時(shí)worker觸發(fā)生成前端頁(yè)面，然后推送到靜態(tài)資源服務(wù)器，最終通過(guò)CDN加速提供服務(wù)。其中在worker觸發(fā)生成html階段執(zhí)行多層驗(yàn)證邏輯，保證html的完整性。
接口的容災(zāi)：一般接口邏輯均是優(yōu)先讀取緩存數(shù)據(jù)，若緩存失效則繼續(xù)讀取上游RPC數(shù)據(jù)來(lái)輸出。但上游系統(tǒng)均不保證100%可用，如何保證在上游異常的情況下提供可靠服務(wù)使頁(yè)面正常渲染呢？PC首頁(yè)系統(tǒng)在接口層面做了2方面工作：
第一、接口在讀取&聚合上游RPC數(shù)據(jù)后會(huì)保存兩部分緩存，一個(gè)為正常用戶加速緩存，一般會(huì)設(shè)置5min過(guò)期時(shí)間，一個(gè)是兜底緩存，永不過(guò)期。當(dāng)緩存或者上游RPC服務(wù)均不可用時(shí)，接口會(huì)讀取兜底緩存保證正常的數(shù)據(jù)輸出。
第二、如果API服務(wù)由于自身問(wèn)題（例如宿主機(jī)異常、Redis服務(wù)異常、用戶網(wǎng)絡(luò)抖動(dòng)等）導(dǎo)致無(wú)法提供正常的服務(wù)怎么辦。為了避免這個(gè)問(wèn)題，系統(tǒng)為API提供了一條新的訪問(wèn)途徑-CDN API。CDN API會(huì)訪問(wèn)由Worker定時(shí)生成的靜態(tài)結(jié)果集（File）輸出數(shù)據(jù)。當(dāng)前端異步加載數(shù)據(jù)感知常規(guī)線路異常后自動(dòng)觸發(fā)CDN API線路來(lái)保證接口可用性。
依據(jù)上面2種兜底邏輯，繪制如下流程圖，此邏輯將首頁(yè)API服務(wù)的可靠率提高至100%。
接口的降級(jí)：如下圖所示，正常情況接口通過(guò)讀取Cache、RPC數(shù)據(jù)、兜底Cache提供服務(wù)。但如果Cache和RPC服務(wù)均異常，接口的響應(yīng)時(shí)間就大大浪費(fèi)在前兩階段（10ms+100ms）。為了避免此情況的發(fā)生，系統(tǒng)通過(guò)配置中心（蜂巢系統(tǒng)）設(shè)置降級(jí)開(kāi)關(guān)，當(dāng)系統(tǒng)感知降級(jí)開(kāi)關(guān)打開(kāi)時(shí)，將直接讀取兜底Cache，保證API的響應(yīng)速度。
NGINX的容災(zāi)：NGINX容災(zāi)指系統(tǒng)監(jiān)控到接口非200狀態(tài)碼的時(shí)候在NGINX層面執(zhí)行兜底邏輯，此兜底邏輯可以讀取（或代理）遠(yuǎn)程靜態(tài)資源實(shí)現(xiàn)透明容災(zāi)。具體實(shí)現(xiàn)通過(guò)error_page指令完成，error_page指令可以在特定的狀態(tài)碼設(shè)置一個(gè)named location，并在其代碼塊中執(zhí)行相應(yīng)的兜底業(yè)務(wù)邏輯。
樓層容災(zāi)：在多模塊樓層，前端會(huì)調(diào)用多個(gè)API進(jìn)行頁(yè)面渲染。如下圖所示，此樓層一共包含4個(gè)模塊，每個(gè)模塊均提供獨(dú)立的API接口。當(dāng)其中一個(gè)模塊API異常，即觸發(fā)樓層隱藏動(dòng)作，避免天窗的出現(xiàn)。（這里執(zhí)行的是頁(yè)面可以有損但必須完整的策略）
終極容災(zāi)（頁(yè)面CDN兜底）：在2016年，啟動(dòng)“永不消失的首頁(yè)”項(xiàng)目，即不論情況如何極端（包括Redis服務(wù)異常、服務(wù)器異常、RPC異常、網(wǎng)絡(luò)異常等等），系統(tǒng)均可快速響應(yīng)并切換至歷史頁(yè)面來(lái)保證頁(yè)面完整。
為實(shí)現(xiàn)歷史快照，項(xiàng)目借鑒爬蟲(chóng)技術(shù)，定時(shí)抓取PC首頁(yè)的完整數(shù)據(jù)，并將快照數(shù)據(jù)推送至靜態(tài)服務(wù)器。當(dāng)監(jiān)控到系統(tǒng)異常時(shí)開(kāi)啟降級(jí)開(kāi)關(guān)將頁(yè)面及時(shí)回滾至特定歷史版本。此降能繞開(kāi)正常的服務(wù)流程，直接讀取兜底的靜態(tài)資源。具體流程如下：
（此項(xiàng)目自上線后尚未觸發(fā)一次。在其他的業(yè)務(wù)場(chǎng)景中，需要考慮各自實(shí)際情況）
2.流暢的加載速度
既要保證頁(yè)面完整性，也要保證頁(yè)面以及API的加載速度。下面從性能方面講解系統(tǒng)的優(yōu)化方向。
技術(shù)選型
首頁(yè)是一種重性能、輕邏輯的業(yè)務(wù)場(chǎng)景，沒(méi)有過(guò)多的基礎(chǔ)服務(wù)依賴，主要與Redis和上游RPC做交互。系統(tǒng)通過(guò)讀取上游RPC數(shù)據(jù)后聚合、過(guò)濾、驗(yàn)證后輸出，最終完成頁(yè)面展示。用戶請(qǐng)求簡(jiǎn)化流程圖如下：
結(jié)合業(yè)務(wù)場(chǎng)景，京東首頁(yè)在2015年開(kāi)始調(diào)研并嘗試使用OpenResty服務(wù)，基于NGINX的異步事件模型以及高性能的腳本語(yǔ)言LUA，OpenResty完美勝任京東首頁(yè)的高并發(fā)場(chǎng)景。經(jīng)過(guò)近幾年的沉淀，OpenResty成為京東首頁(yè)的基礎(chǔ)架構(gòu)，也以此沉淀了OpenLua開(kāi)發(fā)框架。
如上圖所示，OpenResty(Nginx)服務(wù)的請(qǐng)求處理?yè)碛?1個(gè)階段之多，每個(gè)階段都有其特定的業(yè)務(wù)場(chǎng)景。在init_by_lua*階段，框架初始化環(huán)境變量、init_worker_by_lua*階段初始化降級(jí)開(kāi)關(guān)以及基礎(chǔ)配置，并將其同步至共享cache(ngx.shared.DICT)、 init_write_by_lua*階段初始化路由策略、access_by_lua*階段實(shí)現(xiàn)訪問(wèn)權(quán)限驗(yàn)證，加解密等、content_by_lua*階段實(shí)現(xiàn)主體業(yè)務(wù)邏輯、log_by_lua*階段實(shí)現(xiàn)日志以及Ump信息的輸出。
Redis HotKey（熱key）優(yōu)化：在多數(shù)的業(yè)務(wù)場(chǎng)景中都使用Redis集群為服務(wù)加速，通過(guò)集群的橫向擴(kuò)展能力增加系統(tǒng)吞吐率。但在特殊的業(yè)務(wù)場(chǎng)景會(huì)有熱點(diǎn)數(shù)據(jù)的出現(xiàn)，導(dǎo)致流量?jī)A斜，增加單個(gè)分片的壓力，這樣就極大制約API的效率，極端情況甚至可以拖垮Redis集群。如何避免熱點(diǎn)數(shù)據(jù)有2種方案：1、通過(guò)復(fù)制熱點(diǎn)數(shù)據(jù)將數(shù)據(jù)存放到不同的Redis分片，每次通過(guò)隨機(jī)算法讀取；2、熱點(diǎn)數(shù)據(jù)前置、減少Redis的壓力。由于第一種方案實(shí)現(xiàn)繁瑣，系統(tǒng)使用第二種方案解決熱點(diǎn)數(shù)據(jù)，也就是將發(fā)現(xiàn)的熱點(diǎn)數(shù)據(jù)存儲(chǔ)到本地cache中(ngx.shard.DICT),通過(guò)本地cache服務(wù)直接對(duì)外提供服務(wù)，由于ngx.shard.DICT效率極高，極大優(yōu)化API的響應(yīng)時(shí)間。
Redis BigKey優(yōu)化：項(xiàng)目開(kāi)發(fā)中BigKey是不可忽略的性能點(diǎn)，可能在前期開(kāi)發(fā)以及壓測(cè)時(shí)均可以完美達(dá)到設(shè)定值，但是線上環(huán)境效率不理想，這時(shí)候就要考慮bigkey的因素了。由于bigkey占用內(nèi)存較多，不但會(huì)使網(wǎng)卡成為瓶頸，在set、get也會(huì)阻塞其他操作，直接導(dǎo)致Redis吞吐量下降。
在PC首頁(yè)系統(tǒng)bigkey的定義范圍為>5k,只要key的值大于5k均需要單獨(dú)處理。處理方案依然是2種。1、業(yè)務(wù)上做切割。例如一個(gè)業(yè)務(wù)場(chǎng)景需要將一個(gè)大的商品列表放到Cache中， 一般做法是通過(guò)kv（set key value）保存到Redis中。這時(shí)業(yè)務(wù)優(yōu)化方案是將一個(gè)key擴(kuò)展到1+n個(gè)key，一個(gè)key存儲(chǔ)id list，其余n個(gè)key存儲(chǔ)id對(duì)應(yīng)的詳情信息，這樣就將bigkey打散為多個(gè)key。2、技術(shù)上做切割。例如系統(tǒng)定義的bigkey為5k，通過(guò)算法將value以5k的界限做切割，然后系統(tǒng)存儲(chǔ)一個(gè)關(guān)系key以及n個(gè)小key實(shí)現(xiàn)bigkey轉(zhuǎn)小key的過(guò)程。
不管使用哪個(gè)方案，目標(biāo)是一致的，避免bigkey的出現(xiàn)。在將bigkey轉(zhuǎn)小key的過(guò)程中，合理使用管道技術(shù)減少redis的網(wǎng)路消耗。
分布式任務(wù)的使用：隨著個(gè)性化推薦算法的推廣，商城首頁(yè)全面接入推薦算法。由于個(gè)性化算法基于實(shí)時(shí)計(jì)算，耗時(shí)較高，為了保證用戶瀏覽的流暢度，系統(tǒng)引入分布式服務(wù)。如下圖所示，用戶在請(qǐng)求第一屏的時(shí)候?qū)⒂脩粜畔ush到分布式任務(wù)系統(tǒng)，分布式任務(wù)利用時(shí)間差計(jì)算下面樓層的個(gè)性化數(shù)據(jù)并存儲(chǔ)到Redis。當(dāng)用戶訪問(wèn)到特定樓層即可快速加載數(shù)據(jù)。
并發(fā)請(qǐng)求：每個(gè)API都會(huì)涉及多個(gè)上游RPC服務(wù)，為了避免串行請(qǐng)求帶來(lái)的耗時(shí)累加，系統(tǒng)將每個(gè)上游RPC封裝成單個(gè)子API服務(wù)，然后通過(guò)ngx.location.capture_multi命令實(shí)現(xiàn)并發(fā)請(qǐng)求來(lái)優(yōu)化API耗時(shí)。
磁盤(pán)IO優(yōu)化：為了減少磁盤(pán)io，系統(tǒng)日志模塊使用批量寫(xiě)入策略來(lái)減少磁盤(pán)io的消耗。在OpenResty中每個(gè)請(qǐng)求（包含自請(qǐng)求）都會(huì)初始化一個(gè) ngx.ctx全局表，首頁(yè)應(yīng)用將當(dāng)前請(qǐng)求在不同階段產(chǎn)生的日志內(nèi)容統(tǒng)一寫(xiě)入ngx.ctx.Log表中，并在log_by_lua*階段統(tǒng)一觸發(fā)io操作將日志寫(xiě)入文件系統(tǒng)。
圖片優(yōu)化：電商系統(tǒng)頁(yè)面會(huì)引入大量的圖片，雖然圖片系統(tǒng)引入CDN服務(wù)，但單個(gè)域在高并發(fā)的時(shí)候依然會(huì)有堵塞。為了解決單域問(wèn)題，我們將圖片部署到多個(gè)域上，例如img10.360buyimg.com、img11.360buyimg.com、img12.360buyimg.com等等。但多域會(huì)疊加DNS解析耗時(shí)，此時(shí)頁(yè)面可以引入預(yù)解析指令(dns-prefetch)來(lái)減少dns的解析時(shí)間，提高圖片加載速度。另外使用懶加載也是優(yōu)化的一個(gè)技巧。
3.監(jiān)控&報(bào)警
原有的報(bào)警信息通過(guò) “系統(tǒng)日志->研發(fā)->產(chǎn)品->運(yùn)營(yíng)”的方式層層傳遞，不但處理問(wèn)題時(shí)效長(zhǎng)，而且占用研發(fā)資源。為了簡(jiǎn)化報(bào)警流程，現(xiàn)有系統(tǒng)直接將報(bào)警信息同步給產(chǎn)品&運(yùn)營(yíng)，減少信息流通環(huán)節(jié)，提高效率。
增加報(bào)警邏輯的同時(shí)不影響系統(tǒng)性能，系統(tǒng)通過(guò)異步非阻塞的ngx.socket.tcp組件實(shí)現(xiàn)消息同步。具體流程為系統(tǒng)將日志通過(guò)ngx.socket.tcp組件傳遞給分布式任務(wù)，分布式任務(wù)通過(guò)異步方式將日志同步到Elastic集群。報(bào)警系統(tǒng)根據(jù)報(bào)警規(guī)則觸發(fā)報(bào)警信息發(fā)送。（注：使用ngx.socket.tcp組件請(qǐng)合理使用連接池，避免頻繁建立連接）
小結(jié)
隨著首頁(yè)系統(tǒng)的迭代升級(jí)，團(tuán)隊(duì)沉淀了蜂巢系統(tǒng)平臺(tái)以及OpenLua框架。蜂巢系統(tǒng)通過(guò)積木賦能、組件化思想搭建，可快速響應(yīng)業(yè)務(wù)需求。OpenLua框架實(shí)現(xiàn)Lua的MVC分層結(jié)構(gòu)，并融入京東內(nèi)部組件，在滿足API性能的同時(shí)提升開(kāi)發(fā)效率。
繼續(xù)前行，永不止步。在之后的的研發(fā)道路上，將繼續(xù)沉淀業(yè)務(wù)需求，強(qiáng)化組件化、標(biāo)準(zhǔn)化思想，深耕蜂巢系統(tǒng)、OpenLua框架，使之更加靈活、高效、易用。
、認(rèn)識(shí)WEB
網(wǎng)頁(yè)主要是由文字、圖像和超鏈接等元素構(gòu)成，除了這些基本的元素以外，還包含一些多媒體元素等，比如音頻、視頻等。
比如我們常見(jiàn)的有小米商城、京東商城、以及淘寶等，都屬于我們的大型的購(gòu)物平臺(tái)網(wǎng)站，而這些網(wǎng)站都包含了網(wǎng)頁(yè)中基本的元素。那么網(wǎng)頁(yè)是怎么形成的呢？
其實(shí)網(wǎng)頁(yè)的形參很簡(jiǎn)單，當(dāng)我們前端小姐姐將頁(yè)面通過(guò)代碼構(gòu)建好以后，再通過(guò)瀏覽器（IE、谷歌等瀏覽器）將其渲染成為用戶眼中所能看得到的各種樣式的頁(yè)面。
既然我們的網(wǎng)頁(yè)是通過(guò)瀏覽器的渲染而顯示不同的頁(yè)面，那么常見(jiàn)的瀏覽器有哪一些呢？如常見(jiàn)的五大瀏覽器，分別是IE、火狐、谷歌、Safari以及Opera等。
五大瀏覽器
但是在開(kāi)發(fā)過(guò)程中，谷歌和火狐用得比較多，可以更好地幫助開(kāi)發(fā)人員進(jìn)行調(diào)試。IE瀏覽器相對(duì)來(lái)說(shuō)存在兼容性問(wèn)題，所以很少去使用。
為什么網(wǎng)頁(yè)代碼通過(guò)瀏覽器的渲染就能顯示出各種不同的樣式的頁(yè)面呢？此處就不得不提到瀏覽器的內(nèi)核，通常瀏覽器的內(nèi)核分為如下幾種：
而五大瀏覽器之間的內(nèi)核都是什么呢？如下圖所示：
五大瀏覽器的內(nèi)核
二、Web標(biāo)準(zhǔn)
什么是Web標(biāo)準(zhǔn)？Web標(biāo)準(zhǔn)是由W3C組織和其它標(biāo)準(zhǔn)化組織，制定的一系列標(biāo)準(zhǔn)的集合。
W3C萬(wàn)維網(wǎng)聯(lián)盟是國(guó)際最著名的標(biāo)準(zhǔn)化組織。他是1994年成立后，至今已發(fā)布了近百項(xiàng)相關(guān)萬(wàn)維網(wǎng)的標(biāo)準(zhǔn)。
w3c組織
那為什么要制定Web標(biāo)準(zhǔn)呢？
作用：由于市場(chǎng)上誕生了許多不同類(lèi)型的瀏覽器，而這些瀏覽器都存在不同的內(nèi)核，導(dǎo)致前端小姐姐開(kāi)發(fā)的頁(yè)面在不同的瀏覽器上顯示會(huì)存在不同的差異，這樣就會(huì)給前端開(kāi)發(fā)者帶來(lái)了許多麻煩。而通過(guò)Web標(biāo)準(zhǔn)就會(huì)降低這種頁(yè)面之間的差異化，讓瀏覽器在解析前端代碼的時(shí)候，轉(zhuǎn)向W3C的標(biāo)準(zhǔn)，呈現(xiàn)出統(tǒng)一的效果。
優(yōu)點(diǎn)：
那么一個(gè)漂亮的頁(yè)面是怎樣構(gòu)成的呢？它的構(gòu)成分別是如下幾種類(lèi)型：
漂亮頁(yè)面的構(gòu)成
好啦！[微笑]本節(jié)就分享到這兒哦！對(duì)前端感興趣的小伙伴，可以關(guān)注我的，我會(huì)繼續(xù)給大家分享前端以及其它開(kāi)發(fā)內(nèi)容的知識(shí)，也歡迎大家給我在評(píng)論區(qū)留言[作揖]。
*請(qǐng)認(rèn)真填寫(xiě)需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
