一、背景

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

二、前后端分離架構對比

1.基于SPA的架構設計

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

SPA工作流程

通過上圖，我們可以看出SPA的設計基本上前端和后端的耦合點就是接口。因為這樣的設計，所以導致整個架構師完全和后端解耦的，極大地提高了開發效率。

第一點，對于一個項目而言，前后端只需要在開發前約定一個接口的規范和數據格式，就可以單獨的去開發各自的功能，最后只需要聯調一下接口的數據就可以各自的上線，將渲染完全從服務端進行剝離。

第二點，與每個頁面都需要同服務端獲取數據的傳統web網站對比，SPA的開發方式可以建立前端路由策略來對子頁面進行統籌的管理，路由的跳轉可以轉化成不同的組件渲染和不同函數的調用，后端只需要考慮接口的設計，不需要管理頁面的路由。

這種架構設計同樣有不可避免的兩大缺點：

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

（2）因為SPA需要等待靜態資源的加載完成再請求服務器的接口獲取首屏數據，最后再渲染HTML，這段時間用戶看到的也都是白屏的頁面，這樣也需要開發者從性能上需要花費更多的精力。

針對上面兩個缺陷，下面在項目實踐中給出解決方案：

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

骨架屏圖解

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

SEO解決方案

總結：SPA的設計架構在不需要關注SEO的情況下，還是很方便，便捷開發，快速迭代，前后端完全解耦，在專題頁以及現在的Hybrid應用，等場景是特別適用的。

2.以Node作為中間層的架構設計

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

Node作為中間層的架構設計

針對上面這樣的架構設計，可以發現幾個優點：

（1）由之前的前端到服務端發起請求可以轉成前端通過node發起服務端請求，因為接口是node發起的，可以不用服務端做跨域的設置了，另外，我們對于一些不同部門的不同接口，但是在前端來說都是來處理同一個功能的話，我們可以在node端做一層封裝，暴露給前端的也只是整合之后的接口。

（2）因為HTML的渲染和模板都是由node來處理，所以也完成了前后端的解耦，后端只需要負責接口的編寫。

缺點也同樣明顯：

因為這樣的架構設計，對node中間層來說，所有的功能其實也可以由服務端來完成，我們把模板放到服務端，只是處理頁面的內容。

總結：針對獨立項目來說，類似于后臺管理系統，我們可以通過這樣的架構來完成前后端的解耦。

a） 開發階段，我們只需要和后端完成接口的聯調，路由和頁面的渲染都是前端進行處理節省了溝通成本，提高了開發效率。

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

c） 這種設計同樣只適用于不注重SEO的網站，比較適合用戶中心，后臺管理系統等。

3.基于Node同構JavaScript的架構設計

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

基于React的同構圖解

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

總結：對于這樣的一個同構方案來說很適合構建一些用戶體驗高，有SEO要求的頁面，例如我們二手車的M端一些主要站點，很適合這樣的一個架構。對于這樣既可以兼顧SEO，又可以采用現在主流的前端開發框架來說，是一個不錯的選擇。

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

2）開發出來的項目不僅支持SEO，同樣有很好用戶體驗。

4.搭建服務端渲染會面臨的問題

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

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

b）  需要去處理客戶端以及服務端在同構時，redux數據統一的問題

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

5.解決方案：基于Next.js的CarNext架構設計

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

6.Next.js會有以下特點：

（1）后端數據通信處理

Next.js的數據處理

（2）路由處理

Next.js內置了路由組件，并進行了路由的封裝，會讀取 /pages目錄下面的文件來動態生成路由。

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

有了這樣一個成熟的服務端框架，基于Next.js基礎上設計了一個CarNext框架，更好的幫助我們業務進行開發。

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

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

Redux處理

采用HOC這種設計模式：

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

b)如果前端和后端共同需要維護全局數據的狀態，這個時候就需要在redux里面維持同一個數據狀態。下圖依照登錄邏輯來說明一下：

同步store

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

代碼如下：

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

通過上圖，可以看出，如果以api為開頭的請求可以通過CarNext來轉發，不是的話直接執行next。

3)CarNext錯誤日志處理，我們在CarNext里面使用了koa-json-error中間件，通過聯通mongodb，把項目中的一些錯誤日志都存到數據庫里面，當遇到服務出現問題的時候能夠及時的定位到問題。代碼如下：

同樣定義路由來查詢錯誤日志：

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

 可以通過下面來看出CarNext整體設計框架：

       框架組成

7.CarNext在項目中的應用：

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

（2）線上項目中，在安卓的webview里面跨域請求后端接口存在丟失cookie情況，當時可以使用CarNext提供的接口代理來使用，因為CarNext是不會有跨域問題，并且還是直接node去訪問。

（3）項目中當時項目組同學使用node去請求服務端內網地址而代替去請求外網大大的減少了整個數據通信時間。

內外網請求的對比

（4）通過查詢錯誤日志當時很快的去定位到錯誤情況

三、總結與規劃

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