一、背景

前后端分離是Web架構(gòu)基礎(chǔ)上的進(jìn)一步演化，是Web應(yīng)用程序交互邏輯和業(yè)務(wù)復(fù)雜度背景下的一種趨勢，前后端必然需要去解耦。針對前后端的耦合點(diǎn)來說，主要集中在數(shù)據(jù)接口和HTML渲染。數(shù)據(jù)接口隨著ajax的發(fā)展，已經(jīng)可以現(xiàn)在前后端分離，不需要在進(jìn)入頁面的時(shí)候后端去調(diào)接口渲染頁面。而針對HTML渲染，回顧之前的Web架構(gòu)，我們過去有SSR方案，這個(gè)是完全由后端完成渲染，耦合程度很高，不適合現(xiàn)在的開發(fā)方式。隨著React,Vue框架的發(fā)展，采用CSR的SPA是一種極端的實(shí)施成本最低的完全解耦方式，這種方式的html,css,js等靜態(tài)資源可以放到靜態(tài)服務(wù)器上，接口是唯一的前端和后端交互的媒介，這種方案也存在著一些問題。最后是node作為中間層為前后端同構(gòu)JavaScript編程提供可行性，可以補(bǔ)充SPA的一些不足和缺陷。

二、前后端分離架構(gòu)對比

1.基于SPA的架構(gòu)設(shè)計(jì)

首先我們通過一個(gè)流程圖來看一下SPA的工作流程

SPA工作流程

通過上圖，我們可以看出SPA的設(shè)計(jì)基本上前端和后端的耦合點(diǎn)就是接口。因?yàn)檫@樣的設(shè)計(jì)，所以導(dǎo)致整個(gè)架構(gòu)師完全和后端解耦的，極大地提高了開發(fā)效率。

第一點(diǎn)，對于一個(gè)項(xiàng)目而言，前后端只需要在開發(fā)前約定一個(gè)接口的規(guī)范和數(shù)據(jù)格式，就可以單獨(dú)的去開發(fā)各自的功能，最后只需要聯(lián)調(diào)一下接口的數(shù)據(jù)就可以各自的上線，將渲染完全從服務(wù)端進(jìn)行剝離。

第二點(diǎn)，與每個(gè)頁面都需要同服務(wù)端獲取數(shù)據(jù)的傳統(tǒng)web網(wǎng)站對比，SPA的開發(fā)方式可以建立前端路由策略來對子頁面進(jìn)行統(tǒng)籌的管理，路由的跳轉(zhuǎn)可以轉(zhuǎn)化成不同的組件渲染和不同函數(shù)的調(diào)用，后端只需要考慮接口的設(shè)計(jì)，不需要管理頁面的路由。

這種架構(gòu)設(shè)計(jì)同樣有不可避免的兩大缺點(diǎn)：

（1）采用SPA就需要舍棄SEO，SEO爬蟲軟件通過分析網(wǎng)站的HTML文檔抓取信息，從開始就沒有吧JavaScript考慮在內(nèi)，即使現(xiàn)在的SPA的網(wǎng)站日趨流行，也僅有谷歌爬蟲初步支持了SPA，但是也需要在編寫時(shí)進(jìn)行特殊處理。

（2）因?yàn)镾PA需要等待靜態(tài)資源的加載完成再請求服務(wù)器的接口獲取首屏數(shù)據(jù)，最后再渲染HTML，這段時(shí)間用戶看到的也都是白屏的頁面，這樣也需要開發(fā)者從性能上需要花費(fèi)更多的精力。

針對上面兩個(gè)缺陷，下面在項(xiàng)目實(shí)踐中給出解決方案：

白屏?xí)r間過長，首先我們可以不需要渲染整屏的數(shù)據(jù)，只需要渲染首屏的數(shù)據(jù)就可以，那針對不是首屏的頁面，我們可以采用懶加載。針對首屏的頁面，我們可以采用骨架屏來設(shè)計(jì)。通過頁面的“骨架”來取代空白的頁面，讓用戶優(yōu)先得到視覺反饋，減少用戶耐心的消耗。

骨架屏圖解

針對SEO，業(yè)界也有一套適合的解決方案，但是針對實(shí)施成本，需要綜合考慮。

SEO解決方案

總結(jié)：SPA的設(shè)計(jì)架構(gòu)在不需要關(guān)注SEO的情況下，還是很方便，便捷開發(fā)，快速迭代，前后端完全解耦，在專題頁以及現(xiàn)在的Hybrid應(yīng)用，等場景是特別適用的。

2.以Node作為中間層的架構(gòu)設(shè)計(jì)

在Web服務(wù)端與瀏覽器客戶端之間搭建Node中間渲染層也是一種前后端分離架構(gòu)設(shè)計(jì)，這種架構(gòu)方案，與SPA模式相同的是，接口仍然是前端和服務(wù)端的唯一的媒介，但是這種架構(gòu)可以在node層做接口的代理和整合，以及路由的設(shè)計(jì)和HTML的渲染。以二手車達(dá)爾文項(xiàng)目為例：

Node作為中間層的架構(gòu)設(shè)計(jì)

針對上面這樣的架構(gòu)設(shè)計(jì)，可以發(fā)現(xiàn)幾個(gè)優(yōu)點(diǎn)：

（1）由之前的前端到服務(wù)端發(fā)起請求可以轉(zhuǎn)成前端通過node發(fā)起服務(wù)端請求，因?yàn)榻涌谑莕ode發(fā)起的，可以不用服務(wù)端做跨域的設(shè)置了，另外，我們對于一些不同部門的不同接口，但是在前端來說都是來處理同一個(gè)功能的話，我們可以在node端做一層封裝，暴露給前端的也只是整合之后的接口。

（2）因?yàn)镠TML的渲染和模板都是由node來處理，所以也完成了前后端的解耦，后端只需要負(fù)責(zé)接口的編寫。

缺點(diǎn)也同樣明顯：

因?yàn)檫@樣的架構(gòu)設(shè)計(jì)，對node中間層來說，所有的功能其實(shí)也可以由服務(wù)端來完成，我們把模板放到服務(wù)端，只是處理頁面的內(nèi)容。

總結(jié)：針對獨(dú)立項(xiàng)目來說，類似于后臺管理系統(tǒng)，我們可以通過這樣的架構(gòu)來完成前后端的解耦。

a） 開發(fā)階段，我們只需要和后端完成接口的聯(lián)調(diào)，路由和頁面的渲染都是前端進(jìn)行處理節(jié)省了溝通成本，提高了開發(fā)效率。

b）后續(xù)維護(hù)階段，如果前端更改了模板文件路徑，或者要增加第三方庫文件，也不需要找后端來上線，我們只需要自己上線node服務(wù)就可以，對于后續(xù)的迭代來說也是一個(gè)更好的架構(gòu)設(shè)計(jì)。

c） 這種設(shè)計(jì)同樣只適用于不注重SEO的網(wǎng)站，比較適合用戶中心，后臺管理系統(tǒng)等。

3.基于Node同構(gòu)JavaScript的架構(gòu)設(shè)計(jì)

同構(gòu)js的目的是為了能讓js編寫的代碼既可以在瀏覽器端渲染又可以在服務(wù)器端工作。對于之前的js來說很難去脫離對DOM以及BOM的操作，這樣很難去讓js的代碼去運(yùn)行在瀏覽器端。而對于現(xiàn)在的React、Vue框架來說視圖層是由數(shù)據(jù)層來控制的，被瀏覽器解析前的HTML文檔實(shí)際上是沒有平臺屬性的文本，Node層可以去拿到j(luò)s解析后的字符串去處理，完成和客戶端的同構(gòu)。以React框架來說，具體的方案如下：

基于React的同構(gòu)圖解

這種架構(gòu)的設(shè)計(jì)讓Node作為中間層并非讓Node去替代Java去渲染HTML，而是作為同構(gòu)JavaScript作為支持，這種方案的好處在于既可以對于SEO友好，把HTML渲染到模板上，便于SEO爬蟲軟件的分析。對于首屏渲染來說，也是不錯(cuò)的體驗(yàn)，讓用戶能直接看到首屏的信息。

總結(jié)：對于這樣的一個(gè)同構(gòu)方案來說很適合構(gòu)建一些用戶體驗(yàn)高，有SEO要求的頁面，例如我們二手車的M端一些主要站點(diǎn)，很適合這樣的一個(gè)架構(gòu)。對于這樣既可以兼顧SEO，又可以采用現(xiàn)在主流的前端開發(fā)框架來說，是一個(gè)不錯(cuò)的選擇。

1）這樣的架構(gòu)使用react或者vue可以提高我們的開發(fā)效率，，減少dom操作的頻率，提高頁面性能。

2）開發(fā)出來的項(xiàng)目不僅支持SEO，同樣有很好用戶體驗(yàn)。

4.搭建服務(wù)端渲染會面臨的問題

如果我們自己去搭建這樣一套服務(wù)端渲染框架會面臨著以下幾個(gè)問題：

a） 我們需要自己去處理前后端路由相同匹配的問題

b）  需要去處理客戶端以及服務(wù)端在同構(gòu)時(shí)，redux數(shù)據(jù)統(tǒng)一的問題

c） 當(dāng)如果有首屏數(shù)據(jù)需要去拿服務(wù)端的數(shù)據(jù)來進(jìn)行頁面的渲染，如果服務(wù)端發(fā)起請求拿到數(shù)據(jù)后直接渲染頁面，而不用等到客戶端來加載之后才渲染頁面，對于用戶來說可以很大的提高用戶體驗(yàn)，也不會出現(xiàn)白屏現(xiàn)象，這樣同樣需要我們自己搭建服務(wù)端框架需要考慮的問題.

5.解決方案：基于Next.js的CarNext架構(gòu)設(shè)計(jì)

對于前端項(xiàng)目來說，如果能使用前后端同構(gòu)這樣的架構(gòu)設(shè)計(jì)的話，是一個(gè)很合適的方案，通過調(diào)研，Next.js是基于react的ssr解決方案，解決了ssr同構(gòu)方面的問題，我們只需要簡單的二次封裝就定制符合業(yè)務(wù)的服務(wù)端渲染框架。

6.Next.js會有以下特點(diǎn)：

（1）后端數(shù)據(jù)通信處理

Next.js的數(shù)據(jù)處理

（2）路由處理

Next.js內(nèi)置了路由組件，并進(jìn)行了路由的封裝，會讀取 /pages目錄下面的文件來動(dòng)態(tài)生成路由。

（3）提供了豐富擴(kuò)展性，可以擴(kuò)展Bable， Webpack ，express ,koa 等

有了這樣一個(gè)成熟的服務(wù)端框架，基于Next.js基礎(chǔ)上設(shè)計(jì)了一個(gè)CarNext框架，更好的幫助我們業(yè)務(wù)進(jìn)行開發(fā)。

1) 數(shù)據(jù)管理：對于react組件間數(shù)據(jù)通信來說，通常是采用redux來管理數(shù)據(jù)。

基于Next.js可以通過HOC來封裝redux作為數(shù)據(jù)管理

Redux處理

采用HOC這種設(shè)計(jì)模式：

a)可以簡化App組件的代碼，把需要處理redux相關(guān)的邏輯放到HOC里面，實(shí)現(xiàn)組件的邏輯分離。

b)如果前端和后端共同需要維護(hù)全局?jǐn)?shù)據(jù)的狀態(tài)，這個(gè)時(shí)候就需要在redux里面維持同一個(gè)數(shù)據(jù)狀態(tài)。下圖依照登錄邏輯來說明一下：

同步store

通過上圖的例子，當(dāng)客戶端同構(gòu)的時(shí)候，直接可以從store拿到服務(wù)端處理的登錄信息，不需要客戶端來處理登錄這部分邏輯，但是客戶端只是使用登錄信息，完成應(yīng)用的其他模塊的開發(fā)。這樣打通了數(shù)據(jù)方面的共享。

代碼如下：

2)proxy接口處理，在我們開發(fā)項(xiàng)目中可能會遇到跨域以及其他前后端通信的 問題，CarNext內(nèi)置了一個(gè)代理方案，可以把客戶端對服務(wù)端的請求轉(zhuǎn)成CarNext來轉(zhuǎn)發(fā)客戶端的請求，來避免跨域等問題。代碼如下：

通過上圖，可以看出，如果以api為開頭的請求可以通過CarNext來轉(zhuǎn)發(fā)，不是的話直接執(zhí)行next。

3)CarNext錯(cuò)誤日志處理，我們在CarNext里面使用了koa-json-error中間件，通過聯(lián)通mongodb，把項(xiàng)目中的一些錯(cuò)誤日志都存到數(shù)據(jù)庫里面，當(dāng)遇到服務(wù)出現(xiàn)問題的時(shí)候能夠及時(shí)的定位到問題。代碼如下：

同樣定義路由來查詢錯(cuò)誤日志：

4)其他的一些css,sass的設(shè)置，直接配置樣式

 可以通過下面來看出CarNext整體設(shè)計(jì)框架：

       框架組成

7.CarNext在項(xiàng)目中的應(yīng)用：

（1）在線上項(xiàng)目中，使用CarNext對首頁的渲染比使用客戶端開發(fā)提高了1倍的渲染速度。

（2）線上項(xiàng)目中，在安卓的webview里面跨域請求后端接口存在丟失cookie情況，當(dāng)時(shí)可以使用CarNext提供的接口代理來使用，因?yàn)镃arNext是不會有跨域問題，并且還是直接node去訪問。

（3）項(xiàng)目中當(dāng)時(shí)項(xiàng)目組同學(xué)使用node去請求服務(wù)端內(nèi)網(wǎng)地址而代替去請求外網(wǎng)大大的減少了整個(gè)數(shù)據(jù)通信時(shí)間。

內(nèi)外網(wǎng)請求的對比

（4）通過查詢錯(cuò)誤日志當(dāng)時(shí)很快的去定位到錯(cuò)誤情況

三、總結(jié)與規(guī)劃

通過上文所述，如果是活動(dòng)頁或者Hybrid功能頁，SPA這樣的設(shè)計(jì)來說是一個(gè)合適的方案選擇，如果是后臺管理系統(tǒng)可以選擇以node作為中間層來渲染，對于注重SEO和首屏渲染速度來說，JS的同構(gòu)設(shè)計(jì)方案則更加適合。