前端靜態(tài)化

前端有且僅有靜態(tài)內(nèi)容,再明確些,只有HTML/CSS/JS. 其內(nèi)容來(lái)自于完全靜態(tài)的資源而不需要任何后臺(tái)技術(shù)進(jìn)行動(dòng)態(tài)化組裝.前端內(nèi)容的運(yùn)行環(huán)境和引擎完全基于瀏覽器本身.

后端數(shù)據(jù)化

后端可以用任何語(yǔ)言,技術(shù)和平臺(tái)實(shí)現(xiàn),但它們必須遵循一個(gè)原則:只提供數(shù)據(jù),不提供任何和界面表現(xiàn)有關(guān)的內(nèi)容.換言之,他們提供的數(shù)據(jù)可以用于任何其他客戶(hù)端(如本地化程序,移動(dòng)端程序).

平臺(tái)無(wú)關(guān)化

前端3大技術(shù)本身就是平臺(tái)無(wú)關(guān)的,而后臺(tái)連接部分的本質(zhì)是實(shí)現(xiàn)合適的RESTful接口和交互Json數(shù)據(jù),就這2者而言,任何技術(shù)和平臺(tái)都可以實(shí)現(xiàn).

構(gòu)架分離化

前端架構(gòu)完全基于HTML/CSS的發(fā)展和JS框架的演變,與我們耳熟能詳?shù)暮笈_(tái)語(yǔ)言(如C#, Java, NodeJs等)完全無(wú)關(guān). 由于前臺(tái)是純靜態(tài)內(nèi)容,大型構(gòu)架方面可以考慮向CDN方向發(fā)展.

后端構(gòu)架幾乎可以基于任何語(yǔ)言和平臺(tái)的任何解決方案,大型構(gòu)架方面, RESTful Api可以考慮負(fù)載均衡;而數(shù)據(jù),業(yè)務(wù)實(shí)現(xiàn)等可以考慮數(shù)據(jù)庫(kù)優(yōu)化和分布式,這些領(lǐng)域園內(nèi)大牛如云,就不再班門(mén)弄斧了.

但總而言之,前后端的分離也實(shí)現(xiàn)了前后端構(gòu)架的分離.

分離模式的優(yōu)勢(shì) 
1、前后端流量大幅減少

我們知道,前后端流量的大頭是HTML/JS/IMG資源,而數(shù)據(jù)僅僅是小頭,資源占到100K以上的頁(yè)面不算大,但數(shù)據(jù)充其量10K左右,比如一個(gè)1萬(wàn)條記錄的數(shù)據(jù)經(jīng)過(guò)壓縮也僅僅在100K左右,而一個(gè)稍大的JS庫(kù)或圖片就不止這些.

流量的減少在于”前端靜態(tài)化”這個(gè)規(guī)則,在第一次獲取以后靜態(tài)資源會(huì)被瀏覽器緩存,即使瀏覽器繼續(xù)輪詢(xún),服務(wù)端也會(huì)返回一個(gè)非常小Not Modified響應(yīng),流量幾乎可以忽略不計(jì).

舉例說(shuō)明,在一個(gè)頁(yè)面為100K,數(shù)據(jù)為10K的頁(yè)面中,100次請(qǐng)求的流量是100K+10X100 = 1.1M. 顯而易見(jiàn),其流量是大幅低于每次獲取完整HTML的情況的.

2、表現(xiàn)性能的提高

也有人質(zhì)疑這種模式的頁(yè)面性能問(wèn)題,其實(shí)情況沒(méi)有那么悲觀: 第一次獲取的確會(huì)有些許損失,但我認(rèn)為,損失微乎其微,一個(gè)HTML頁(yè)面的加載,同時(shí)加載10多個(gè)幾十K的JS, Image的情況非常常見(jiàn),再多1-2個(gè)10K的Json也并非沉重負(fù)擔(dān).

但后續(xù)使用這個(gè)頁(yè)面,性能優(yōu)勢(shì)就完全體現(xiàn)了,頁(yè)面的絕大部分內(nèi)容都是本地緩存直接加載,遠(yuǎn)程獲取的僅僅是1-2個(gè)10K的內(nèi)容,其加載時(shí)間百毫秒內(nèi),這和本地頁(yè)面幾無(wú)區(qū)別,其前端加載和響應(yīng)速度得到非常大的提高是顯而易見(jiàn)的.

3、前后端平臺(tái)無(wú)關(guān)和技術(shù)無(wú)關(guān)

前端是純HTML技術(shù),前端人員只需要記事本就可以開(kāi)發(fā)并非一句”戲言”,而后端能夠?qū)崿F(xiàn)RESTful的框架和平臺(tái)比比皆是, 完全可以選擇更適合團(tuán)隊(duì),人員和公司的技術(shù)路線(xiàn)而不在糾結(jié)于平臺(tái)和技術(shù)的選擇.

4、安全性方面的集中優(yōu)化

前端靜態(tài)化以后,前端頁(yè)面攻擊幾無(wú)可能,一些注入式攻擊在分離模式下被很好的規(guī)避; 而后端安全問(wèn)題集中化了,僅僅只處理一個(gè)RESEful接口的安全考慮,安全架設(shè)和集中優(yōu)化變得更明確和便利.

5、開(kāi)發(fā)的分離和構(gòu)架的分離

也許很多團(tuán)隊(duì)還是1個(gè)開(kāi)發(fā)人員全包前后端的模式,但我也提到了,前端的要求越來(lái)越高,前后端人員的需求分化日益明顯,一旦系統(tǒng)上級(jí)別上檔次,其分離的需求必將出現(xiàn).

前后端人員的完全分離可以使得他們?cè)诟髯灶I(lǐng)域進(jìn)一步求深求專(zhuān),成為更加專(zhuān)業(yè)的高手;另外,前后端的構(gòu)架也可以分開(kāi)考慮和架設(shè),前端構(gòu)架就能集中考慮性能和優(yōu)化,而業(yè)務(wù),安全和存儲(chǔ)等問(wèn)題就能集中到后端考慮.

可以說(shuō)受益匪淺,而針對(duì)他們提出一些的問(wèn)題,也嘗試在自己的構(gòu)想下進(jìn)行尋求解決方案:

頁(yè)面邏輯和呈現(xiàn)效果: 還是剛剛的一句話(huà),JS已經(jīng)無(wú)所不能,依托于目前的各種JS函數(shù)庫(kù)和框架,在獲取到合理的數(shù)據(jù)以后,幾乎沒(méi)有做不出來(lái)的邏輯和效果. 我本身偏向于前端實(shí)現(xiàn),對(duì)這點(diǎn)有疑問(wèn)的朋友我們可以深入交流. 至于有些園友提出的數(shù)據(jù)校驗(yàn),頁(yè)面白屏,路由控制,代碼復(fù)用等等問(wèn)題,前端技術(shù)已經(jīng)完全可以解決.

6、服務(wù)器性能和優(yōu)化: 由于前端內(nèi)容是完全的靜態(tài)內(nèi)容,在初次獲取以后的大部分時(shí)間內(nèi),瀏覽器使用的就是本地緩存,也就是說(shuō),服務(wù)器的壓力主要來(lái)自于承載數(shù)據(jù)的Restful Api調(diào)用,壓力的大幅降低不言而喻.加上對(duì)交互數(shù)據(jù)的合理設(shè)計(jì),可以說(shuō)對(duì)客戶(hù)端-服務(wù)端的交互量控制已經(jīng)接近極限.

7、安全性: 由于前端靜態(tài)內(nèi)容僅僅只能獲取,而后端只能接受Json,應(yīng)該說(shuō),屏蔽了大量可能發(fā)生的注入型問(wèn)題,而一些其他問(wèn)題,比如非法對(duì)象,數(shù)據(jù)加密,DDOS等問(wèn)題,這些本身就是后端人員無(wú)法回避的責(zé)任,在任何模式下都必須考慮.

跨平臺(tái),跨技術(shù): 正如剛剛所所說(shuō), 前端技術(shù)本身無(wú)平臺(tái)限制,而后端幾乎任何平臺(tái)都能實(shí)現(xiàn).

實(shí)現(xiàn)

前后端人員雙方約定好接口的數(shù)據(jù)格式，比如：前端需要調(diào)用一個(gè)用戶(hù)信息的接口，數(shù)據(jù)格式為{name:”,gender:”}，那么，后端人員只需要告訴他一個(gè)接口url（如： http://192.168.1.2:8080/pro/userInfo），并且將這個(gè)接口返回前端想要的數(shù)據(jù)即可，至于后端人員怎么實(shí)現(xiàn)這個(gè)接口，前端人員并不關(guān)心！ 
前端頁(yè)面用ajax解析url，獲取數(shù)據(jù)進(jìn)行頁(yè)面端的處理，然后再按照上述地址返回給后端，就想APP和后臺(tái)接口對(duì)接是一個(gè)道理。 
至于前端人員要用這個(gè)接口來(lái)做什么，后端人員同樣不需要關(guān)心！雙方都只專(zhuān)注于自己需要實(shí)現(xiàn)的業(yè)務(wù)邏輯。

順便說(shuō)一下AMS7.0預(yù)計(jì)年內(nèi)發(fā)布，AMS主程序全部用C++開(kāi)發(fā)，AMS通過(guò)REST API提供所有接口，并提供Web容器，AMS7將 采用JS + CSS +HTML提供一套全新的基于前后端分離技術(shù)的Web頁(yè)面，基于復(fù)雜直播、點(diǎn)播、轉(zhuǎn)碼、設(shè)備管理，用戶(hù)管理，系統(tǒng)功能等功能皆可完美呈現(xiàn)。