先後端分離架構的發展

先後端分離是如今互聯網項目開發的業界標準使用方式，咱們來看看它的發展。

先後端未分離時代（各類耦合）

這個時代能夠叫作MVC時代，由於主要是使用MVC框架。

大體就是，全部的客戶端請求都被髮送給做爲控制器的Servlet，它接收請求，並根據請求信息將它們分發給適當的JSP來響應。同時，Servlet還根據JSP的需求生成JavaBeans的實例並輸出給JSP環境。JSP能夠經過直接調用方法或使用UseBean的自定義標籤獲得JavaBeans中的數據。須要說明的是，這個View還能夠採用Velocity、Freemarker等模板引擎。使用了這些模板引擎，可使得開發過程當中的人員分工更加明確，還能提升開發效率。

在這個時期，首先是有如下的開發方式。

這種方式已經逐漸淘汰。主要緣由有兩點：

1.前端在開發過程當中嚴重依賴後端，在後端沒有完成的狀況下，前端根本沒法幹活。

2.因爲趨勢問題，會JSP、懂Velocity和曉Freemarker等模板引擎的前端愈來愈少。

所以進化出了另外一種開發方式，這種方式如今不少小型傳統軟件公司還在使用。

可是這種開發方式和它前身的開發方式有着一樣的缺點：

1.前端沒法單獨調試，開發效率低。

2.前端不可避免會遇到後臺代碼。好比說JSP中的EL表達式和JSTL標籤，難爲前端。這種方式的耦合性太強，就算用了Freemarker等模板引擎，前端也不可避免地要去從新學習該模板引擎的語法，無謂增長了前端的學習成本。

3.JSP自己侷限所致使的性能問題。一是第一次請求JSP，必需要在WEB服務器中編譯成Servlet，形成第一次運行會比較緩慢的結果；二是每次請求JSP都要訪問Servlet再用輸出流輸出HTML頁面，效率比直接使用HTML低下；三是JSP是同步加載的方式，若是頁面中有不少內容，頁面響應會很慢。

先後端半分離時代

走過了先後端未分離的時代，來到了先後端半分離的時代。在這個時代，前端負責開發頁面，經過接口（AJAX）獲取數據，採用DOM操做對頁面進行數據綁定，最終是由前端把頁面渲染出來，這也就是AJAX與SPA應用（單頁應用）結合的方式，其結構圖以下：

1.瀏覽器請求，CDN返回HTML頁面。

2.HTML中的JS代碼以AJAX的方式請求後臺的RESTFUL API接口。

3.接口響應並返回JSON數據，頁面解析JSON數據後經過DOM操做渲染頁面。

這裏後端提供的都是以JSON爲數據格式的API接口供Native端使用，一樣提供給WEB的也是JSON數據格式的API接口，那麼就意味着WEB的工做流程是：

1.打開WEB瀏覽器，加載基本資源，如CSS、JS和圖片等。

2.使用JS發起一個AJAX請求到服務端請求數據，同時展現LOADING（加載中）。

3.獲得JSON格式的數據後再根據邏輯選擇模板渲染出DOM字符串。

4.將DOM字符串插入頁面中WEB VIEW渲染出DOM結構。

這些步驟都由用戶所使用的設備中逐步執行，也就是說用戶的設備性能與APP的運行速度緊密聯繫，換句話說，若是用戶的設備很低端，那麼APP打開頁面的速度就會很慢，極度影響用戶體驗。

爲何說是半分離的呢，由於不是全部頁面都是單頁面應用。在多頁面應用的狀況下，前端由於沒有掌握Controller層，前端須要和後端討論頁面是要同步輸出仍是異步JSON渲染。並且即便在這個時期，一般也是一個工程師搞定先後端全部的工做。所以在這個階段只能算半分離。

這個時代比起上一個時代仍是有進步的，首先前端不會嵌入任何後臺代碼，前端專一於HTML、CSS、JS的開發，不依賴於後端。本身還可以模擬JSON數據來渲染頁面，發現BUG也能迅速定位出是誰的問題。

然而在這種架構下仍是存在明顯的弊端的，最明顯的有以下幾點：

1.JS存在大量冗餘，在業務複雜的狀況下，頁面的渲染部分的代碼很是複雜。

2.在JSON返回的數據量比較大的狀況下，渲染很是緩慢，會出現頁面卡頓的狀況。

3.SEO（Serach Engine Optimization，搜索引擎優化）很是不方便。因爲國內的搜索引擎的爬蟲沒法爬下JS異步渲染的數據，致使這樣的頁面SEO會存在必定的問題。

4.資源消耗嚴重，在業務複雜的狀況下，一個頁面可能要發起屢次HTTP請求才能將頁面渲染完畢。可能有人不服，以爲PC端創建屢次HTTP請求也沒啥，可是移動端創建一次HTTP請求的消耗十分巨大。

真是由於如上的缺點，咱們在亟需真正的先後端分離架構。

先後端分離時代

通過了先後端未分離、先後端半分離的時代後，終於迎來了先後端分離時代。在這個時代，前端的範圍被擴展，Controller層也被認爲是屬於前端的一部分。前端負責View和Controller層，後端只負責Model層和Service層。

但是後端開發人員對前端的HTML結構不熟悉，前端開發人員也不懂後臺代碼啊，Controller層要怎麼實現呢？這時NodeJS橫空出世了，NodeJS適合運用在高併發、I/O密集、少許業務邏輯的場景。最重要的一點是，前端不用再學一門其它語言了，美滋滋。

能夠把NodeJS當成跟前端交互的API。總的來講，NodeJS的做用在MVC中至關於C（Controller，控制器）。NodeJS路由的實現邏輯是把前端靜態頁面代碼當成字符串發送到客戶端（例如瀏覽器），簡單理解能夠理解爲路由是提供給客戶端的一組API接口，只不過返回的數據是頁面代碼的字符串而已。

用NodeJS來做爲橋樑架構服務端API輸出的JSON能帶來優異性能。後端處於性能和別的緣由，提供的接口所返回的數據格式也許不太適合前端直接使用，前端所需的排序功能、篩選功能以及到了視圖層的頁面展示，也許都須要對接口所提供的數據進行二次處理。這些處理雖然是能夠放在前端來執行，但若是數據量一大，便會浪費瀏覽器性能，更會下降頁面渲染速度，影響用戶體驗。於是現在增長NodeJS中間層是一種良好的解決方案。

增長了NodeJS中間層以後，瀏覽器（Webview）便再也不直接請求服務端的API，而是瀏覽器先去請求服務端的NodeJS，由NodeJS對服務端的API發起HTTP請求，NodeJS收到服務端的API響應返回的JSON後就去渲染HTML頁面，而後NodeJS直接將HTML頁面flush到瀏覽器。這樣，瀏覽器獲得的就是普通的HTML頁面，再也不用發AJAX去請求服務器以後再在瀏覽器進行頁面渲染了。

增長NodeJS中間層主要有如下優勢：

1.適配性提高。咱們在開發過程當中，常常會給PC端、Mobile、App端各自研發一套前端。其實對於這三端來講，大部分業務邏輯是同樣的，惟一的區別就是交互展示邏輯的不一樣。若是Controller層在後端手裏，後端爲了這些不一樣端頁面展示邏輯，本身維護這些Controller，模板沒法重用，徒增與前端溝通成本。若是增長了NodeJS層，每種前端的界面展現邏輯由NodeJS層本身維護。產品經理在中途若是想要改動界面，能夠由前端本身維護，無需後端操心。先後端各司其職，後端專一於本身的業務邏輯開發，前端專一於產品效果開發。

2.響應速度提高。有的時候會遇到後端返回給前端得數據太簡單了，須要前端對這些數據進行邏輯處理。那麼在數據量比較小得時候，對其作運算分組等操做，並沒有影響。可是當數據量大的時候，會有明顯的卡頓效果。這時候，NodeJS中間層其實能夠將不少這樣的代碼放入NodeJS層處理，也能夠替後端分擔一些簡單的邏輯、又能夠用模板引擎本身掌握前臺的輸出。這樣作，靈活度、響應度都有較大的提高。

3.性能獲得提高。你們應該都知道單一職責原則，從該角度來看，咱們請求一個頁面，可能要響應不少個後端接口，請求變多了，天然速度就變慢了，這種現象在Mobile端更加嚴重。採用NodeJS做爲中間層，將頁面所須要的多個後端數據直接在內網階段就拼裝好，再統一返回給前端，會獲得更好的性能。

4.異步與模板統一。淘寶首頁就是由幾十個HTML片斷（每一個片斷一個文件）拼裝成的。以前PHP同步加載這幾十個片斷，必定是串行的，換成NodeJS以後就能夠實現異步加載，讀文件能夠並行，一旦這些片斷中也包含業務邏輯，異步的優點就很明顯了，真正作到哪一個文件先渲染完就先輸出顯示。前端機的文件系統越複雜，頁面的組成片斷越多，這種異步的提速效果就越明顯。先後端模板統一在無線領域頗有用，PC頁面和WIFI場景下的頁面適合前端渲染（後端數據經過AJAX返回到前端），2G/3G弱網絡環境則適合後端渲染（數據隨着頁面一塊兒返回給前端），因此一樣的模板，在不一樣的條件下走不一樣的渲染渠道，模板只須要一次開發。

先後端分離的缺點

先後端分離有優勢，天然也會有缺點，由於凡事都有兩面性的。

1.人員問題。宣傳這種架構的公司通常都是很高級別的公司，通常的中小型公司沒有這樣的前端資源來支撐這樣的架構。若是強推先後端分離的架構可能會致使不少問題 ，好比後端被逼着去學VueJS，NodeJS這些，白白增長後端的負擔，甚至會形成後端開發紛紛離職的狀況。

2.產品迭代週期的問題。中小型的軟件公司通常須要一個比較快的軟件迭代週期。採用先後端分離架構的話，增長了一個接口指定流程和先後端聯調流程。從本質上來講放慢了迭代的週期。

3.前端須要學習業務知識。原本前端只須要掌管視覺交互的部分。如今由於Controller層也歸前端管了，前端必須對公司的業務流程有深刻的瞭解，才能準確地寫出顯示邏輯。不過這樣會讓後端以爲前端奪權，前端在混KPI。前端雖然必需要去學無聊的業務，可是有得必有失，前端也所以可以站穩腳跟。也許正是由於先後端分離架構的出現，前端能夠朝着架構師進軍。

總結

先後端分離雖然很熱門，可是也是要謹慎選擇使用的，特別是一些中小型的軟件公司要慎用。必定要弄清楚本身的定位，不要妄自菲薄，技術最終是爲業務服務的，能完美實現業務、並使用最低的開發成本的纔是好技術。

 

 "每一個人都在努力，每一個人都很忙。"