千萬級用戶網站門戶前端設計

發布時間：2021-06-22 15:26:45

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

 

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

（一）、首頁打開時間太慢了

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

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

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

（三）、希望用戶緩存的地方未進行緩存

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

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

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

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

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

（六）、增量靜態資源發布

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

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

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

（八）、大家都知道門戶需要做靜態化，但是靜態化方案那么多，哪一種合適呢？

     門戶的靜態方案隨著前端技術的發展，從最開始的freemark等后端java類模板，到客戶端的渲染模板，但是他們各自有什么優勢？該怎么選型？

（九）、需要開發多端，工作量大

 

二、整體設計

 

設計圖 基礎架構

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

（一）、CDN ：

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

（二）、反向代理 ：

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

（三）、硬負載 ：

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

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

（四）、使用NoSql數據庫和搜索引擎：

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

（五）、 消息隊列：

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

（六）、分布式文件系統：

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

    

三、前端功能性設計

（一）、多頁和單頁的選擇

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

理由如下：

   多頁項目，頁面和頁面之間是獨立的，不存在交互，因此當一個頁面需要單獨重構時，不會影響其他頁面，對于有長期歷史的項目來說，可維護性、可重構性要高很多；

多頁項目可以單次只更新一個頁面的版本，而單頁項目如果其中一個功能模塊要更新（特別是公共組件更新），很容易讓所有頁面都需要更新版本；

多頁項目的版本控制更簡單，如果需要頁面拆分，調整部分頁面的使用流程，難度也會更低；

灰度發布更友好；

優點：

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

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

（二）、考慮多端，并規范多端共用一套接口，注冊接口平臺服務

常見方案如下：

后端提供的接口，應該同時考慮包含PC和H5的數據（即單獨對一個存在亢余數據）；

    接口應當穩定，即當業務變更時，應盡量采取追加數據的形式；

    只有在單獨一端需要特殊業務流程時，設計單端獨有接口；

    多端共用接口，是減少開發工作量，并且提高業務可維護性的重要解決方案。

優點：

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

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

 

（三）、負載均衡使用nginx

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

降低單臺server的壓力，提高業務承載能力；

方便應對峰值流量，擴容方便（如舉辦某些活動時）；

增強業務的可用性、擴展性、穩定性；

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

優點：

   1、增強業務的可用性、擴展性、穩定性，可以支持更多用戶的訪問。

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

 

（四）、考慮使用CDN

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

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

支持視頻、靜態資源、大文件、小文件、直播等多種業務場景；

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

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

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

優點：

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

 

（五）、前后端分離

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

優點：

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

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

 

（六）、支撐內容和欄目可以配置

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

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

優點：

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

（八）、靜態化；

   能夠對數據進行靜態化，在服務端進行頁面的渲染。

正常情況調用接口接口，異常轉向靜態數據。

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

優點：

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

（九）、緩存機制

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

常見解決方案：

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

 

好處有以下幾點：

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

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

 

（十）、基礎組件庫的建設

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

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

優點：

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

（十一）、瀏覽器兼容

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

常見解決方案：

配置postcss，讓某些css增加兼容性前綴；

寫一個wepback的loader，處理某些特殊場景；

規范團隊代碼，使用更穩定的寫法（例如移動端避免使用fixed進行布局）；

對常見問題、疑難問題，總結解決方案并團隊共享；

建議或引導用戶使用高版本瀏覽器（比如chrome）；

優點：

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

 

（十二）、考慮響應式設計

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

優點：

1、為后期多端開發提供支撐。

 

（十三）、采用靜態資源部署方式

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

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

優點：

1、 提升靜態資源響應速度。

 

四、非功能性需求

（一）、安全管理

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

XSS注入：對用戶輸入的內容，需要轉碼（大部分時候要server端來處理，偶爾也需要前端處理），禁止使用eval函數；

https：這個顯然是必須的，好處非常多；

CSRF：要求server端加入CSRF的處理方法（至少在關鍵頁面加入）；

優點：

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

 

（二）、埋點系統

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

前端埋點系統的好處：

記錄每個頁面的訪問量（日周月年的UV、PV）；

記錄每個功能的使用量；

捕捉報錯情況；

圖表化顯示，方便給其他部門展示；

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

埋點系統應和業務解耦，開發人員使用時注冊，然后在項目中引入。然后在埋點系統里查看相關數據（例如以小時、日、周、月、年為周期查看）

優點：

1、數據是money，數據是公司的生命線，數據是最好的武器。

 

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