千萬級用戶網(wǎng)站門戶前端設(shè)計
對于千萬級的注冊用戶的門戶項目是前端這塊是怎么去實現(xiàn)的,自己在平常的工作中總結(jié)了一些經(jīng)驗,也是在不斷的挫折中,不斷演練的,希望總結(jié)出來給大家參考下,和大家一起探討,一起進步。
一、門戶設(shè)計一般會遇到哪些難點
(一)、首頁打開時間太慢了
在開發(fā)一個門戶到生產(chǎn)上線后,首頁響應(yīng)時間是檢驗門戶整個系統(tǒng)架構(gòu)以及開發(fā)的重要的一項指標,有時候我們發(fā)現(xiàn)在公司測試發(fā)現(xiàn)速度都挺快的,怎么到生產(chǎn)首頁打開就慢了呢?
(二)、頁面加載不流暢,總感覺看著不舒服
因為門戶一般都是偏向于內(nèi)容和圖片類資源比較多,但是我們打開自己的網(wǎng)頁,有時候總感覺加載并不是按照我們期望的那樣加載得到,順其自然,總感覺看起來怪怪的。
(三)、希望用戶緩存的地方未進行緩存
很多靜態(tài)的前端資源,其實在系統(tǒng)未進行更新時候,第一次加載之后,希望緩存到用戶的本地,但是因為緩存策略沒搞好,經(jīng)常未進行有效的緩存。
(四)、頁面的頭部尾部經(jīng)常需要被第三方嵌入
因為作為一個比較大的門戶站點,可能會讓很多小的服務(wù)接入進來,但是頭部和尾部因為是需要保持風(fēng)格統(tǒng)一,所以經(jīng)常需要被第三方進行嵌入。
(五)、代碼沒有進行有效的壓縮,導(dǎo)致被竊取
因為作為門戶站點,前端如果不進行加密的話,代碼很容易被別人進行抄襲偽造,而且還很容易清楚里面的業(yè)務(wù)邏輯,從而很容易仿造和進行攻擊。
(六)、增量靜態(tài)資源發(fā)布
經(jīng)常門戶線上環(huán)境需要增加一點小功能,但是我們又不想去整個版本的迭代更新,這時候我們可能需要增量更新一部分代碼,但是因為加密壓縮,這時候該怎么解決呢?
(七)、門戶的輪播圖,運營位圖片那么多,該怎么提升加載速度呢?
我們經(jīng)常在門戶上面能看到很多的圖片,但是這些圖片卻大大的拖慢了整個網(wǎng)站的加載速度,怎樣去很好的處理這些圖片資源呢,你考慮過么?
(八)、大家都知道門戶需要做靜態(tài)化,但是靜態(tài)化方案那么多,哪一種合適呢?
門戶的靜態(tài)方案隨著前端技術(shù)的發(fā)展,從最開始的freemark等后端java類模板,到客戶端的渲染模板,但是他們各自有什么優(yōu)勢?該怎么選型?
(九)、需要開發(fā)多端,工作量大
二、整體設(shè)計

上圖主要說明了大型門戶中常用到的一些技術(shù),說明如下:
(一)、CDN :
假設(shè)我們的服務(wù)器都部署在合肥的機房,對于安徽的用戶來說訪問是較快的,而對于新疆的用戶訪問是較慢的,這是由于合肥和新疆分別屬于電信和聯(lián)通的不同發(fā)達地區(qū),新疆用戶訪問需要通過互聯(lián)路由器經(jīng)過較長的路徑才能訪問到合肥的服務(wù)器,返回路徑也一樣,所以數(shù)據(jù)傳輸時間比較長。對于這種情況,常常使用CDN解決,CDN將數(shù)據(jù)內(nèi)容緩存到運營商的機房,用戶訪問時先從最近的運營商獲取數(shù)據(jù),這樣大大減少了網(wǎng)絡(luò)訪問的路徑。
(二)、反向代理 :
部署在網(wǎng)站的機房,當用戶請求達到時首先訪問反向代理服務(wù)器,反向代理服務(wù)器將緩存的數(shù)據(jù)返回給用戶,如果沒有緩存數(shù)據(jù)才會繼續(xù)訪問應(yīng)用服務(wù)器獲取,這樣做減少了獲取數(shù)據(jù)的成本。反向代理常用Nginx。
(三)、硬負載 :
應(yīng)用服務(wù)器作為網(wǎng)站的入口,會承擔大量的請求,我們往往通過應(yīng)用服務(wù)器集群來分擔請求數(shù)。應(yīng)用服務(wù)器前面部署負載均衡服務(wù)器調(diào)度用戶請求,根據(jù)分發(fā)策略將請求分發(fā)到多個應(yīng)用服務(wù)器節(jié)點。
其中包括硬負載和軟負載,硬負載常用的負載均衡技術(shù)硬件的有F5,價格比較貴一般都在15W以上。軟件的有LVS、Nginx、HAProxy。LVS是四層(傳輸層)負載均衡。
(四)、使用NoSql數(shù)據(jù)庫和搜索引擎:
對于海量數(shù)據(jù)的查詢和分析,我們使用nosql數(shù)據(jù)庫加上搜索引擎可以達到更好的性能。并不是所有的數(shù)據(jù)都要放在關(guān)系型數(shù)據(jù)中。常用的NOSQL有mongodb、hbase、redis,搜索引擎有l(wèi)ucene、solr、elasticsearch。
(五)、 消息隊列:
隨著業(yè)務(wù)的擴展,應(yīng)用程序變得非常臃腫,這時我們需要將應(yīng)用程序進行業(yè)務(wù)拆分。每個業(yè)務(wù)應(yīng)用負責相對獨立的業(yè)務(wù)運作。業(yè)務(wù)之間通過消息進行通信或者共享數(shù)據(jù)庫來實現(xiàn)。
(六)、分布式文件系統(tǒng):
用戶一天天增加,業(yè)務(wù)量越來越大,產(chǎn)生的文件越來越多,單臺的文件服務(wù)器已經(jīng)不能滿足需求,這時就需要分布式文件系統(tǒng)的支撐。常用的分布式文件系統(tǒng)有GFS、HDFS、TFS。而我們業(yè)務(wù)線主要用FASTDFS。
三、前端功能性設(shè)計
(一)、多頁和單頁的選擇
門戶網(wǎng)站推薦使用多頁架構(gòu)。
理由如下:
- 多頁項目,頁面和頁面之間是獨立的,不存在交互,因此當一個頁面需要單獨重構(gòu)時,不會影響其他頁面,對于有長期歷史的項目來說,可維護性、可重構(gòu)性要高很多;
 - 多頁項目可以單次只更新一個頁面的版本,而單頁項目如果其中一個功能模塊要更新(特別是公共組件更新),很容易讓所有頁面都需要更新版本;
 - 多頁項目的版本控制更簡單,如果需要頁面拆分,調(diào)整部分頁面的使用流程,難度也會更低;
 - 灰度發(fā)布更友好;
 
優(yōu)點:
1、降低長期項目迭代維護的難度;
2、方便增量資源更新,以及緩存內(nèi)容按照頁面緩存,不會整體緩存。
(二)、考慮多端,并規(guī)范多端共用一套接口,注冊接口平臺服務(wù)
常見方案如下:
- 后端提供的接口,應(yīng)該同時考慮包含PC和H5的數(shù)據(jù)(即單獨對一個存在亢余數(shù)據(jù));
 - 接口應(yīng)當穩(wěn)定,即當業(yè)務(wù)變更時,應(yīng)盡量采取追加數(shù)據(jù)的形式;
 - 只有在單獨一端需要特殊業(yè)務(wù)流程時,設(shè)計單端獨有接口;
 - 多端共用接口,是減少開發(fā)工作量,并且提高業(yè)務(wù)可維護性的重要解決方案。
 
優(yōu)點:
1、降低開發(fā)工作量,增強可維護性。
2、頁面可以通過響應(yīng)式設(shè)計,部分頁面可以減少開發(fā)工作量。
(三)、負載均衡使用nginx
負載均衡通常使用Nginx比較多。當遇見大型項目的時候,負載均衡和分布式幾乎是必須的。前端主要是對于靜態(tài)資源服務(wù)來說,負載均衡有以下好處:
- 降低單臺server的壓力,提高業(yè)務(wù)承載能力;
 - 方便應(yīng)對峰值流量,擴容方便(如舉辦某些活動時);
 - 增強業(yè)務(wù)的可用性、擴展性、穩(wěn)定性;
 
負載均衡已經(jīng)是蠻常見的技術(shù)了,好處不用多說,很容易理解。
優(yōu)點:
1、增強業(yè)務(wù)的可用性、擴展性、穩(wěn)定性,可以支持更多用戶的訪問。
2、通過靜態(tài)資源代理,可以增加緩存,提升加載速度。
(四)、考慮使用CDN
用戶來自不同地區(qū),加入CDN可以使用戶訪問資源時,訪問離自己比較近的CDN服務(wù)器,降低訪問延遲;
降低服務(wù)器帶寬使用成本;
支持視頻、靜態(tài)資源、大文件、小文件、直播等多種業(yè)務(wù)場景;
消除跨運營商造成的網(wǎng)絡(luò)速度較慢的問題;
降低DDOS攻擊造成的對網(wǎng)站的影響;
CDN是一種比較成熟的技術(shù),各大云平_臺都有提供CDN服務(wù),價格也不貴,因此CDN的性價比很高。
優(yōu)點:
1、增加用戶訪問速度,降低網(wǎng)絡(luò)延遲,帶寬優(yōu)化,減少服務(wù)器負載,增強對攻擊的抵抗能力。
(五)、前后端分離
建議前端負責所有靜態(tài)資源的開發(fā),后端負責所有服務(wù)的開發(fā);前端通過前端工程化來完成前端靜態(tài)資源的編譯和處理工作,同時像VUE等腳手架也提供了工具。
優(yōu)點:
1、更規(guī)范的進行頁面管理,降低頁面和功能的耦合度,減少復(fù)雜頁面的環(huán)境配置時間,以及方便欄目拼接。
2、方便進行頁面的工程化處理,包括合并,壓縮,加密等;
(六)、支撐內(nèi)容和欄目可以配置
提供內(nèi)容和欄目渲染的基礎(chǔ)組件,支持這些可復(fù)用的內(nèi)容可以進行可配置,減少后期運維的成本。
門戶開發(fā)前期,一定要梳理出后期可能調(diào)整的地方,從而很大限度的進行配置。
優(yōu)點:
1、 頁面調(diào)整時候更加靈活,方便定制化;
(七)、靜態(tài)化;
能夠?qū)?shù)據(jù)進行靜態(tài)化,在服務(wù)端進行頁面的渲染。
正常情況調(diào)用接口接口,異常轉(zhuǎn)向靜態(tài)數(shù)據(jù)。
可以通過靜態(tài)頁存儲,采用定時更新機制減輕服務(wù)器負擔,首頁每個小模塊可以通過oscache進行緩存,這樣不用每次拉數(shù)據(jù)。
優(yōu)點:
1、 能夠很大程度上提升頁面以及首頁的加載速度;
(八)、緩存機制
對頭部導(dǎo)航、用戶信息等內(nèi)容進行緩存,靜態(tài)的數(shù)據(jù)進行緩存,定期更新。
常見解決方案:
直接將資源文件名使用文件摘要或者說某個固定的字符串加上一個文件摘要拼接成一個文件名。
好處有以下幾點:
首先發(fā)資源文件,由于文件名已經(jīng)不一樣了,所以不會覆蓋掉之前存在的資源文件,客戶端依舊可以安全的訪問。
再發(fā)客戶端文件,在客戶端文件一旦發(fā)布成功,那么就會立馬切成新的特性,中間可以做到無縫銜接。這就是所謂的非覆蓋發(fā)布的方案。
(九)、基礎(chǔ)組件庫的建設(shè)
梳理門戶常見的組件,并形成統(tǒng)一的UI組件庫,從而更加優(yōu)化的交互,以及方便后面升級。
門戶常用的組件不多,但是需要梳理出規(guī)范,這樣便于第三方接入。
優(yōu)點:
1、 方便頁面展示好看,并且方便第三方接入。
(十)、瀏覽器兼容
兼容性考慮統(tǒng)一解決方案,避免bug的重復(fù)產(chǎn)生。
常見解決方案:
- 配置postcss,讓某些css增加兼容性前綴;
 - 寫一個wepback的loader,處理某些特殊場景;
 - 規(guī)范團隊代碼,使用更穩(wěn)定的寫法(例如移動端避免使用fixed進行布局);
 - 對常見問題、疑難問題,總結(jié)解決方案并團隊共享;
 - 建議或引導(dǎo)用戶使用高版本瀏覽器(比如chrome);
 
優(yōu)點:
1、避免瀏覽器環(huán)境產(chǎn)生的bug,以及排查此類bug所浪費的大量時間。
(十一)、考慮響應(yīng)式設(shè)計
盡量支持響應(yīng)式布局,方便在移動設(shè)備上顯示。
優(yōu)點:
1、為后期多端開發(fā)提供支撐。
(十二)、采用靜態(tài)資源部署方式
為了前端靜態(tài)資源方便維護和升級,建議分開部署,和服務(wù)端tomcat容器不要部署在一起。
利用nginx分向,使用之前對接完成的地址+新增一個獨立上下文,然后nginx攔截執(zhí)行到tomcat外層靜態(tài)文件,原請求上下文依然使用nginx指向到tomcat調(diào)用接口。
優(yōu)點:
1、 提升靜態(tài)資源響應(yīng)速度。
四、非功能性需求
(一)、安全管理
安全管理的很難從架構(gòu)設(shè)計上完全避免,但還是有一定解決方案的,常見安全問題如下:
- XSS注入:對用戶輸入的內(nèi)容,需要轉(zhuǎn)碼(大部分時候要server端來處理,偶爾也需要前端處理),禁止使用eval函數(shù);
 - https:這個顯然是必須的,好處非常多;
 - CSRF:要求server端加入CSRF的處理方法(至少在關(guān)鍵頁面加入);
 
優(yōu)點:
1、減少安全漏洞,避免用戶受到損失,避免遭遇惡意攻擊,增加系統(tǒng)的穩(wěn)定性和安全性。
(二)、埋點系統(tǒng)
強烈推薦前端做自己的埋點系統(tǒng)。這個不同于后端的日志系統(tǒng)。
前端埋點系統(tǒng)的好處:
- 記錄每個頁面的訪問量(日周月年的UV、PV);
 - 記錄每個功能的使用量;
 - 捕捉報錯情況;
 - 圖表化顯示,方便給其他部門展示;
 
埋點系統(tǒng)是前端高度介入業(yè)務(wù),把握業(yè)務(wù)發(fā)展情況的一把利劍,通過這個系統(tǒng),我們可以比后端更深刻的把握用戶的習(xí)慣,以及給產(chǎn)品經(jīng)理、運營等人員提供準確的數(shù)據(jù)依據(jù)。當有了數(shù)據(jù)后,前端人員就可以針對性的優(yōu)化功能、布局、 頁面交互邏輯、用戶使用流程。
埋點系統(tǒng)應(yīng)和業(yè)務(wù)解耦,開發(fā)人員使用時注冊,然后在項目中引入。然后在埋點系統(tǒng)里查看相關(guān)數(shù)據(jù)(例如以小時、日、周、月、年為周期查看)
優(yōu)點:
1、數(shù)據(jù)是money,數(shù)據(jù)是公司的生命線,數(shù)據(jù)是很好的武器。
以上一些點是我們在門戶開發(fā)中常注意的點,來解決交互,性能和安全方面的問題。















 
 
 






 
 
 
 