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

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

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

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

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

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

（三）、希望使用者快取的地方未進行快取

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

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

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

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

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

（六）、增量靜態資源釋出

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

（七）、門戶的輪播圖，運營點陣圖片那麼多，該怎麼提升載入速度呢？

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

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

     門戶的靜態方案隨著前端技術的發展，從最開始的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，資料是公司的生命線，資料是最好的武器。

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