引言
由於近期前端抽不出資源，博主最近接手一個前端項目的代碼維護工作。拿到手一看，一臉懵逼，和博主當年所學的jsp開發方式、利用ajax來請求數據的單頁面開發方式完全不同。然而火坑已經跳下，只能硬着頭皮啃，博主只能默默告訴自己:"沖沖沖，四驅戰士在行動！"
博主勉強算是經歷了前端開發的幾個時期吧。本文以一種循序漸進的方法，講前后端分離架構的必要性。不過不得不說一點，目前前后端分離架構的文章一搜一大把，博主畢竟不是專業搞前端的，如果文章有什么理解不到位的地方，請及時指出，不勝感激。
正文
以博主的資歷，沒有經歷過更早的時期了，一出山SpringMVC和struts2等架構已經很成熟，所以博主最早接觸的開發方式就是從MVC開發方式開始的，博主將開發方式分為未分離，半分離和分離三個時期。
未分離時期
MVC，博主就不多做解釋了，在早期JSP+SERVLET中的結構圖如下
大致就是所有的請求都被發送給作為控制器的Servlet，它接受請求，並根據請求信息將它們分發給適當的JSP來響應。同時，Servlet還根據JSP的需求生成JavaBeans的實例並輸出給JSP環境。JSP可以通過直接調用方法或使用UseBean的自定義標簽得到JAVABeans中的數據。需要說明的是，這個View還可以采用 Velocity、Freemaker 等模板引擎。使用了這些模板引擎，可以使得開發過程中的人員分工更加明確，還能提高開發效率。
那么，在這個時期，開發方式有如下兩種
方式一:
方式二:
先說明一下，方式二已經逐漸淘汰。主要原因有兩點:
- (1)前端在開發過程中嚴重依賴后端，在后端沒有完成的情況下，前端根本無法干活。
- (2)由於趨勢問題，會JSP,懂velocity,freemarker的前端越來越少。
因此，方式二逐漸不被采用。然而，不得不說一點，方式一，其實很多小型傳統軟件公司至今還在使用。那么，方式一和方式二具有哪些共同的缺點呢?
I、前端無法單獨調試
在項目上線后，遇到一些問題。比如樣式出問題了，由於前端不具備項目開發環境，那么就有可能出現如下對話
前端:"我這里沒問題啊。后端，你那里正常么？"
后端:"我這里不正常啊。要不你過來看一下吧?"
前端:"一時我也看不出問題，我也沒環境，怎么辦？"
后端:"你沒環境，坐我這邊調吧。"
然后，前端就滿臉不爽的在你那調代碼了。更有些情商低的后端就直接在旁邊開摁手機，實在是。。。。。
總結，因為前端無法單獨調試。一方面開發效率降低。另一方面，還有可能引發公司內部人員上的矛盾。
II、前端不可避免會遇到后台代碼
比如前端可能碰到如下結構的代碼
<body>
<%
request.setCharacterEncoding("utf-8")
String name=request.getParameter("username");
out.print(name);
%>
</body>
身為前端，在頁面里看到了后台代碼，必然內心是十分不快的，這種方式耦合性太強。那么，就算你用了freemarker等模板引擎，不能寫JAVA代碼。那前端也不可避免的要去重新學習該模板引擎的模板語法，無謂增加了前端的學習成本。
正如我們后端開發不想寫前端一樣，你想想如果你的后台代碼里嵌入前端代碼，你是什么感受？因此，這種方式十分不妥。
III、JSP本身所導致的一些其他問題
比如，JSP第一次運行的時候比較緩慢，因為里頭包含一個翻譯為Servlet的步驟。再比如因為同步加載的原因，在jsp中有很多內容的情況下，頁面響應會很慢。
半分離時期
前后端半分離，前端負責開發頁面，通過接口（Ajax）獲取數據，采用dom操作對頁面進行數據綁定，最終是由前端把頁面渲染出來。這也就是其他博客里說的，Ajax與SPA應用（單頁應用）結合的方式。其結構圖如下
步驟如下:
(1)瀏覽器請求，cdn返回html頁面
(2)html中的js代碼以ajax方式請求后台的restful接口
(3)接口返回json數據，頁面解析json數據，通過dom操作渲染頁面
ps：博主早期就是用jquery的ajax請求，然后這么做的。
為什么說是半分離的？
因為不是所有頁面都是單頁面應用，在多頁面應用的情況下，前端因為沒有掌握controller層，前端需要跟后端討論，我們這個頁面是要同步輸出呢，還是異步json渲染呢？因此，在這一階段，只能算半分離。
這種方式的優缺點有哪些呢？
首先，這種方式的優點是很明顯的。前端不會嵌入任何后台代碼，前端專注於html、css、js的開發，不依賴於后端。自己還能夠模擬json數據來渲染頁面。發現bug，也能迅速定位出是誰的問題，不會出現互相推脫的現象。
然而，在這種架構下，還是存在明顯的弊端的。最明顯的有如下幾點：
(1)js存在大量冗余，在業務復雜的情況下，頁面的渲染部分的代碼，非常復雜。
(2)在json返回的數據比較大的情況下，渲染的十分緩慢，會出現頁面卡頓的情況
(3)seo非常不方便，由於搜索引擎的爬蟲無法爬下js異步渲染的數據，導致這樣的頁面，SEO會存在一定的問題。
(4)資源消耗嚴重，在業務復雜的情況下，一個頁面可能要發起多次http請求才能將頁面渲染完畢。可能有人不服，覺得pc端建立多次http請求也沒啥。那你考慮過移動端么，知道移動端建立一次http請求需要消耗多少資源么？
正是因為如上缺點，真正的前后端分離架構誕生了
分離時期
在這一時期，擴展了前端的范圍。認為controller層也屬於前端的一部分。在這一時期
前端：負責View和Controller層。
后端：只負責Model層，業務處理/數據等。
可是前端不懂后台代碼呀？controller層如何實現呢？
這就是node.js的妙用了，node.js適合運用在高並發、I/O密集、少量業務邏輯的場景。最重要的一點是，前端不用再學一門其他的語言了，對前端來說，上手度大大提高。
於是，這一時期架構圖如下
增加node.js作為中間層，具體有哪些好處呢？
(1)適配性提升
我們其實在開發過程中，經常會給pc端、mobile、app端各自研發一套前端。其實對於這三端來說，大部分端業務邏輯是一樣的。唯一區別就是交互展現邏輯不同。如果controller層在后端手里，后端為了這些不同端頁面展示邏輯，自己維護這些controller，徒增和前端溝通端成本。
如果增加了node.js層，此時架構圖如下
在該結構下，每種前端的界面展示邏輯由node層自己維護。如果產品經理中途想要改動界面什么的，可以由前端自己專職維護，后端無需操心。前后端各司其職，后端專注自己的業務邏輯開發，前端專注產品效果開發。
(2)響應速度提升
我們有時候，會遇到后端返回給前端的數據太簡單了，前端需要對這些數據進行邏輯運算。那么在數據量比較小的時候，對其做運算分組等操作，並無影響。但是當數據量大的時候，會有明顯的卡頓效果。這時候，node中間層其實可以將很多這樣的代碼放入node層處理、也可以替后端分擔一些簡單的邏輯、又可以用模板引擎自己掌握前台的輸出。這樣做靈活度、響應度都大大提升。
(3)性能得到提升
大家應該都知道單一職責原則。從該角度來看，我們請求一個頁面，可能要響應很多看后端接口，請求變多了，自然速度就變慢了，這種現象在mobile端更加嚴重。采用node作為中間層，將頁面所需要的多個后端數據，直接在內網階段就拼裝好，再統一返回給前端，會得到更好的性能。
分離所帶來的缺點
在分析缺點之前，容博主先自責一下。博主拿着底層程序員的工資，想着架構師，甚至是部門leader該考慮的問題了。博主有罪！ok，說重點。
先上結論，中小型軟件公司，慎用前后端分離架構！慎用！
(1)人員問題
大家自己留意一下宣傳這種架構的是什么級別的公司，中小型公司一般沒有這樣的前端資源來支撐這樣的架構。如果強推這樣的分離架構會導致一個后果，后端被硬逼着去學vue.js，node.js這些，白白增加后端的負擔。最后處理不好，會出現一個后端紛紛離職的場面，
(2) 產品迭代周期問題
中小型軟件公司，一般需要一個比較快的軟件迭代周期。采用分離架構，增加了一個接口制定流程和前后端聯調流程。從本質上來說，放慢了迭代周期。
(3) 前端需要學習業務
本來前端只需要掌管視覺交互的部分。現在因為controller層也歸前端管了，前端必須對公司的業務流程有深入的了解，才能准確的寫出顯示邏輯。不過這樣會讓后端覺得，前端奪權，前端在混KPI。前端也必須要去學無聊的業務，不過正所謂有得必有失，前端因此也能夠站穩腳跟。或許正是因為前后端分離架構的出現，前端可以朝着架構師進軍吧。
結語
本文討論了前后端未分離、半分離、分離的架構、以及各自架構演進的原因。博主前端也只能算是半吊子水平吧。其實大家發現了么，靠着前端進BAT，比靠后端進BAT難度小的多，博主也曾經動搖過，不過還是堅持在后端繼續深造。這篇文章只能算是博主的一點淺薄見解，可能博主在有些地方用詞不夠准確，希望大家指出。最后，送上一句暴露年齡的歌詞
抬頭望望天，月亮在笑。低頭看看地，浪花在跳。這個世界，我們多么渺小。只要努力，就會心比天高 ！
只要努力就好，不是嘛^_^!