深入淺出:了解前后端分離優勢、前后端接口聯調以及優化問題


深入淺出:了解前后端分離優勢、前后端接口聯調以及優化問題

目錄:

1. 項目有前后端分離和前后端不分離;

2. 前后端接口聯調;

3.前端性能優化 ;

4.前端安全問題;

一、項目有前后端分離和前后端不分離:

  在前后端不分離架構中,所有的靜態資源和業務代碼統一部署在同一台服務器上。服務器接收到瀏覽器的請求后,進行處理得到數據,然后將數據填充到靜態頁面中,最終返回給瀏覽器。

 

 

 實現前后端分離后,有了下面幾點改變:

  1.服務器一分為二,前后端分別部署,靜態資源放在前端服務器,業務代碼放在后的服務器

  2.前端服務器需要接收Http請求(一般使用node.js)

  3.前端服務器需要進行視圖解析(可以使用vue.js、angular.js)

  4.前端服務器需要處理路由(也就是頁面之間的跳轉邏輯)

  5.后端服務器只需要返回數據

 

一、前言

 

  前后端分離已成為互聯網項目開發的業界標准使用方式,通過nginx+tomcat的方式(也可以中間加一個nodejs)有效的進行解耦,並且前后端分離會為以后的大型分布式架構、彈性計算架構、微服務架構、多端化服務(多種客戶端,例如:瀏覽器,車載終端,安卓,IOS等等)打下堅實的基礎。這個步驟是系統架構從猿進化成人的必經之路。

 

  核心思想是前端html頁面通過ajax調用后端的restuful api接口並使用json數據進行交互。

 

  在互聯網架構中,名詞解釋:

 

  Web服務器:一般指像nginx,apache這類的服務器,他們一般只能解析靜態資源。

 

  應用服務器:一般指像tomcat,jetty,resin這類的服務器可以解析動態資源也可以解析靜態資源,但解析靜態資源的能力沒有web服務器好。

 

二、技術分工(開發人員分離)

 

以前的JavaWeb項目大多數都是java程序員又當爹又當媽,又搞前端,又搞后端。

 

隨着時代的發展,漸漸的許多大中小公司開始把前后端的界限分的越來越明確,前端工程師只管前端的事情,后端工程師只管后端的事情。正所謂術業有專攻,一個人如果什么都會,那么他畢竟什么都不精。大中型公司需要專業人才,小公司需要全才,但是對於個人職業發展來說,我建議是分開。

 

1、對於后端java工程師:(負責Model層,業務處理/數據等

 

把精力放在java基礎,設計模式,jvm原理,spring+springmvc原理及源碼,linux,mysql事務隔離與鎖機制,mongodb,http/tcp,多線程,分布式架構,彈性計算架構,微服務架構,java性能優化,以及相關的項目管理等等。

 

后端追求的是:三高(高並發,高可用,高性能),安全,存儲,業務等等。

 

2、對於前端工程師:(負責View和Controller層。

 

把精力放在html5,css3,jquery,angularjs,bootstrap,reactjs,vuejs,webpack,less/sass,gulp,nodejs,Google V8引擎,javascript多線程,模塊化,面向切面編程,設計模式,瀏覽器兼容性,性能優化等等。

 

前端追求的是:頁面表現,速度流暢,兼容性,用戶體驗等等。

 

術業有專攻,這樣你的核心競爭力才會越來越高,正所謂你往生活中投入什么,生活就會反饋給你什么。並且兩端的發展都越來越高深,你想什么都會,那你畢竟什么都不精。

通過將team分成前后端team,讓兩邊的工程師更加專注各自的領域,獨立治理,然后構建出一個全棧式的精益求精的team。

 

三、開發模式

以前老的方式是:

 

  產品經歷/領導/客戶提出需求===》UI做出設計圖 ===》前端工程師做html頁面===》后端工程師將html頁面套成jsp頁面(前后端強依賴,后端必須要等前端的html做好才能套jsp。如果html發生變更,就更痛了,開發效率低)===》集成出現問題 ===》前端返工 ===》后端返工===》二次集成 ===》集成成功 ==》交付

 

新的方式是:

 

  產品經歷/領導/客戶提出需===》UI做出設計圖 ===》前后端約定接口&數據&參數 ===》前后端並行開發(無強依賴,可前后端並行開發,如果需求變更,只要接口&參數不變,就不用兩邊都修改代碼,開發效率高)===》前后端集成 ===》前端頁面調整 ===》集成成功 ===》交付

 

四、請求方式

 

 
以前老的方式是:

 

 
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想象成一個數據提供者),加快整體響應速度。(這里需要使用一些前端工程化的框架比如nodejs,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、前端需要有機制應對后端請求超時以及后端服務宕機的情況,友好的展示給用戶

 

原文:https://blog.csdn.net/bntX2jSQfEHy7/article/details/80589580 

 

二、前后端接口聯調: 

前言:

以JC同事為例,他公司為前后端分離架構,前端vue全家桶;前后端人員開會協商數據接口后(主要是定義傳輸的數據和API接口),前后端並行開發;因為后台此時無法提供后端數據,所以前端需要用mock模擬假數據,管理API接口,獲取數據,到時接口聯調時連接后端服務器,訪問后端數據即可。

但是JC同事的ajax的借口寫的是與后端叔叔商量好的絕對路徑(域名+請求路徑+請求參數,跨域問題已解決),因為這是以后真正的請求路徑,所以JC同事又不像先寫本地相對路徑,后期再來修改(萬一后台叔叔開發的慢了,鬼知道有多少接口要修改呀)。於是他就迷茫了。。。

仔細看看這其實就是前后端分離中的mock數據和聯調的問題,就現在來說能解決的方式有很多種。先說mock數據,gulp,webpack, fekit (去哪兒網的一款前端自動化構建工具,據說歷史比webpack和gulp都要久遠)等等自動化構建工具都有mock數據的功能,這不是問題;再說絕對路徑的問題,其實只需要做一個host的映射就行了。

一、什么是前后端接口聯調

之前開發寫代碼的時候,所有的ajax數據都不是后端返回的真實數據,而是我們自己通過接口mock模擬的假數據,當前端的代碼編寫完畢,后端的接口也已經寫好之后,我們就需要把mock數據干掉,嘗試使用后端提供的數據,進行前后端的一個調試,這個過程我們就把它稱之為前后端的接口聯調。

為什么要聯調 本地的mock數據是JC同事自己寫的,肯定符合前端需求,但是后端接口首先需要測試通不通,還需要測試數據格式對不對,還有后端有沒有填寫足夠的數據,比如寫列表頁,前端想分頁,如果后端就寫了兩條測試數據,你咋整? 所以,Jack需要根據后端對接口的調整,不斷地來回切換url,這樣豈不是還在受后端的影響,還談什么毛線的前后端分離,名存實亡嘛!

二、如何實現前后端接口聯調

 

首先,我們已經知道,目前的前后端分離的架構應用分為兩種情況:

 

前后端完全分離,前后端分別擁有自己的域名和服務器。

 

前后端開發分離,但是部署時是一個域名和一台服務器。

 

雖然架構可以采用前后端分離,但是部署有可能就不一樣了,這和項目的大小,公司的情況等等都有關系了,一個百八十人用的小系統,還得兩台服務器兩個域名,你不覺着浪費嗎?兩種不同的部署情況直接導致了前期在設計聯調方案的時候就不同了。

 

如果你們公司的項目在部署時是兩台服務器對應兩個域名,恭喜你,這是最nice的方案,也是聯調最舒服的方式。第二種情況,也就是開發時前后端分離,部署時是一個域名和一台服務器。知道這個之后,他就明白接下來該怎么操作了。JC同事之前在項目根目錄static文件夾下新建了一個mock文件夾,里面寫了一些json文件,當我們做聯調的時候,這些mock數據就沒用了,我們要把mock數據切換成后端提供給我們的真實的數據。
 

當我的朋友Jack把static文件夾下的mock數據刪除之后,在運行項目,發現報錯了,瀏覽器告訴他,你訪問的mock下面的index.json文件找不到404。

 

我們平時本地前端開發環境dev地址大多是 localhost:8080,而后台服務器的訪問地址就有很多種情況了,比如 后端程序猿本地IP(127.0.0.1:8889),或者外網域名,當前端與后台進行數據交互時,自然就出現跨域問題(后台服務沒做處理情況下)。axios不支持jsonp, 所以我們就要使用http-proxy-middleware中間件做代理。

 
現在通過在前端修改 vue-cli 的配置可解決: vue-cli中的 config/index.js 下配置 dev選項的 {proxyTable}:
 
proxyTable: {
'/api': {
target: '127.0.0.1:8889', // 真實請求的地址
changeOrigin: true, // 是否跨域
}
}
如果你想在公司的vue項目中實現前后端聯調,不需要再使用類似於fiddler charles的抓包代理工具了,你只需要使用proxyTable這個配置項,把你需要請求的后端的服務器地址寫在target值里就OK了。

 

 
解決完跨域問題后,接下來Jack該想想怎么在一台服務器一個域名下進行聯調的問題了。比較常見的做法是前端在本地修改,本地查看,測試好了以后上傳到服務器,看看線上環境可不可以,OK的話一切都好;不行就本地接着改,然后在上傳。

 

 
聯調完之后,如何將前端打包的項目文件發給后端,這里也需要注意兩點:

 

 
(1)css、js和圖片等靜態文件

 

 
這時候的靜態文件在開發階段不需要任何考慮,按照你喜歡的相對路徑或者相對於項目的根路徑的形式寫就行了,因為早晚還得交給后端。但是,需要注意:

 

 
如果你采用 相對項目根路徑的書寫方式來寫你的靜態文件路徑 時,一定要先和后端商量好,將來項目部署的時候他會把你的前端整個項目放在哪里?如果不是根目錄下,你就掛了。比如:你的reset.css的路徑是 /exports/styles/common/reset.css ,后端把你前端項目放在了根目錄下的 frontEnd 文件夾下, reset.css 文件就報404了。

 

 
如果后端采用的java,你需要特別注意的是, tomcat的根目錄 並不是 webapps 文件,而后端項目默認是部署在 webapps/ROOT 文件下的,所以你如果使用了相對項目根路徑的書寫方式來寫你的靜態文件路徑時,對不起又是404了。

 

 
(2)ajax后端數據

 

 
因為現在唯一的一台服務器還是在后端程序猿那里,所以此時你還是可以寫絕對路徑(域名+請求路徑),利用hosts文件來改變域名映射實現聯調。
 
 

https://www.douban.com/note/686499733/?type=rec#sep

 

三、前端性能優化 

1.內容優化

(1)減少HTTP請求數

(3)避免重定向

(4)使用Ajax緩存

(5)延遲加載組件,預加載組件

(6)減少DOM元素數量

(7)避免404

2.服務器優化

(1)使用內容分發網絡(CDN):把網站內容分散到多個、處於不同地域位置的服務器上可以加快下載速度。

(2)GZIP壓縮

(3)設置ETag:ETags(Entity tags,實體標簽)是web服務器和瀏覽器用於判斷瀏覽器緩存中的內容和服務器中的原始內容是否匹配的一種機制。

(4)提前刷新緩沖區

(5)對Ajax請求使用GET方法

(6)避免空的圖像src

3.Cookie優化

(1)減小Cookie大小

(2)針對Web組件使用域名無關的Cookie

4.CSS優化

1)將CSS代碼放在HTML頁面的頂部

2)避免使用CSS表達式

(3)使用<link>來代替@import

(4)避免使用Filters

5.javascript優化

(1)將JavaScript腳本放在頁面的底部。

(2)將JavaScript和CSS作為外部文件來引用:在實際應用中使用外部文件可以提高頁面速度,因為JavaScript和CSS文件都能在瀏覽器中產生緩存。

(3)縮小JavaScript和CSS

(4)刪除重復的腳本

(5)最小化DOM的訪問:使用JavaScript訪問DOM元素比較慢。

(6)開發智能的事件處理程序

(7)javascript代碼注意:謹慎使用with,避免使用eval Function函數,減少作用域鏈查找。

6.圖像優化

(1)優化圖片大小

(2)通過CSS Sprites優化圖片

(3)不要在HTML中使用縮放圖片

(4)favicon.ico要小而且可緩存

 

四、前端安全問題

1.算法加密:

(1)   RSA加密

(2)   MD5加密

(3)   SHA256加密

推薦一個網址:https://www.haorooms.com/post/js_my_passwordjm


免責聲明!

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



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