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