1. 程式人生 > >對於前後端分離技術的理解和實現

對於前後端分離技術的理解和實現

前端靜態化

前端有且僅有靜態內容,再明確些,只有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個開發人員全包前後端的模式,但我也提到了,前端的要求越來越高,前後端人員的需求分化日益明顯,一旦系統上級別上檔次,其分離的需求必將出現.

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

可以說受益匪淺,而針對他們提出一些的問題,也嘗試在自己的構想下進行尋求解決方案:

頁面邏輯和呈現效果: 還是剛剛的一句話,JS已經無所不能,依託於目前的各種JS函式庫和框架,在獲取到合理的資料以後,幾乎沒有做不出來的邏輯和效果. 我本身偏向於前端實現,對這點有疑問的朋友我們可以深入交流. 至於有些園友提出的資料校驗,頁面白屏,路由控制,程式碼複用等等問題,前端技術已經完全可以解決.

伺服器效能和優化: 由於前端內容是完全的靜態內容,在初次獲取以後的大部分時間內,瀏覽器使用的就是本地快取,也就是說,伺服器的壓力主要來自於承載資料的RESTFul Api呼叫,壓力的大幅降低不言而喻.加上對互動資料的合理設計,可以說對客戶端-服務端的互動量控制已經接近極限.

安全性: 由於前端靜態內容僅僅只能獲取,而後端只能接受Json,應該說,遮蔽了大量可能發生的注入型問題,而一些其他問題,比如非法物件,資料加密,DDOS等問題,這些本身就是後端人員無法迴避的責任,在任何模式下都必須考慮.

跨平臺,跨技術: 正如剛剛所所說, 前端技術本身無平臺限制,而後端幾乎任何平臺都能實現.

實現

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