Web系統開發構架再思考-先後端的徹底分離

前言

　　先後端徹底分離其實一直是Web開發人員的夢想,也一直是個人夢想,遙想當年,不管是直接在代碼裏面輸出HTML,仍是在HTML裏面嵌入各類代碼,都不能讓人感到滿意.期間的痛苦和糾結,我想全部Web開發人員都深有感觸.

因爲最近幾年一直在MS平臺,從Web Form到MVC,MS平臺雖然易用好學,但整合度過高而靈活性不足,一直沒有找到很好的先後端分離的思路. (Java平臺的兄弟若是已經有很是成熟的平臺和思路,最好能簡單留個言給個帖子地址或者技術名稱,不勝感激).

         ASP.NET的MVC模式的確是向先後端分離邁出了一大步,但我認爲目前的模式仍是不完全,我看過園內的一些文章,你們都認爲這是Controller層的問題,但我認爲仍是View層的問題,View層的輸出仍是須要通過Controller通道,也就是說Controller依然影響 "頁面渲染」的最終效果, 使得目前的MVC也僅僅只能是Servlet, JSP, Web Form的升級模式,離真正的先後端分離仍是有必定的距離.

不過,目前OWIN標準的出現和MS的自我革命,使我開始從新思考先後端分離的核心問題,結合以前Web開發遇到的問題和心得, 我但願能和你們一塊兒交流下這方面的思路和體會.

前提條件和必要性

從目前來看,Web開發技術的日益發展和Web系統需求的日益的提升,使得先後臺分離的條件日益成熟,而必要性也日益提升.我總結爲3句話來歸納就是:

前端無所不能,通道日益便利,需求日益明確.

HTML/CSS標準的發展使得前端表現日益豐富

　　在近年Web前端技術的競賽中,HTML5/CSS3顯然仍是是領跑者,它們標準的不斷髮展也給前端實現帶來了更多可能,介於這兩種技術是任何模式的必選,這裏就不加累述了.

JS框架的不斷髮展使得前端開發無限可能

　　經過不斷的發展和無數高手的努力,「JS能實現任何功能」已經不是一句笑談, 連」 Atwood定律」 這種略帶輕狂的言論也被愈來愈多人所接受.

現在,內有JQuery, Dojo這種簡單易用的基礎函數庫,外有AngularJS和BackBone這種牛逼閃閃的框架實現. 在JS的肩膀之上,前端開發事實上已經具有無限可能.

RESTful Api和Json的發展使得先後端交互日益便利

         固然,分離之後就存在交流的問題,如何快速,簡潔,有效,統一的在先後臺進行信息的交互,成爲分離之後必須考慮的問題.

         幸運的是, RESTful思想和Json數據標準的出現,使得這種交互日益便利,在前端,咱們耳熟能詳的JS技術和框架對RESTful和Json的支持能夠說已經水到渠成. 至於後端,無論什麼語言,什麼平臺都有很是成熟的方案.

先後端的不一樣發展趨勢使得先後端分離需求日益明顯

         衆所周知,Web開發自出現以來一直存在性能,表現和體驗的先天不足,但時至今日,事實已經並不是如此,一些看上去甚至比桌面程序更炫的應用和網站橫空出世,客戶也被吊足了胃口.Web開發桌面化已是沒法阻擋的潮流,而前端開發的需求應該會向更加註重界面表現,速度流暢,用戶體驗的方向發展,並且要求只會愈來愈高.

         而在後端,穩定,性能,安全,存儲,業務等核心問題依然是主流,因此先後端的需求必將日益分化,注重表現和注重內在的先後端開發人員必將須要適合本身的舞臺.

四大原則

因此我認爲將來Web開發,先後端的徹底分離應該是一個值得考慮的方向,個人想法比較簡單明瞭(可能比較簡單,但願你們多多斧正),看下圖:

 

要實現這種分離,我認爲有如下四大原則:

前端靜態化

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

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

常見問題解決探討

這裏我閱讀了幾位園內高手的文章:

夏天的森林 -關於大型網站技術演進的思考（十四）--網站靜態化處理—先後端分離

系統架構：Web應用架構的新趨勢---前端和後端分離的一點想法

呂大豹（Double.Lv）的一個簡單粗暴的先後端分離方案

常胤 先後端分離的思考與實踐（一）

能夠說受益不淺,而針對他們提出一些的問題,也嘗試在本身的構想下進行尋求解決方案:

頁面邏輯和呈現效果: 仍是剛剛的一句話,JS已經無所不能,依託於目前的各類JS函數庫和框架,在獲取到合理的數據之後,幾乎沒有作不出來的邏輯和效果. 我自己偏向於前端實現,對這點有疑問的朋友咱們能夠深刻交流. 至於有些園友提出的數據校驗,頁面白屏,路由控制,代碼複用等等問題,前端技術已經徹底能夠解決.

服務器性能和優化: 因爲前端內容是徹底的靜態內容,在初次獲取之後的大部分時間內,瀏覽器使用的就是本地緩存,也就是說,服務器的壓力主要來自於承載數據的RESTFul Api調用,壓力的大幅下降不言而喻.加上對交互數據的合理設計,能夠說對客戶端-服務端的交互量控制已經接近極限.

安全性: 因爲前端靜態內容僅僅只能獲取,然後端只能接受Json,應該說,屏蔽了大量可能發生的注入型問題,而一些其餘問題,好比非法對象,數據加密,DDOS等問題,這些自己就是後端人員沒法迴避的責任,在任何模式下都必須考慮.

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

企業級構架考慮:  前端考慮搭建CDN,後端考慮負載均衡,數據庫優化和分佈式設計.關鍵問題是,先後端構架能夠分開考慮,各自交給其專業人員去架設.

測試: 前端JS已經出現很是優秀的單元測試框架(AngularJS),然後端RESTFul測試技術早已得心應手.

SEO:  的確是一個問題,但經過OWIN或者其餘HTTP Module橋接技術,轉接一部分HTTP路由到SEO功能並不是難事.

開發技術: 前端人員只須要學習HTML/CSS/JS,然後端人員只須要學習後端語言.幾乎不須要穿插.

Ajax跨域: 若是遠程調用或者內部少許調用,能夠考慮後端轉接和JSONP,內部構架分離能夠考慮CORS.