本文主要介紹Vue SSR(vue服務(wù)端渲染)的應(yīng)用場景，開發(fā)中容易遇到的一些問題，提升ssr性能的方法，以及ssr的安全性問題。

SSR的應(yīng)用場景

1.SEO需求

SEO（Search Engine Optimization，搜索引擎優(yōu)化），是一種利用搜索引擎規(guī)則，提高網(wǎng)站在搜索引擎內(nèi)自然排名的技術(shù)。通常這需要頁面內(nèi)容在頁面加載完成時便已經(jīng)存在。SEO需求的存在與互聯(lián)網(wǎng)技術(shù)的發(fā)展歷程密不可分。在互聯(lián)網(wǎng)產(chǎn)生之初，網(wǎng)頁使用超文本鏈接協(xié)議，將服務(wù)器的信息傳遞給客戶端。而后出現(xiàn)了專門為人們檢索信息的搜索引擎。隨著前端技術(shù)的不斷發(fā)展，出現(xiàn)了前后端分離的純前端項(xiàng)目，由于這類項(xiàng)目需要頁面加載完成后再異步獲取數(shù)據(jù)渲染，因此大部分搜索引擎無法獲取到這類項(xiàng)目的內(nèi)容。Vue SSR正是基于此類需求而給出的一種技術(shù)方案。利用nodejs搭建頁面渲染服務(wù)，在服務(wù)端完成之前需要在客戶端完成的頁面渲染工作，輸出給SEO更友好的頁面。

除Vue SSR方案外，也可以選擇Prerender（https://github.com/prerender/prerender）作為替代方案。Prerender和Vue SSR的相同點(diǎn)是都需要在服務(wù)端完成頁面的渲染，不同點(diǎn)在于Prerender采用無界面虛擬瀏覽器Phantomjs去渲染輸出頁面，而Vue SSR是基于vue組件的渲染。相比來說Prerender的通用性更強(qiáng)，任何頁面都適用，而Vue SSR則只適用于vue項(xiàng)目，但由于Vue SSR是基于代碼層面的直接渲染，不需要像Prerender那樣再去拉取靜態(tài)資源，因此速度更快。

至于應(yīng)該使用哪一種技術(shù)方案，就要視需求和實(shí)際情況取舍了。

2.首屏渲染速度

如在上面SEO需求中提到的，目前前后端的分離的前端項(xiàng)目需要先加載靜態(tài)資源，再異步獲取數(shù)據(jù)，最后渲染頁面，在這個過程中的前兩部頁面都是沒有數(shù)據(jù)的，影響了首屏的渲染速度，也就影響了用戶的體驗(yàn)。 目前對于首屏渲染速度的提升有許多方案，在ssr之外還有龍骨，墓碑，數(shù)據(jù)直出。相比于這些方案ssr方案實(shí)現(xiàn)是最復(fù)雜的，但效果也是最好的。

下圖是項(xiàng)目使用服務(wù)端渲染前后的首屏加載時間對比，可以明顯看出服務(wù)端渲染將白屏?xí)r間和首屏完成渲染的時間都減少了50%左右。

3.Vue SSR方案的選擇

目前Vue SSR的實(shí)現(xiàn)有兩種實(shí)現(xiàn)，一種是基于官方Vue SSR指南文檔的官方方案，一種是vue.js通用應(yīng)用框架--NUXT。 官方方案具有更直接的控制應(yīng)用程序的結(jié)構(gòu)，更深入底層，更加靈活，同時在使用官方方案的過程中，也會對Vue SSR有更加深入的了解。 而NUXT提供了平滑的開箱即用的體驗(yàn)，它建立在同等的Vue技術(shù)棧之上，但抽象出很多模板，并提供了一些額外的功能，例如靜態(tài)站點(diǎn)生成。通過NUXT可以根據(jù)約定的規(guī)則，快速的實(shí)現(xiàn)Vue SSR。

開發(fā)中容易遇到的一些問題

1.一套代碼兩套執(zhí)行環(huán)境

vue的生命周期鉤子函數(shù)中， 只有?beforeCreate和?created?會在服務(wù)器端渲染(SSR)過程中被調(diào)用，這就是說在這兩個鉤子函數(shù)中的代碼以及除了vue生命周期鉤子函數(shù)的全局代碼，都將會在服務(wù)端和客戶端兩套環(huán)境下執(zhí)行。如果在兩套環(huán)境的代碼中加入具有副作用的代碼或訪問特定平臺的API，將出現(xiàn)各種問題。比如服務(wù)端沒有window、document對象， 如果加了對這個對象的引用和操作，將在服務(wù)端引起報(bào)錯中斷。

因此，總結(jié)起來，最容易犯的錯誤就是不判斷環(huán)境就去使用window、document對象。

解決方案：

（1）在beforeCreate，created生命周期以及全局的執(zhí)行環(huán)境中調(diào)用特定的api前需要判斷執(zhí)行環(huán)境；

（2）使用adapter模式，寫一套adapter兼容不同環(huán)境的api。

2.服務(wù)端數(shù)據(jù)的預(yù)獲取

官方方案使用Vuex在服務(wù)端預(yù)獲取數(shù)據(jù)。 在服務(wù)端添加vue鉤子函數(shù)，獲取數(shù)據(jù)后，將數(shù)據(jù)保存在vuex的store結(jié)構(gòu)中，同時渲染頁面。

?

在數(shù)據(jù)預(yù)獲取階段注冊的鉤子函數(shù)中，最好只進(jìn)行數(shù)據(jù)的獲取和保存，不進(jìn)行其他任何涉及this的操作。因?yàn)榇藭r的this是服務(wù)端的this，是所有用戶共享的this，進(jìn)行操作將發(fā)生一些不可預(yù)知的錯誤。

?

舉個例子，比如想在數(shù)據(jù)預(yù)獲取的鉤子函數(shù)中操作data數(shù)據(jù)。 首先，數(shù)據(jù)預(yù)獲取的鉤子函數(shù)在運(yùn)行時還沒有vue的實(shí)例，因此根本拿不到關(guān)于vue實(shí)例的任何東西；其次，進(jìn)行的存取操作都是在所有用戶的公共變量下進(jìn)行的，一旦成功進(jìn)行了存取操作，必然是所有用戶的存取操作。

?

同時需要注意的是，vuex在Vue SSR方案下，應(yīng)使用惰性注冊的方案。如果不使用惰性注冊方案，而是在一開始vuex初始化實(shí)例的時候就把所有的模塊統(tǒng)一注冊，將會出現(xiàn)多個頁面共用許多模塊的問題。

如我們有store模塊如下：

?

則在路由組件內(nèi)，需要按如下代碼惰性注冊vuex模塊

?

?

總結(jié)起來就是，在服務(wù)端預(yù)獲取數(shù)據(jù)的鉤子函數(shù)中，不要進(jìn)行額外的操作，任何對于數(shù)據(jù)的額外操作都要在vuex的體系下進(jìn)行，vuex在Vue SSR方案下，應(yīng)使用惰性注冊的方案。

3.接口代理的問題

由于前端平時開發(fā)時的接口很多都是線下的，因此需要對于接口的地址進(jìn)行代理切換。我們平時用的最多的是fiddler和charles等端口代理軟件。但是ssr在數(shù)據(jù)預(yù)獲取時走的是服務(wù)端，不是瀏覽器，因此不能通過這兩個工具進(jìn)行代理。

?

辦法有兩個，一個是修改服務(wù)器的host地址，這個方法在開發(fā)階段只需要更改本機(jī)的host就好，但是在提測階段需要修改服務(wù)器的host，如果兩個項(xiàng)目在同一個機(jī)器上測試，將不可避免的造成沖突。 第二個方法是使用axios的代理功能，因?yàn)閍xios對于ssr有天然的適配性，因此99%的項(xiàng)目都會用它。而它自帶的proxy功能，可以幫助我們方便的做接口代理。

?

代理配置文件如下：

?

?

代理設(shè)置代碼如下：

?

4.cookie穿透

由于客戶端的http請求首先達(dá)到SSR服務(wù)器，再由SSR服務(wù)器去后端服務(wù)器獲取相應(yīng)的接口數(shù)據(jù)。在客戶端到SSR服務(wù)器的請求中，客戶端是攜帶有cookie數(shù)據(jù)的。但是在SSR服務(wù)器請求后端接口的過程中，卻是沒有相應(yīng)的cookie數(shù)據(jù)的。因此在SSR服務(wù)器進(jìn)行接口請求的時候，我們需要手動拿到客戶端的cookie傳給后端服務(wù)器。這里如果使用是axios，就可以手動設(shè)置axios請求的headers字段，達(dá)到cookie穿透的目的。

?

5.路由模式

vue有兩種路由模式，一種是hash模式，就是我們經(jīng)常用的#/hasha/hashb這種，還有一種是history模式，就是/historya/historyb這種。因?yàn)閔ash模式的路由提交不到服務(wù)器上，因此ssr的路由需要采用history的方式。

異常處理問題

1.異常來自哪里？

（1）服務(wù)端數(shù)據(jù)預(yù)獲取過程中的異常，如接口請求的各種異常，獲取到數(shù)據(jù)后對數(shù)據(jù)進(jìn)行操作的過程中出現(xiàn)的錯誤異常。

（2）在服務(wù)端數(shù)據(jù)預(yù)獲取的生命周期結(jié)束后的渲染頁面過程中出現(xiàn)的異常，包括各種操作數(shù)據(jù)的語法錯誤等，如對undefined取屬性。

2.怎么處理異常

（1）官方處理方法

拋出500錯誤頁面，體驗(yàn)不友好，產(chǎn)品不接受。

（2）目前采用的方法

a.服務(wù)端數(shù)據(jù)預(yù)獲取過程中出現(xiàn)的異常，讓頁面繼續(xù)渲染，不拋出500異常頁面，打錯誤日志，接入監(jiān)控。同時，在頁面加入標(biāo)志，讓前端頁面再次進(jìn)行一次數(shù)據(jù)獲取頁面渲染的嘗試。

b.頁面渲染過程的異常。由于目前渲染過程是vue提供的一個插件進(jìn)行的，異常不好捕獲，同時出現(xiàn)問題的概率不是很大，因此還沒有做專門的處理。

代碼如下：

entry-server.js服務(wù)端部分：

?

index.template.html頁面模板部分增加如下js代碼：

entry-client.js客戶端部分：

總結(jié)：總結(jié)起來一句話，為了更好的體驗(yàn)，不要出現(xiàn)500。

性能

ssr可以提高首屏加載的速度，減少白屏?xí)r間，通過以下設(shè)置可以提高性能，減少服務(wù)器資源的占用，加快訪問速度。

（1）頁面級別的緩存 將渲染完成的頁面緩存到內(nèi)存中，同時設(shè)置最大緩存數(shù)量和緩存時間。 優(yōu)勢：大幅度提高頁面的訪問速度 代價(jià)：增加服務(wù)器內(nèi)存的使用

?

（2）組件級別的緩存 適用：純靜態(tài)組件，v-for中循環(huán)的子組件

（3）接口級別的緩存

安全

因?yàn)樽隽薾ode服務(wù)，因此安全方面也需要考慮。

(1)DDOS攻擊

最基本的DDOS攻擊就是利用合理的服務(wù)請求來占用過多的服務(wù)資源，從而使合法用戶無法得到服務(wù)的響應(yīng)

應(yīng)對：

1.提升硬件設(shè)備

硬件性能越好，提供的服務(wù)并發(fā)能力越強(qiáng)，這樣即使有小量的DDOS攻擊也可以不影響正常用戶的訪問。

2.在服務(wù)端只做最基本的處理

在服務(wù)端不做過多復(fù)雜的數(shù)據(jù)處理，可以有效的提高ssr的性能。

3.日志只打印關(guān)鍵部位的關(guān)鍵信息

打印日志過多將耗費(fèi)服務(wù)器資源，影響服務(wù)器的性能。

4.DDOS流量清洗

部署流量清洗相關(guān)設(shè)備，可以對網(wǎng)絡(luò)中的DDoS攻擊流量進(jìn)行清除，同時保證正常流量的通過。

5.DDOS軟硬件防火墻

軟件防火墻解決方案為將軟件防火墻部署到被保護(hù)的服務(wù)器上，優(yōu)點(diǎn)是成本低、方便、靈活，缺點(diǎn)是作用有限、占用資源。

硬件防火墻解決方案為安裝防火墻硬件，優(yōu)點(diǎn)是效果好，缺點(diǎn)是成本高。

(2)sql注入

就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令 例如： 游戲pc詳情頁的代碼為http://game.zhuanzhuan.com/detail/1001306437923405830?metric=e32aeb1b742c27af0ec80cef4b51b654

而攻擊者將url替換為http://game.zhuanzhuan.com/detail/select%20*%20from%20user?metric=e32aeb1b742c27af0ec80cef4b51b654

應(yīng)對：

1.對參數(shù)進(jìn)行校驗(yàn)

在服務(wù)端的entry文件中添加校驗(yàn)代碼，執(zhí)行組件的校驗(yàn)規(guī)則

(3)數(shù)據(jù)泄露

使用vuex的情況下，如果不使用惰性加載，容易造成數(shù)據(jù)泄露的情況發(fā)生。

關(guān)于任何需要登錄獲取數(shù)據(jù)的情況，建議不在服務(wù)端進(jìn)行，只在客戶端進(jìn)行

?

編輯：千鋒HTML5

作者：ChokCoco

原文：www.cnblogs.com/coco1s/p/8882542.html

總結(jié)

以上是生活随笔為你收集整理的关于Vue SSR不可不知的问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。