【原創】分佈式之閒侃先後端分離的必要性

時間 2019-12-05

原文原文鏈接

引言

因爲近期前端抽不出資源，博主最近接手一個前端項目的代碼維護工做。拿到手一看，一臉懵逼，和博主當年所學的jsp開發方式、利用ajax來請求數據的單頁面開發方式徹底不一樣。然而火坑已經跳下，只能硬着頭皮啃，博主只能默默告訴本身:"沖沖衝，四驅戰士在行動！"css

博主勉強算是經歷了前端開發的幾個時期吧。本文以一種按部就班的方法，講先後端分離架構的必要性。不過不得不說一點，目前先後端分離架構的文章一搜一大把，博主畢竟不是專業搞前端的，若是文章有什麼理解不到位的地方，請及時指出，不勝感激。html

正文

以博主的資歷，沒有經歷過更早的時期了，一出山SpringMVC和struts2等架構已經很成熟，因此博主最先接觸的開發方式就是從MVC開發方式開始的，博主將開發方式分爲未分離，半分離和分離三個時期。前端

未分離時期

MVC，博主就很少作解釋了，在早期JSP+SERVLET中的結構圖以下

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

方式二:

先說明一下，方式二已經逐漸淘汰。主要緣由有兩點:vue

(1)前端在開發過程當中嚴重依賴後端，在後端沒有完成的狀況下，前端根本沒法幹活。
(2)因爲趨勢問題，會JSP,懂velocity,freemarker的前端愈來愈少。

所以，方式二逐漸不被採用。然而，不得不說一點，方式一，其實不少小型傳統軟件公司至今還在使用。那麼，方式一和方式二具備哪些共同的缺點呢?node

I、前端沒法單獨調試

在項目上線後，遇到一些問題。好比樣式出問題了，因爲前端不具有項目開發環境，那麼就有可能出現以下對話jquery

前端:"我這裏沒問題啊。後端，你那裏正常麼？"
後端:"我這裏不正常啊。要不你過來看一下吧?"
前端:"一時我也看不出問題，我也沒環境，怎麼辦？"
後端:"你沒環境，坐我這邊調吧。"
而後，前端就滿臉不爽的在你那調代碼了。更有些情商低的後端就直接在旁邊開摁手機，實在是。。。。。

總結，由於前端沒法單獨調試。一方面開發效率下降。另外一方面，還有可能引起公司內部人員上的矛盾。程序員

II、前端不可避免會遇到後臺代碼

好比前端可能碰到以下結構的代碼ajax

<body>
<%
request.setCharacterEncoding("utf-8")
String name=request.getParameter("username");
out.print(name);
%>
</body>

身爲前端，在頁面裏看到了後臺代碼，必然心裏是十分不快的，這種方式耦合性太強。那麼，就算你用了freemarker等模板引擎，不能寫JAVA代碼。那前端也不可避免的要去從新學習該模板引擎的模板語法，無謂增長了前端的學習成本。
正如咱們後端開發不想寫前端同樣，你想一想若是你的後臺代碼裏嵌入前端代碼，你是什麼感覺？所以，這種方式十分不妥。json

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難度小的多，博主也曾經動搖過，不過仍是堅持在後端繼續深造。這篇文章只能算是博主的一點淺薄看法，可能博主在有些地方用詞不夠準確，但願你們指出。最後，送上一句暴露年齡的歌詞

擡頭望望天，月亮在笑。低頭看看地，浪花在跳。這個世界，咱們多麼眇小。只要努力，就會心比天高 ！

只要努力就好，不是嘛^_^!

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。