閱讀680 返回首頁    go 阿裏雲 go 技術社區[雲棲]


前後端分離狀態下的工作與交互

為什麼要前後端分離

前後端職責不清

在業務邏輯複雜的係統裏,我們最怕維護前後端混雜在一起的代碼,因為沒有約束,M-V-C每一層都可能出現別的層的代碼,日積月累,完全沒有維護性可言

雖然前後端分離沒辦法完全解決這種問題,但是可以大大緩解。因為從物理層次上保證了你不可能這麼做

開發效率問題

淘寶的Web基本上都是基於MVC框架webx,架構決定了前端隻能依賴後端。所以開發模式:前端寫好靜態demo,後端翻譯成VM模版,這種模式的問題就不說了,被吐槽了很久

直接基於後端環境開發也很痛苦,配置安裝使用都很麻煩。為了解決這個問題,我們發明了各種工具,比如VMarket,但是前端還是要寫VM,而且依賴後端數據,效率依然不高。另外,後端也沒法擺脫對展現的強關注,從而專心於業務邏輯層的開發

對前端發揮的局限

性能優化如果隻在前端做空間非常有限,於是我們經常需要後端合作才能碰撞出火花,但由於後端框架限製,我們很難使用Comet、Bigpipe等技術方案來優化性能

怎麼做前後端分離?

前端:負責View和Controller層

後端:負責Model層,業務處理/數據等

前後端人員雙方約定好接口的數據格式,比如:前端需要調用一個用戶信息的接口,數據格式為{name:”,gender:”},那麼,後端人員隻需要告訴他一個接口url(如:https://192.168.1.2:8080/pro/userInfo),並且將這個接口返回前端想要的數據即可,至於後端人員怎麼實現這個接口,前端人員並不關心!
前端頁麵用ajax解析url,獲取數據進行頁麵端的處理,然後再按照上述地址返回給後端,就想APP和後台接口對接是一個道理。
至於前端人員要用這個接口來做什麼,後端人員同樣不需要關心!雙方都隻專注於自己需要實現的業務邏輯

前後端分離的優勢

前端靜態化

前端有且僅有靜態內容,再明確些,隻有HTML/CSS/js. 其內容來自於完全靜態的資源而不需要任何後台技術進行動態化組裝.前端內容的運行環境和引擎完全基於瀏覽器本身

後端數據化

後端可以用任何語言,技術和平台實現,但它們必須遵循一個原則:隻提供數據,不提供任何和界麵表現有關的內容.換言之,他們提供的數據可以用於任何其他客戶端(如本地化程序,移動端程序)

平台無關化

前端3大技術本身就是平台無關的,而後台連接部分的本質是實現合適的RESTful接口和交互Json數據,就這2者而言,任何技術和平台都可以實現

構架分離化

前端架構完全基於HTML/CSS的發展和JS框架的演變,與我們耳熟能詳的後台語言(如C#, Java, NodeJs等)完全無關. 由於前台是純靜態內容,大型構架方麵可以考慮向CDN方向發展.

後端構架幾乎可以基於任何語言和平台的任何解決方案,大型構架方麵, RESTful Api可以考慮負載均衡;而數據,業務實現等可以考慮數據庫優化和分布式

但總而言之,前後端的分離也實現了前後端構架的分離

前後端流量大幅減少

我們知道,前後端流量的大頭是HTML/JS/IMG資源,而數據僅僅是小頭,資源占到100K以上的頁麵不算大,但數據充其量10K左右,比如一個1萬條記錄的數據經過壓縮也僅僅在100K左右,而一個稍大的JS庫或圖片就不止這些.

流量的減少在於”前端靜態化”這個規則,在第一次獲取以後靜態資源會被瀏覽器緩存,即使瀏覽器繼續輪詢,服務端也會返回一個非常小Not Modified響應,流量幾乎可以忽略不計.

舉例說明,在一個頁麵為100K,數據為10K的頁麵中,100次請求的流量是100K+10X100 = 1.1M. 顯而易見,其流量是大幅低於每次獲取完整HTML的情況的

表現性能的提高

有人質疑這種模式的頁麵性能問題,其實情況沒有那麼悲觀: 第一次獲取的確會有些許損失,但我認為,損失微乎其微,一個HTML頁麵的加載,同時加載10多個幾十K的JS, Image的情況非常常見,再多1-2個10K的Json也並非沉重負擔.

但後續使用這個頁麵,性能優勢就完全體現了,頁麵的絕大部分內容都是本地緩存直接加載,遠程獲取的僅僅是1-2個10K的內容,其加載時間百毫秒內,這和本地頁麵幾無區別,其前端加載和響應速度得到非常大的提高是顯而易見的.

前後端平台無關和技術無關

前端是純HTML技術,前端人員隻需要記事本就可以開發並非一句”戲言”,而後端能夠實現RESTful的框架和平台比比皆是, 完全可以選擇更適合團隊,人員和公司的技術路線而不在糾結於平台和技術的選擇

安全性方麵的集中優化

前端靜態化以後,前端頁麵攻擊幾無可能,一些注入式攻擊在分離模式下被很好的規避; 而後端安全問題集中化了,僅僅隻處理一個RESEful接口的安全考慮,安全架設和集中優化變得更明確和便利

開發的分離和構架的分離

也許很多團隊還是1個開發人員全包前後端的模式,但前端的要求越來越高,前後端人員的需求分化日益明顯,一旦係統上級別上檔次,其分離的需求必將出現.

前後端人員的完全分離可以使得他們在各自領域進一步求深求專,成為更加專業的高手;另外,前後端的構架也可以分開考慮和架設,前端構架就能集中考慮性能和優化,而業務,安全和存儲等問題就能集中到後端考慮

最後更新:2017-06-13 15:31:37

  上一篇:go  《深入解析IPv6(第3版)》——11.5 參考資料
  下一篇:go  企業網站建設|優秀的網站都是靠這些細節做成功的