為什麼新來的經理強烈推薦前後端分離
前言
我在合肥的一家公司上班，公司規模不大不小。不是什麼網際網路公司，也不像北上廣那些大城市的公司，我們的開發技術很保守，運用傳統的技術來玩著我們的專案。因為大家都習慣了，也懶得去換什麼新潮技術了。前段時間部門招了一位經理。看了我們目前專案的架構，根據專案的實際情況，以及開發情況，就一直推薦使用前後端分離來重構專案。在之前雖然學習了點前後端分離的小知識，但沒有深入學習。由於沒有切身體會前後端分離的有點，所以不懂為什麼經理這麼強烈的推薦前後端分離呢？
原來的傳統專案模式
部門之前用的開發模式就是採用傳統的mvc模式來進行開發。大致如下圖
我們的JavaWeb專案都是使用了若干後臺框架，springmvc/struts + spring + spring jdbc/hibernate/mybatis 等等。
大多數專案在java後端都是分了三層，控制層（controller/action），業務層（service/manage），持久層（dao）。控制層負責接收引數，呼叫相關業務層，封裝資料，以及路由&渲染到jsp頁面。然後jsp頁面上使用各種標籤（jstl/el/struts標籤等）或者手寫java表示式（<%=%>）將後臺的資料展現出來，玩的是MVC那套思路。慶幸的是公司還是有前端工程師（把html靜態頁面切出來的那種)。所以我們和前端一起合作的開發模式類似下面這種。
採用上面的開發模式，我們遇到一些問題
1.初版本專案完成之後，由於專案的原因客戶需求確定也不太清晰，經常改需求很大一部分需求都是對頁面樣式的修改，甚至是對整個專案的頁面進行升級，每一次升級都得麻煩前端去重新設計介面或者修改介面，前端介面把新的html搞好了之後會發一個檔案過來，我們把新的樣式檔案加到原來得專案中，但是以前得頁面樣式又不敢隨便刪除也還保留在以前得專案中（誰知道哪天客戶又覺得以前得樣式好看呢）。隨著需求的變更，整個專案的變得越來越大（前端樣式和業務介面都在裡面），每次修改的時候苦不堪言。
2.由於專案不確定需求太多，專案上線之後。專案的瀏覽器的相容性和螢幕解析度的問題暴露出來了，這時候讓前端再去改這些頁面也是難上加難，前端也沒有實際的除錯環境。沒辦法只能自己去搞，但是說實話這些相容性問題我們真的不擅長，往往這時候就會發生前後端踢皮球的一幕。。
半分離模式
前後端半分離，前端負責開發頁面，通過介面（Ajax）獲取資料，採用dom操作對頁面進行資料繫結，最終是由前端把頁面渲染出來。這也就是其他部落格裡說的，Ajax與SPA應用（單頁應用）結合的方式。其結構圖如下
步驟如下:
(1)瀏覽器請求，cdn返回html頁面
(2)html中的js程式碼以ajax方式請求後臺的restful介面
(3)介面返回json資料，頁面解析json資料，通過dom操作渲染頁面
為什麼說是半分離的？
因為不是所有頁面都是單頁面應用，在多頁面應用的情況下，前端因為沒有掌握controller層，前端需要跟後端討論，我們這個頁面是要同步輸出呢，還是非同步json渲染呢？因此，在這一階段，只能算半分離。
這種方式的優缺點有哪些呢？
首先，這種方式的優點是很明顯的。前端不會嵌入任何後臺程式碼，前端專注於html、css、js的開發，不依賴於後端。自己還能夠模擬json資料來渲染頁面。發現bug，也能迅速定位出是誰的問題，不會出現互相推脫的現象。
然而，在這種架構下，還是存在明顯的弊端的。最明顯的有如下幾點：
(1)js存在大量冗餘，在業務複雜的情況下，頁面的渲染部分的程式碼，非常複雜。
(2)在json返回的資料比較大的情況下，渲染的十分緩慢，會出現頁面卡頓的情況
(3)seo非常不方便，國內的搜尋引擎爬蟲只會抓取靜態資料，不會解析頁面中的js，這使得應用得不到良好的搜尋引擎支援。
(4)資源消耗嚴重，在業務複雜的情況下，一個頁面可能要發起多次http請求才能將頁面渲染完畢。
最終的前後端分離
在這一時期，擴充套件了前端的範圍。認為controller層也屬於前端的一部分。在這一時期
前端：負責View和Controller層。
後端：只負責Model層，業務處理/資料等。
可是前端不懂後臺程式碼呀？controller層如何實現呢？
這就是node.js的妙用了，node.js適合運用在高併發、I/O密集、少量業務邏輯的場景。
這時候的開發模式就是下面的這種了
上面這種模式的‘優勢在哪呢？
1. 適配性提升
我們其實在開發過程中，經常會給pc端、mobile、app端各自研發一套前端。其實對於這三端來說，大部分端業務邏輯是一樣的。唯一區別就是互動展現邏輯不同。如果controller層在後端手裡，後端為了這些不同端頁面展示邏輯，自己維護這些controller，徒增和前端溝通端成本。
如果增加了node.js層，此時架構圖如下
在該結構下，每種前端的介面展示邏輯由node層自己維護。如果產品經理中途想要改動介面什麼的，可以由前端自己專職維護，後端無需操心。前後端各司其職，後端專注自己的業務邏輯開發，前端專注產品效果開發。
2. 響應速度提升
我們有時候，會遇到後端返回給前端的資料太簡單了，前端需要對這些資料進行邏輯運算。那麼在資料量比較小的時候，對其做運算分組等操作，並無影響。但是當資料量大的時候，會有明顯的卡頓效果。這時候，node中間層其實可以將很多這樣的程式碼放入node層處理、也可以替後端分擔一些簡單的邏輯、又可以用模板引擎自己掌握前臺的輸出。這樣做靈活度、響應度都大大提升。
3. 效能得到提升
大家應該都知道單一職責原則。從該角度來看，我們請求一個頁面，可能要響應很多看後端介面，請求變多了，自然速度就變慢了，這種現象在mobile端更加嚴重。採用node作為中間層，將頁面所需要的多個後端資料，直接在內網階段就拼裝好，再統一返回給前端，會得到更好的效能。