對于千萬級的注冊用戶的門戶項目是前端這塊是怎么去實現(xiàn)的，自己在平常的工作中總結了一些經驗，也是在不斷的挫折中，不斷演練的，希望總結出來給大家參考下，和大家一起探討，一起進步。

[[284960]]

一、門戶設計一般會遇到哪些難點

(一)、首頁打開時間太慢了

在開發(fā)一個門戶到生產上線后，首頁響應時間是檢驗門戶整個系統(tǒng)架構以及開發(fā)的重要的一項指標，有時候我們發(fā)現(xiàn)在公司測試發(fā)現(xiàn)速度都挺快的，怎么到生產首頁打開就慢了呢?

(二)、頁面加載不流暢，總感覺看著不舒服

因為門戶一般都是偏向于內容和圖片類資源比較多，但是我們打開自己的網頁，有時候總感覺加載并不是按照我們期望的那樣加載得到，順其自然，總感覺看起來怪怪的。

(三)、希望用戶緩存的地方未進行緩存

很多靜態(tài)的前端資源，其實在系統(tǒng)未進行更新時候，第一次加載之后，希望緩存到用戶的本地，但是因為緩存策略沒搞好，經常未進行有效的緩存。

(四)、頁面的頭部尾部經常需要被第三方嵌入

因為作為一個比較大的門戶站點，可能會讓很多小的服務接入進來，但是頭部和尾部因為是需要保持風格統(tǒng)一，所以經常需要被第三方進行嵌入。

(五)、代碼沒有進行有效的壓縮，導致被竊取

因為作為門戶站點，前端如果不進行加密的話，代碼很容易被別人進行抄襲偽造，而且還很容易清楚里面的業(yè)務邏輯，從而很容易仿造和進行攻擊。

(六)、增量靜態(tài)資源發(fā)布

經常門戶線上環(huán)境需要增加一點小功能，但是我們又不想去整個版本的迭代更新，這時候我們可能需要增量更新一部分代碼，但是因為加密壓縮，這時候該怎么解決呢?

(七)、門戶的輪播圖，運營位圖片那么多，該怎么提升加載速度呢?

我們經常在門戶上面能看到很多的圖片，但是這些圖片卻大大的拖慢了整個網站的加載速度，怎樣去很好的處理這些圖片資源呢，你考慮過么?

(八)、大家都知道門戶需要做靜態(tài)化，但是靜態(tài)化方案那么多，哪一種合適呢?

門戶的靜態(tài)方案隨著前端技術的發(fā)展，從最開始的freemark等后端java類模板，到客戶端的渲染模板，但是他們各自有什么優(yōu)勢?該怎么選型?

(九)、需要開發(fā)多端，工作量大

二、整體設計

 

 

 

 

設計圖 基礎架構

 

上圖主要說明了大型門戶中常用到的一些技術，說明如下：

(一)、CDN ：

假設我們的服務器都部署在合肥的機房，對于安徽的用戶來說訪問是較快的，而對于新疆的用戶訪問是較慢的，這是由于合肥和新疆分別屬于電信和聯(lián)通的不同發(fā)達地區(qū)，新疆用戶訪問需要通過互聯(lián)路由器經過較長的路徑才能訪問到合肥的服務器，返回路徑也一樣，所以數(shù)據傳輸時間比較長。對于這種情況，常常使用CDN解決，CDN將數(shù)據內容緩存到運營商的機房，用戶訪問時先從最近的運營商獲取數(shù)據，這樣大大減少了網絡訪問的路徑。

(二)、反向代理 ：

部署在網站的機房，當用戶請求達到時首先訪問反向代理服務器，反向代理服務器將緩存的數(shù)據返回給用戶，如果沒有緩存數(shù)據才會繼續(xù)訪問應用服務器獲取，這樣做減少了獲取數(shù)據的成本。反向代理常用Nginx。

(三)、硬負載 ：

應用服務器作為網站的入口，會承擔大量的請求，我們往往通過應用服務器集群來分擔請求數(shù)。應用服務器前面部署負載均衡服務器調度用戶請求，根據分發(fā)策略將請求分發(fā)到多個應用服務器節(jié)點。

其中包括硬負載和軟負載，硬負載常用的負載均衡技術硬件的有F5，價格比較貴一般都在15W以上。軟件的有LVS、Nginx、HAProxy。LVS是四層(傳輸層)負載均衡。

(四)、使用NoSql數(shù)據庫和搜索引擎：

對于海量數(shù)據的查詢和分析，我們使用nosql數(shù)據庫加上搜索引擎可以達到更好的性能。并不是所有的數(shù)據都要放在關系型數(shù)據中。常用的NOSQL有mongodb、hbase、redis，搜索引擎有l(wèi)ucene、solr、elasticsearch。

(五)、 消息隊列：

隨著業(yè)務的擴展，應用程序變得非常臃腫，這時我們需要將應用程序進行業(yè)務拆分。每個業(yè)務應用負責相對獨立的業(yè)務運作。業(yè)務之間通過消息進行通信或者共享數(shù)據庫來實現(xiàn)。

(六)、分布式文件系統(tǒng)：

用戶一天天增加，業(yè)務量越來越大，產生的文件越來越多，單臺的文件服務器已經不能滿足需求，這時就需要分布式文件系統(tǒng)的支撐。常用的分布式文件系統(tǒng)有GFS、HDFS、TFS。而我們業(yè)務線主要用FASTDFS。

三、前端功能性設計

(一)、多頁和單頁的選擇

門戶網站推薦使用多頁架構。

理由如下：

• 多頁項目，頁面和頁面之間是獨立的，不存在交互，因此當一個頁面需要單獨重構時，不會影響其他頁面，對于有長期歷史的項目來說，可維護性、可重構性要高很多;
• 多頁項目可以單次只更新一個頁面的版本，而單頁項目如果其中一個功能模塊要更新(特別是公共組件更新)，很容易讓所有頁面都需要更新版本;
• 多頁項目的版本控制更簡單，如果需要頁面拆分，調整部分頁面的使用流程，難度也會更低;
• 灰度發(fā)布更友好;

優(yōu)點：

1、降低長期項目迭代維護的難度;

2、方便增量資源更新，以及緩存內容按照頁面緩存，不會整體緩存。

(二)、考慮多端，并規(guī)范多端共用一套接口，注冊接口平臺服務

常見方案如下：

• 后端提供的接口，應該同時考慮包含PC和H5的數(shù)據(即單獨對一個存在亢余數(shù)據);
• 接口應當穩(wěn)定，即當業(yè)務變更時，應盡量采取追加數(shù)據的形式;
• 只有在單獨一端需要特殊業(yè)務流程時，設計單端獨有接口;
• 多端共用接口，是減少開發(fā)工作量，并且提高業(yè)務可維護性的重要解決方案。

優(yōu)點：

1、降低開發(fā)工作量，增強可維護性。

2、頁面可以通過響應式設計，部分頁面可以減少開發(fā)工作量。

(三)、負載均衡使用nginx

負載均衡通常使用Nginx比較多。當遇見大型項目的時候，負載均衡和分布式幾乎是必須的。前端主要是對于靜態(tài)資源服務來說，負載均衡有以下好處：

• 降低單臺server的壓力，提高業(yè)務承載能力;
• 方便應對峰值流量，擴容方便(如舉辦某些活動時);
• 增強業(yè)務的可用性、擴展性、穩(wěn)定性;

負載均衡已經是蠻常見的技術了，好處不用多說，很容易理解。

優(yōu)點：

1、增強業(yè)務的可用性、擴展性、穩(wěn)定性，可以支持更多用戶的訪問。

2、通過靜態(tài)資源代理，可以增加緩存，提升加載速度。

(四)、考慮使用CDN

用戶來自不同地區(qū)，加入CDN可以使用戶訪問資源時，訪問離自己比較近的CDN服務器，降低訪問延遲;

降低服務器帶寬使用成本;

支持視頻、靜態(tài)資源、大文件、小文件、直播等多種業(yè)務場景;

消除跨運營商造成的網絡速度較慢的問題;

降低DDOS攻擊造成的對網站的影響;

CDN是一種比較成熟的技術，各大云平_臺都有提供CDN服務，價格也不貴，因此CDN的性價比很高。

優(yōu)點：

1、增加用戶訪問速度，降低網絡延遲，帶寬優(yōu)化，減少服務器負載，增強對攻擊的抵抗能力。

(五)、前后端分離

建議前端負責所有靜態(tài)資源的開發(fā)，后端負責所有服務的開發(fā);前端通過前端工程化來完成前端靜態(tài)資源的編譯和處理工作，同時像VUE等腳手架也提供了工具。

優(yōu)點：

1、更規(guī)范的進行頁面管理，降低頁面和功能的耦合度，減少復雜頁面的環(huán)境配置時間，以及方便欄目拼接。

2、方便進行頁面的工程化處理，包括合并，壓縮，加密等;

(六)、支撐內容和欄目可以配置

提供內容和欄目渲染的基礎組件，支持這些可復用的內容可以進行可配置，減少后期運維的成本。

門戶開發(fā)前期，一定要梳理出后期可能調整的地方，從而很大限度的進行配置。

優(yōu)點：

1、 頁面調整時候更加靈活，方便定制化;

(七)、靜態(tài)化;

能夠對數(shù)據進行靜態(tài)化，在服務端進行頁面的渲染。

正常情況調用接口接口，異常轉向靜態(tài)數(shù)據。

可以通過靜態(tài)頁存儲，采用定時更新機制減輕服務器負擔，首頁每個小模塊可以通過oscache進行緩存，這樣不用每次拉數(shù)據。

優(yōu)點：

1、 能夠很大程度上提升頁面以及首頁的加載速度;

(八)、緩存機制

對頭部導航、用戶信息等內容進行緩存，靜態(tài)的數(shù)據進行緩存，定期更新。

常見解決方案：

直接將資源文件名使用文件摘要或者說某個固定的字符串加上一個文件摘要拼接成一個文件名。

好處有以下幾點：

首先發(fā)資源文件，由于文件名已經不一樣了，所以不會覆蓋掉之前存在的資源文件，客戶端依舊可以安全的訪問。

再發(fā)客戶端文件，在客戶端文件一旦發(fā)布成功，那么就會立馬切成新的特性，中間可以做到無縫銜接。這就是所謂的非覆蓋發(fā)布的方案。

(九)、基礎組件庫的建設

梳理門戶常見的組件，并形成統(tǒng)一的UI組件庫，從而更加優(yōu)化的交互，以及方便后面升級。

門戶常用的組件不多，但是需要梳理出規(guī)范，這樣便于第三方接入。

優(yōu)點：

1、 方便頁面展示好看，并且方便第三方接入。

(十)、瀏覽器兼容

兼容性考慮統(tǒng)一解決方案，避免bug的重復產生。

常見解決方案：

• 配置postcss，讓某些css增加兼容性前綴;
• 寫一個wepback的loader，處理某些特殊場景;
• 規(guī)范團隊代碼，使用更穩(wěn)定的寫法(例如移動端避免使用fixed進行布局);
• 對常見問題、疑難問題，總結解決方案并團隊共享;
• 建議或引導用戶使用高版本瀏覽器(比如chrome);

優(yōu)點：

1、避免瀏覽器環(huán)境產生的bug，以及排查此類bug所浪費的大量時間。

(十一)、考慮響應式設計

盡量支持響應式布局，方便在移動設備上顯示。

優(yōu)點：

1、為后期多端開發(fā)提供支撐。

(十二)、采用靜態(tài)資源部署方式

為了前端靜態(tài)資源方便維護和升級，建議分開部署，和服務端tomcat容器不要部署在一起。

利用nginx分向，使用之前對接完成的地址+新增一個獨立上下文，然后nginx攔截執(zhí)行到tomcat外層靜態(tài)文件，原請求上下文依然使用nginx指向到tomcat調用接口。

優(yōu)點：

1、 提升靜態(tài)資源響應速度。

四、非功能性需求

(一)、安全管理

安全管理的很難從架構設計上完全避免，但還是有一定解決方案的，常見安全問題如下：

• XSS注入：對用戶輸入的內容，需要轉碼(大部分時候要server端來處理，偶爾也需要前端處理)，禁止使用eval函數(shù);
• https：這個顯然是必須的，好處非常多;
• CSRF：要求server端加入CSRF的處理方法(至少在關鍵頁面加入);

優(yōu)點：

1、減少安全漏洞，避免用戶受到損失，避免遭遇惡意攻擊，增加系統(tǒng)的穩(wěn)定性和安全性。

(二)、埋點系統(tǒng)

強烈推薦前端做自己的埋點系統(tǒng)。這個不同于后端的日志系統(tǒng)。

前端埋點系統(tǒng)的好處：

• 記錄每個頁面的訪問量(日周月年的UV、PV);
• 記錄每個功能的使用量;
• 捕捉報錯情況;
• 圖表化顯示，方便給其他部門展示;

埋點系統(tǒng)是前端高度介入業(yè)務，把握業(yè)務發(fā)展情況的一把利劍，通過這個系統(tǒng)，我們可以比后端更深刻的把握用戶的習慣，以及給產品經理、運營等人員提供準確的數(shù)據依據。當有了數(shù)據后，前端人員就可以針對性的優(yōu)化功能、布局、 頁面交互邏輯、用戶使用流程。

埋點系統(tǒng)應和業(yè)務解耦，開發(fā)人員使用時注冊，然后在項目中引入。然后在埋點系統(tǒng)里查看相關數(shù)據(例如以小時、日、周、月、年為周期查看)

優(yōu)點：

1、數(shù)據是money，數(shù)據是公司的生命線，數(shù)據是很好的武器。

以上一些點是我們在門戶開發(fā)中常注意的點，來解決交互，性能和安全方面的問題。