前后端完全分離其實(shí)一直是Web開(kāi)發(fā)人員的夢(mèng)想,也一直是我的夢(mèng)想,遙想當(dāng)年,無(wú)論是直接在代碼里面輸出HTML,還是在HTML里面嵌入各種代碼,都不能讓人感到滿意.期間的痛苦和糾結(jié),我想所有Web開(kāi)發(fā)人員都深有感觸.
由于最近幾年一直在MS平臺(tái),從Web Form到MVC,MS平臺(tái)雖然易用好學(xué),但整合度太高而靈活性不足,一直沒(méi)有找到很好的前后端分離的思路. (Java平臺(tái)的兄弟如果已經(jīng)有非常成熟的平臺(tái)和思路,最好能簡(jiǎn)單留個(gè)言給個(gè)帖子地址或者技術(shù)名稱(chēng),不勝感激).
ASP.NET的MVC模式的確是向前后端分離邁出了一大步,但我認(rèn)為目前的模式還是不徹底,我看過(guò)園內(nèi)的一些文章,大家都認(rèn)為這是Controller 層的問(wèn)題,但我認(rèn)為還是View層的問(wèn)題,View層的輸出還是需要經(jīng)過(guò)Controller通道,也就是說(shuō)Controller依然影響 "頁(yè)面渲染”的最終效果, 使得目前的MVC也僅僅只能是Servlet, JSP, Web Form的升級(jí)模式,離真正的前后端分離還是有一定的距離.
不過(guò),目前OWIN標(biāo)準(zhǔn)的出現(xiàn)和MS的自我革命,使我開(kāi)始重新思考前后端分離的核心問(wèn)題,結(jié)合之前Web開(kāi)發(fā)遇到的問(wèn)題和心得, 我希望能和大家一起交流下這方面的思路和體會(huì).
前提條件和必要性
從目前來(lái)看,Web開(kāi)發(fā)技術(shù)的日益發(fā)展和Web系統(tǒng)需求的日益的提高,使得前后臺(tái)分離的條件日益成熟,而必要性也日益提高.我總結(jié)為3句話來(lái)概括就是:
前端無(wú)所不能,通道日益便利,需求日益明確.
HTML/CSS標(biāo)準(zhǔn)的發(fā)展使得前端表現(xiàn)日益豐富
在近年Web前端技術(shù)的競(jìng)賽中,HTML5/CSS3顯然還是是領(lǐng)跑者,它們標(biāo)準(zhǔn)的不斷發(fā)展也給前端實(shí)現(xiàn)帶來(lái)了更多可能,介于這兩種技術(shù)是任何模式的必選,這里就不加累述了.
JS框架的不斷發(fā)展使得前端開(kāi)發(fā)無(wú)限可能
通過(guò)不斷的發(fā)展和無(wú)數(shù)高手的努力,“JS能實(shí)現(xiàn)任何功能”已經(jīng)不是一句笑談, 連” Atwood定律” 這種略帶輕狂的言論也被越來(lái)越多人所接受.
如今,內(nèi)有JQuery, Dojo這種簡(jiǎn)單易用的基礎(chǔ)函數(shù)庫(kù),外有AngularJS和BackBone這種牛逼閃閃的框架實(shí)現(xiàn). 在JS的肩膀之上,前端開(kāi)發(fā)事實(shí)上已經(jīng)具備無(wú)限可能.
RESTful Api和Json的發(fā)展使得前后端交互日益便利
當(dāng)然,分離以后就存在交流的問(wèn)題,如何快速,簡(jiǎn)潔,有效,統(tǒng)一的在前后臺(tái)進(jìn)行信息的交互,成為分離以后必須考慮的問(wèn)題.
幸運(yùn)的是, RESTful思想和Json數(shù)據(jù)標(biāo)準(zhǔn)的出現(xiàn),使得這種交互日益便利,在前端,我們耳熟能詳?shù)腏S技術(shù)和框架對(duì)RESTful和Json的支持可以說(shuō)已經(jīng)水到渠成. 至于后端,不管什么語(yǔ)言,什么平臺(tái)都有非常成熟的方案.
前后端的不同發(fā)展趨勢(shì)使得前后端分離需求日益明顯
眾所周知,Web開(kāi)發(fā)自出現(xiàn)以來(lái)一直存在性能,表現(xiàn)和體驗(yàn)的先天不足,但時(shí)至今日,事實(shí)已經(jīng)并非如此,一些看上去甚至比桌面程序更炫的應(yīng)用和網(wǎng)站橫空出 世,客戶(hù)也被吊足了胃口.Web開(kāi)發(fā)桌面化已經(jīng)是無(wú)法阻擋的潮流,而前端開(kāi)發(fā)的需求應(yīng)該會(huì)向更加注重界面表現(xiàn),速度流暢,用戶(hù)體驗(yàn)的方向發(fā)展,而且要求只 會(huì)越來(lái)越高.
而在后端,穩(wěn)定,性能,安全,存儲(chǔ),業(yè)務(wù)等核心問(wèn)題依然是主流,所以前后端的需求必將日益分化,注重表現(xiàn)和注重內(nèi)在的前后端開(kāi)發(fā)人員必將需要適合自己的舞臺(tái).
四大原則
所以我認(rèn)為未來(lái)Web開(kāi)發(fā),前后端的完全分離應(yīng)該是一個(gè)值得考慮的方向,我的想法比較簡(jiǎn)單明了(可能比較簡(jiǎn)單,希望大家多多斧正),看下圖:
要實(shí)現(xiàn)這種分離,我認(rèn)為有以下四大原則:
前端靜態(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)架的分離.
常見(jiàn)問(wèn)題解決探討
這里我閱讀了幾位園內(nèi)高手的文章:
夏天的森林 -關(guān)于大型網(wǎng)站技術(shù)演進(jìn)的思考（十四）--網(wǎng)站靜態(tài)化處理—前后端分離
系統(tǒng)架構(gòu)：Web應(yīng)用架構(gòu)的新趨勢(shì)---前端和后端分離的一點(diǎn)想法
呂大豹（Double.Lv）的一個(gè)簡(jiǎn)單粗暴的前后端分離方案
可以說(shuō)受益匪淺,而針對(duì)他們提出一些的問(wèn)題,也嘗試在自己的構(gòu)想下進(jìn)行尋求解決方案:
頁(yè)面邏輯和呈現(xiàn)效果: 還是剛剛的一句話,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)完全可以解決.
服務(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)接近極限.
安全性: 由于前端靜態(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).
企業(yè)級(jí)構(gòu)架考慮: 前端考慮搭建CDN,后端考慮負(fù)載均衡,數(shù)據(jù)庫(kù)優(yōu)化和分布式設(shè)計(jì).關(guān)鍵問(wèn)題是,前后端構(gòu)架可以分開(kāi)考慮,各自交給其專(zhuān)業(yè)人員去架設(shè).
測(cè)試: 前端JS已經(jīng)出現(xiàn)非常優(yōu)秀的單元測(cè)試框架(AngularJS),而后端RESTFul測(cè)試技術(shù)早已駕輕就熟.
SEO: 的確是一個(gè)問(wèn)題,但通過(guò)OWIN或者其他HTTP Module橋接技術(shù),轉(zhuǎn)接一部分HTTP路由到SEO功能并非難事.
開(kāi)發(fā)技術(shù): 前端人員只需要學(xué)習(xí)HTML/CSS/JS,而后端人員只需要學(xué)習(xí)后端語(yǔ)言.幾乎不需要穿插.
Ajax跨域: 如果遠(yuǎn)程調(diào)用或者內(nèi)部少量調(diào)用,可以考慮后端轉(zhuǎn)接和JSONP,內(nèi)部構(gòu)架分離可以考慮CORS.
