為什么要前后端分離?有什么優缺點?(轉)


一、前戲

前后端分離已經成為互聯網項目開發的業界標准使用方式,通過nginx+tomcat的方式(也可以中間加一個node.js)有效的進行解耦,並且前后端分離會為以后的大型分布式架構,彈性計算架構,微服務架構,多端化服務(多種客戶端:例如:瀏覽器,車載終端,安卓,IOS等等)打下堅實的基礎。這個步驟是系統架構從猿進化成人的必經之路。
核心思想是前端html頁面通過ajax調用后端的restuful api接口並使用json數據進行交互。
在互聯網架構中,名詞解釋:
web服務器:一般指像nginx,apache這類的服務器,他們一般只能解析靜態資源。
應用服務器:一般指像tomcat,jetty,resin這類的服務器可以解析動態資源也可以解析靜態資源,但解析靜態資源的能力沒有web服務器好。
一般都是只有web服務器才能被外網訪問,應用服務器只能內網訪問。

二、術業有專攻(開發人員分離)

以前的javaweb項目大多數都是java程序員又當爹,又當媽,前后端都搞。
隨着時代的發展,漸漸的許多大中小公司開始把前后端的界限分的越來越明確。前端工程師只管前端的事情,后端工程師只管后端的事情,正所謂術業有專攻,一個人如果什么都會,那他必經什么都不精
大中型企業需要專業人才,小公司要全才。但是對於個人職業發展來說,我建議分開。
1,對於后端java工程師;
把精力放在java基礎,設計模式,jvm原理,spring+springmvc原理以及源碼Linux,mysql 事務隔離與鎖機制,mongodb,http/tcp,多線程,分布式架構,彈性計算機構,微服務架構,java性能優化,以及相關的項目管理等等。
后端追求的是三高 (高並發,高可用,高性能),安全,存儲,業務等等。
2,對於前端工程師;
把精力放在html5,css3,jquery,angularjs,bootstrap,reactjs,vuejs,webpack,less/sass,gulp,node.js,Google V8引擎,javascript多線程,模塊化,面向切面編程,設計模式,瀏覽器兼容性,性能優化等。
前端追求的是:頁面表現,速度流暢,兼容性,用戶體驗等。
術業有專攻,這樣你的核心競爭力才會越來越高,正所謂你往生活中投入什么,生活就會反饋給你什么。並且兩端的發展都越來越高深,你想什么都會,那你畢竟什么都不精。
通過將team分成前后端team,讓兩邊的工程師更加專注各自的領域,獨立治理,然后構建出一個全棧式的精益求精的team。

三、原始人時代(各種耦合)

幾曾何時,我們的JavaWeb項目都是使用了若干后台框架,springmvc/struts + spring + spring jdbc/hibernate/mybatis 等等。

大多數項目在java后端都是分了三層,控制層,業務層,持久層。控制層負責接收參數,調用相關業務層,封裝數據,以及路由&渲染到jsp頁面。然后jsp頁面上使用各種標簽或者手寫java表達式將后台的數據展現出來,玩的是MVC那套思路。

我們先看這種情況:需求定完了,代碼寫完了,測試測完了,然后呢?要發布了吧?你需要用maven或者eclipse等工具把你的代碼打成一個war包,然后把這個war包發布到你的生產環境下的web容器里,對吧?發布完了之后,你要啟動你的web容器,開始提供服務,這時候你通過配置域名,dns等等相關,你的網站就可以訪問了(假設你是個網站)。

那我們來看,你的前后端代碼是不是全都在那個war包里?包括你的js,css,圖片,各種第三方的庫,對吧?

好,下面在瀏覽器中輸入你的網站域名(www.xxx.com),之后發生了什么?(這個問題也是很多公司的面試題)我撿干的說了啊,基礎不好的童鞋請自己去搜。

瀏覽器在通過域名通過dns服務器找到你的服務器外網ip,將http請求發送到你的服務器,在tcp3次握手之后(http下面是tcp/ip),通過tcp協議開始傳輸數據,你的服務器得到請求后,開始提供服務,接收參數,之后返回你的應答給瀏覽器,瀏覽器再通過content-type來解析你返回的內容,呈現給用戶。

那么我們來看,我們先假設你的首頁中有100張圖片,此時,用戶的看似一次http請求,其實並不是一次,用戶在第一次訪問的時候,瀏覽器中不會有緩存,你的100張圖片,瀏覽器要連着請求100次http請求(有人會跟我說http長連短連的問題,不在這里討論),你的服務器接收這些請求,都需要耗費內存去創建socket來玩tcp傳輸(消耗你服務器上的計算資源)。

重點來了,這樣的話,你的服務器的壓力會非常大,因為頁面中的所有請求都是只請求到你這台服務器上,如果1個人還好,如果10000個人並發訪問呢(先不聊服務器集群,這里就說是單實例服務器),那你的服務器能扛住多少個tcp連接?你的帶寬有多大?你的服務器的內存有多大?你的硬盤是高性能的嗎?你能抗住多少IO?你給web服務器分的內存有多大?會不會宕機?

這就是為什么,越是大中型的web應用,他們越是要解耦。

理論上你可以把你的數據庫+應用服務+消息隊列+緩存+用戶上傳的文件+日志+等等都扔在一台服務器上,你也不用玩什么服務治理,也不用做什么性能監控,什么報警機制等等,就亂成一鍋粥好了。

但是這樣就好像是你把雞蛋都放在一個籃子里,隱患非常大。如果因為一個子應用的內存不穩定導致整個服務器內存溢出而hung住,那你的整個網站就掛掉了。如果出意外掛掉,而恰好這時你們的業務又處於井噴式發展高峰期,那么恭喜你,業務成功被技術卡住,很可能會流失大量用戶,后果不堪設想。

(注意:技術一定是要走在業務前面的,否則你將錯過最佳的發展期喲,親~)

此外,你的應用全部都耦合在一起,相當於一個巨石,當服務端負載能力不足時,一般會使用負載均衡的方式,將服務器做成集群,

這樣其實你是在水平擴展一塊塊巨石,性能加速度會越來越低,

要知道,本身負載就低的功能or模塊是沒有必要水平擴展的,

在本文中的例子就是你的性能瓶頸不在前端,那干嘛要水平擴展前端呢???

還有發版部署上線的時候,我明明只改了后端的代碼,為什么要前端也跟着發布呢???

正常的互聯網架構都要拆分的,你web服務器集群,你的應用服務器集群+文件服務器集群+數據庫服務器集群+消息隊列集群+緩存集群等。

四 jsp痛點

以前的javaweb項目大多數使用jsp作為頁面層展示數據給用戶,因為流量不高,因此也沒有那么多的苛刻的性能要求,

但現在是大數據時代,對互聯網項目的性能要求是越來越高,因此原始的前后端耦合在一起的架構模式已經不能滿足我們,

因此我們需要找到一種解耦的方式,來大幅提升我們的負載能力。

1,動態資源和靜態資源全部耦合在一起,服務器壓力大,因為服務器會收到各種http請求,例如css的http請求,js的,圖片等等。一旦服務器出現情況,前后台一起玩完,用戶體驗很差。
2,UI出好設計圖后,前端工程師只負責將設計圖切成html,需要由java,工程師來將html套成jsp頁面,出錯率較高(因為頁面會經常出現大量的js代碼),修改問題時需要雙方協同開發,效率低下。
3,jsp必須要在支持jsp的web服務器里運行(例如tomcat,jetty,resin等),無法使用ngingx等(NGINX據說單實例http並發5w,這個優勢要用上)性能提不上來。
4,第一次請求jsp,必須在web服務器里編譯成servlet,第一次運行會比較慢。
5,每次請求jsp都是訪問servlet再用輸出流輸出html頁面,效率沒有直接使用html高
6,jsp內有較多的標簽和表達方式,前端工程師在修改頁面時會捉襟見肘,遇到很多痛點。
7,如果jsp中的內容很多,頁面響應會很慢,因為是同步加載。
8,需要前端工程師使用java的ide,以及配置各種后端的開發環境

基於以上的一些痛點,我們應該把整個項目的開發權重往前移,剩下后端真正的解耦!

五,開發模式

以前老的方式是:
1,產品經理、領導/客戶提出需求
2,ui做出設計圖
3,前端工程師做html頁面
4,后端工程師將html頁面套成jsp(前后端依賴強,后端必須要等前端的html做好才能套jsp。如果html發生變更,就更痛了,開發效率低)
5,集成出現問題
6,前端返工
7,后端返工
8,二次集成
9,集成成功
10,交付

新的方式是:
1,產品經理/領導/客戶提出需求
2,ui做出設計圖
3,前后端約定接口&數據&參數
4,前后端並行開發(無強依賴,可以前后端並行開發,如果綉球變更,只要接口&參數不變就不用2邊都修改代碼,開發效率高)
5,前后端集成
6,前端頁面調整
7,集成成功
8,交付

六,請求方式

以前老大方式是:
1,客戶端請求,
2,服務端的servlet或controller接受請求(后端控制路由與渲染頁面,整個項目開發的權重大部分在后端)
3,調用service,dao代碼完成業務邏輯
4,返回jsp
5,jsp展現一些動態的代碼

新的方式是
1,瀏覽器發送請求
2,直接到達html頁面(前端控制路由與渲染頁面,整個開發的權重前移)
3,html頁面負責調用服務接口產生數據(通過ajax等等,后台返回的json格式數據,json數據格式因為簡潔高效而取代xml)
4,填充html,展現動態效果,在頁面進行解析並操作DOM;

總結下新的方式的請求步驟

大量並發瀏覽器請求----》web服務器集群(nginx)應用服務器集群(tomcat)--->文件/數據庫/緩存/消息隊列服務器集群
同時又可以玩分模塊,還可以按業務拆成一個個的小集群,為后面的架構升級做准備。

七,前后端分離的優勢

1,可以實現真正的前后端解耦,前端服務器使用NGINX。前端/WEB服務器放css,js,圖片等一系列靜態資源(甚至你還可以css,js,圖片等資源放到特定的文件服務器,例如阿里雲的oss,並使用cdn加速),前端服務器負責控制頁面引用&跳轉&路由,前端頁面異步調用后端的接口,后端/應用服務器使用tomcat(把tomcat想象成一個數據提供者),加快找你個體響應速度。(這里需要使用一些前端工程化的框架比如node.js,react,router.react,redux,webpack)
2,發現bug,可以快速定位是誰的問題,不會出現相互扯皮的現象。頁面邏輯,跳轉錯誤,瀏覽器兼容問題,腳本錯誤,頁面樣式等問題,全部由前端工程師負責。接口數據出錯,數據沒有提交成功,應答超時等問題全部由后端工程師解決。雙方互不干擾,前后端是相親相愛的一家人。
3。在大並發的情況下,我們可以同時水平擴展前后端服務器,比如淘寶的一個首頁就需要2000+台前端服務器做集群來抗住日均多少億+的日均pv。

(去參加阿里的技術峰會,聽他們說他們的web容器都是自己寫的,就算他單實例抗10萬http並發,2000台是2億http並發,並且他們還可以根據預知洪峰來無限拓展,很恐怖,就一個首頁。。。)

4,減少后端服務器的並發/負載壓力。除了接口以外的其他所有http請求全部轉移到前端nginx上,接口請求是tomcat,參考nginx反向代理tomcat。除了第一次頁面請求外,瀏覽器會大量調用本地緩存。
5,即使后端服務器宕機了,前端頁面也會正常那個訪問,只不過數據出不來而已
6,也許你也需要有微信相關的輕應用,那樣你的借口完全可以共用,也可以有app相關的應用服務,那么系需要通過一些代碼重構,也可以大量服用接口,提升效率(多端應用)
7,頁面顯示的東西再多也不怕,因為是異步加載
8,nginx支持頁面熱部署,不用重啟服務器,前端升級更無縫。
9,參加代碼的維護性和易讀性(前后端耦合在一起的代碼讀起來相當費勁)
10,提升開發效率,因為可以前后端並行開發,並不是以前的強依賴。
11、在nginx中部署證書,外網使用https訪問,並且只開放443和80端口,其他端口一律關閉(防止黑客端口掃描),內網使用http,性能和安全都有保障。
12、前端大量的組件代碼得以復用,組件化,提升開發效率,抽出來!

八、注意事項

1、在開需求會議的時候,前后端工程師必須全部參加,並且需要制定好接口文檔,后端工程師要寫好測試用例(2個維度),不要讓前端工程師充當你的專職測試,推薦使用chrome的插件postman或soapui或jmeter,service層的測試用例拿junit寫。ps:前端也可以玩單元測試嗎?
2、上述的接口並不是java里的interface,說白了調用接口就是調用你controler里的方法。
3、加重了前端團隊的工作量,減輕了后端團隊的工作量,提高了性能和可擴展性。
4、我們需要一些前端的框架來解決類似於頁面嵌套,分頁,頁面跳轉控制等功能。(上面提到的那些前端框架)。
5、如果你的項目很小,或者是一個單純的內網項目,那你大可放心,不用任何架構而言,但是如果你的項目是外網項目,呵呵噠。
6、 以前還有人在使用類似於velocity/freemarker等模板框架來生成靜態頁面,仁者見仁智者見智。
7、這篇文章主要的目的是說jsp在大型外網java web項目中被淘汰掉,可沒說jsp可以完全不學,對於一些學生朋友來說,jsp/servlet等相關的java web基礎還是要掌握牢的,不然你以為springmvc這種框架是基於什么來寫的?
8、如果頁面上有一些權限等等相關的校驗,那么這些相關的數據也可以通過ajax從接口里拿。
9、對於既可以前端做也可以后端做的邏輯,我建議是放到前端,為什么?因為你的邏輯需要計算資源進行計算,如果放到后端去run邏輯,則會消耗帶寬&內存&cpu等等計算資源,你要記住一點就是服務端的計算資源是有限的,而如果放到前端,使用的是客戶端的計算資源,這樣你的服務端負載就會下降(高並發場景)。類似於數據校驗這種,前后端都需要做!
10、前端需要有機制應對后端請求超時以及后端服務宕機的情況,友好的展示給用戶。

九、擴展閱讀

1,其實對於js,css,圖片這類的靜態資源可以考慮放到類似阿里雲的oss這類文件服務器上(如果普通的服務器&操作系統,存儲在到達pb級的文件后,或者單個文件夾內的文件數量達到3-5萬,io會很嚴重的性能問題),在在oss上配cdn(全國子節點加速),這樣你的頁面打開的速度向飛一樣,無論在全國哪個地方,並且你的NGINX的負載會進一步降低。
2,如果你要玩輕量級微服務架構,要使用node.js做網關,用node.js的好處還有利於seo優化,因為NGINX只是、向瀏覽器返回頁面靜態資源,而過捏的搜索引擎爬蟲只會抓取靜態數據,不會解析頁面的js,這使得應用得不到良好的搜索引擎支持。同時因為nginx不會進行頁面的組裝渲染,需要把靜態頁面返回瀏覽器,然后完成渲染工作,這加重了瀏覽器的渲染負擔。瀏覽器發起的請求經過nginx進行分發,URL請求同意分發到node.js,在node.js中進行頁面的組裝渲染;APi請求直接發送到后端服務器,完成響應。
3,如果遇到跨域問題,spring4的CROS可以完美解決,但是一般使用nginx反向代理都不會有跨域問題,除非你把前后端服務分成2個域名。JSONP的方式也被淘汰掉了。
4,如果想玩多端應用,注意去掉tomcat原生的session機制,要使用token機制,使用緩存(因為是分布式系統),做單點,對於token機制安全性問題,可以搜一下jwt
5,前端項目中可以加入mock測試(構造虛擬對象來模擬后端,可以獨立開發和測試),后端需要有詳細的測試用例,保證服務的可用性和穩定性。

十,總結

前后端分離並非僅僅是一種開發模式,而是一種架構模式(前后端分離結構)。千萬不要以為只有在擼代碼的時候把前后端分開就是前后端分離了,需要區分前后端項目。前后端項目是2個項目,放在 不同的服務器,需要獨立部署,2個不同的工程,2個不同的代碼庫,不同的開發人員。前后端工程師需要約定交互接口,實現並行開發,開發結束后需要進行獨立部署,前端通過ajax來調用http請求調用后端的restful.前端只需要關注頁面樣式和動態數據的解析&渲染,而后端專注於業務邏輯。

全文地址請點擊:https://blog.csdn.net/bntx2jsqfehy7/article/details/80589580?utm_source=copy

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM