分散式之閒侃前後端分離的必要性
引言
由於近期前端抽不出資源,博主最近接手一個前端專案的程式碼維護工作。拿到手一看,一臉懵逼,和博主當年所學的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難度小的多,博主也曾經動搖過,不過還是堅持在後端繼續深造。這篇文章只能算是博主的一點淺薄見解,可能博主在有些地方用詞不夠準確,希望大家指出。最後,送上一句暴露年齡的歌詞
抬頭望望天,月亮在笑。低頭看看地,浪花在跳。這個世界,我們多麼渺小。只要努力,就會心比天高 !
只要努力就好,不是嘛^_^!
作者:孤獨煙
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31473948/viewspace-2156240/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 分散式之閒侃前後端分離架構的必要性分散式後端架構
- 前後端分離之更好的mock你的後端api後端MockAPI
- 前後端分離之Ajax入門後端
- 前後端分離後的前端時代後端前端
- 前後端完全分離之API設計後端API
- ???前後端分離模式的思考???後端模式
- 再談前後端分離後端
- 前後端分離那些事後端
- 淺談前後端分離後端
- 前後端分離——使用OSS後端
- 工程管理系統之Spring Cloud+Mybatis+Oauth2+分散式+微服務+前後端分離SpringCloudMyBatisOAuth分散式微服務後端
- 前後端分離後模組開發後端
- 前後端分離的優缺點後端
- 實現前後端分離的心得後端
- 簡單的前後端分離 Cas後端
- 實踐中的前後端分離後端
- 前後端分離之JWT(JSON Web Token)的使用後端JWTJSONWeb
- 前後端分離——資料mock後端Mock
- vue前後端分離修改webpackVue後端Web
- 前後端分離整合SpringSecurity後端SpringGse
- 前後端分離,最佳實踐後端
- 淺談WEB前後端分離Web後端
- 什麼是前後端分離?後端
- 前後端分離實踐有感後端
- 從MVC到前後端分離MVC後端
- 前後端分離Ajax入門後端
- laravel+vue前後端分離之伺服器端配置LaravelVue後端伺服器
- 前後端分離的好處有哪些?後端
- Django+Vue.js搭建前後端分離專案 web前後端分離專案實踐DjangoVue.js後端Web
- Swagger - 前後端分離後的契約Swagger後端
- Flask前後端分離專案案例Flask後端
- 從部署上做到前後端分離後端
- Laravel 前後端分離 csrf 防護Laravel後端
- Cloudera Manager 前後端分離部署方法Cloud後端
- 前後端分離的思考與實踐(三)後端
- 前後端分離的思考與實踐(四)後端
- 前後端分離的思考與實踐(五)後端
- 前後端分離的思考與實踐(六)後端