Web研發模式演變史

從架構改進看思維變化
服務器君一共花費了161.490 ms進行了5次數據庫查詢,努力地為您提供了這個頁面。
試試閱讀模式?希望聽取您的建議

轉玉伯的一篇文章,對Web開發的歷史發展的了解很有裨益,推薦給大家。

前不久徐飛寫了一篇很好的文章:Web 應用的組件化開發。本文嘗試從歷史發展角度,說說各種研發模式的優劣。

一、簡單明快的早期時代

可稱之為 Web 1.0 時代,非常適合創業型小項目,不分前后端,經常 3-5 人搞定所有開發。頁面由 JSP、PHP 等工程師在服務端生成,瀏覽器負責展現。基本上是服務端給什么瀏覽器就展現什么,展現的控制在 Web Server 層。

這種模式的好處是:簡單明快,本地起一個 Tomcat 或 Apache 就能開發,調試什么的都還好,只要業務不太復雜。

然而業務總會變復雜,這是好事情,否則很可能就意味著創業失敗了。業務的復雜會讓 Service 越來越多,參與開發的人員也很可能從幾個人快速擴招到幾十人。在這種情況下,會遇到一些典型問題:

1、Service 越來越多,調用關系變復雜,前端搭建本地環境不再是一件簡單的事。考慮團隊協作,往往會考慮搭建集中式的開發服務器來解決。這種解決方案對編譯型的后端開發來說也許還好,但對前端開發來說并不友好。天哪,我只是想調整下按鈕樣式,卻要本地開發、代碼上傳、驗證生效等好幾個步驟。也許習慣了也還好,但開發服務器總是不那么穩定,出問題時往往需要依賴后端開發搞定。看似僅僅是前端開發難以本地化,但這對研發效率的影響其實蠻大。

2、JSP 等代碼的可維護性越來越差。JSP 非常強大,可以內嵌 Java 代碼。這種強大使得前后端的職責不清晰,JSP 變成了一個灰色地帶。經常為了趕項目,為了各種緊急需求,會在 JSP 里揉雜大量業務代碼。積攢到一定階段時,往往會帶來大量維護成本。

這個時期,為了提高可維護性,可以通過下面的方式實現前端的組件化:

理論上,如果大家都能按照最佳實踐去書寫代碼,那么無論是 JSP 還是 PHP,可維護性都不會差。但可維護性更多是工程含義,有時候需要通過限制帶來自由,需要某種約定,使得即便是新手也不會寫出太糟糕的代碼。

如何讓前后端分工更合理高效,如何提高代碼的可維護性,在 Web 開發中很重要。下面我們繼續來看,技術架構的演變如何解決這兩個問題。

二、后端為主的 MVC 時代

為了降低復雜度,以后端為出發點,有了 Web Server 層的架構升級,比如 Structs、Spring MVC 等,這是后端的 MVC 時代。

代碼可維護性得到明顯好轉,MVC 是個非常好的協作模式,從架構層面讓開發者懂得什么代碼應該寫在什么地方。為了讓 View 層更簡單干脆,還可以選擇 Velocity、Freemaker 等模板,使得模板里寫不了 Java 代碼。看起來是功能變弱了,但正是這種限制使得前后端分工更清晰。然而依舊并不是那么清晰,這個階段的典型問題是:

1、前端開發重度依賴開發環境。這種架構下,前后端協作有兩種模式:一種是前端寫 demo,寫好后,讓后端去套模板。淘寶早期包括現在依舊有大量業務線是這種模式。好處很明顯,demo 可以本地開發,很高效。不足是還需要后端套模板,有可能套錯,套完后還需要前端確定,來回溝通調整的成本比較大。另一種協作模式是前端負責瀏覽器端的所有開發和服務器端的 View 層模板開發,支付寶是這種模式。好處是 UI 相關的代碼都是前端去寫就好,后端不用太關注,不足就是前端開發重度綁定后端環境,環境成為影響前端開發效率的重要因素。

2、前后端職責依舊糾纏不清。Velocity 模板還是蠻強大的,變量、邏輯、宏等特性,依舊可以通過拿到的上下文變量來實現各種業務邏輯。這樣,只要前端弱勢一點,往往就會被后端要求在模板層寫出不少業務代碼。還有一個很大的灰色地帶是 Controller,頁面路由等功能本應該是前端最關注的,但卻是由后端來實現。Controller 本身與 Model 往往也會糾纏不清,看了讓人咬牙的代碼經常會出現在 Controller 層。這些問題不能全歸結于程序員的素養,否則 JSP 就夠了。

經常會有人吐槽 Java,但 Java 在工程化開發方面真的做了大量思考和架構嘗試。Java 蠻符合馬云的一句話:讓平凡人做非凡事。

三、Ajax 帶來的 SPA 時代

歷史滾滾往前,2004 年 Gmail 像風一樣的女子來到人間,很快 2005 年 Ajax 正式提出,加上 CDN 開始大量用于靜態資源存儲,于是出現了 JavaScript 王者歸來的 SPA (Single Page Application 單頁面應用)時代。

這種模式下,前后端的分工非常清晰,前后端的關鍵協作點是 Ajax 接口。看起來是如此美妙,但回過頭來看看的話,這與 JSP 時代區別不大。復雜度從服務端的 JSP 里移到了瀏覽器的 JavaScript,瀏覽器端變得很復雜。類似 Spring MVC,這個時代開始出現瀏覽器端的分層架構:

對于 SPA 應用,有幾個很重要的挑戰:

1、前后端接口的約定。如果后端的接口一塌糊涂,如果后端的業務模型不夠穩定,那么前端開發會很痛苦。這一塊在業界有 API Blueprint 等方案來約定和沉淀接口,在阿里,不少團隊也有類似嘗試,通過接口規則、接口平臺等方式來做。有了和后端一起沉淀的接口規則,還可以用來模擬數據,使得前后端可以在約定接口后實現高效并行開發。相信這一塊會越做越好。

2、前端開發的復雜度控制。SPA 應用大多以功能交互型為主,JavaScript 代碼過十萬行很正常。大量 JS 代碼的組織,與 View 層的綁定等,都不是容易的事情。典型的解決方案是業界的 Backbone,但 Backbone 做的事還很有限,依舊存在大量空白區域需要挑戰。

SPA 讓前端看到了一絲綠色,但依舊是在荒漠中行走。

四、前端為主的 MV* 時代

為了降低前端開發復雜度,除了 Backbone,還有大量框架涌現,比如 EmberJS、KnockoutJS、AngularJS 等等。這些框架總的原則是先按類型分層,比如 Templates、Controllers、Models,然后再在層內做切分,如下圖:

好處很明顯:

1、前后端職責很清晰。前端工作在瀏覽器端,后端工作在服務端。清晰的分工,可以讓開發并行,測試數據的模擬不難,前端可以本地開發。后端則可以專注于業務邏輯的處理,輸出 RESTful 等接口。

2、前端開發的復雜度可控。前端代碼很重,但合理的分層,讓前端代碼能各司其職。這一塊蠻有意思的,簡單如模板特性的選擇,就有很多很多講究。并非越強大越好,限制什么,留下哪些自由,代碼應該如何組織,所有這一切設計,得花一本的厚度去說明。

3、部署相對獨立,產品體驗可以快速改進。

但依舊有不足之處:

  1. 代碼不能復用。比如后端依舊需要對數據做各種校驗,校驗邏輯無法復用瀏覽器端的代碼。如果可以復用,那么后端的數據校驗可以相對簡單化。
  2. 全異步,對 SEO 不利。往往還需要服務端做同步渲染的降級方案。
  3. 性能并非最佳,特別是移動互聯網環境下。
  4. SPA 不能滿足所有需求,依舊存在大量多頁面應用。URL Design 需要后端配合,前端無法完全掌控。

五、Node 帶來的全棧時代

前端為主的 MV* 模式解決了很多很多問題,但如上所述,依舊存在不少不足之處。隨著 Node.js 的興起,JavaScript 開始有能力運行在服務端。這意味著可以有一種新的研發模式:

在這種研發模式下,前后端的職責很清晰。對前端來說,兩個 UI 層各司其職:

1、Front-end UI layer 處理瀏覽器層的展現邏輯。通過 CSS 渲染樣式,通過 JavaScript 添加交互功能,HTML 的生成也可以放在這層,具體看應用場景。

2、Back-end UI layer 處理路由、模板、數據獲取、cookie 等。通過路由,前端終于可以自主把控 URL Design,這樣無論是單頁面應用還是多頁面應用,前端都可以自由調控。后端也終于可以擺脫對展現的強關注,轉而可以專心于業務邏輯層的開發。

通過 Node,Web Server 層也是 JavaScript 代碼,這意味著部分代碼可前后復用,需要 SEO 的場景可以在服務端同步渲染,由于異步請求太多導致的性能問題也可以通過服務端來緩解。前一種模式的不足,通過這種模式幾乎都能完美解決掉。

與 JSP 模式相比,全棧模式看起來是一種回歸,也的確是一種向原始開發模式的回歸,不過是一種螺旋上升式的回歸。

基于 Node 的全棧模式,依舊面臨很多挑戰:

  1. 需要前端對服務端編程有更進一步的認識。比如 network/tcp、PE 等知識的掌握。
  2. Node 層與 Java 層的高效通信。Node 模式下,都在服務器端,RESTful HTTP 通信未必高效,通過 SOAP 等方式通信更高效。一切需要在驗證中前行。
  3. 對部署、運維層面的熟練了解,需要更多知識點和實操經驗。
  4. 大量歷史遺留問題如何過渡。這可能是最大最大的阻力。

六、小結

回顧歷史總是讓人感慨,展望未來則讓人興奮。上面講到的研發模式,除了最后一種還在探索期,其他各種在各大公司都已有大量實踐。幾點小結:

  1. 模式沒有好壞高下之分,只有合不合適。
  2. Ajax 給前端開發帶來了一次質的飛躍,Node 很可能是第二次。
  3. SoC(關注度分離) 是一條偉大的原則。上面種種模式,都是讓前后端的職責更清晰,分工更合理高效。
  4. 還有個原則,讓合適的人做合適的事。比如 Web Server 層的 UI Layer 開發,前端是更合適的人選。

歷史有時候會打轉,咋一看以為是回去了,實際上是螺旋轉了一圈,站在了一個新的起點。

(完)

題圖:演化真不容易呀。

本文地址:http://www.snpmgr.live/librarys/veda/detail/2589,歡迎訪問原出處。

不打個分嗎?

轉載隨意,但請帶上本文地址:

http://www.snpmgr.live/librarys/veda/detail/2589

如果你認為這篇文章值得更多人閱讀,歡迎使用下面的分享功能。
小提示:您可以按快捷鍵 Ctrl + D,或點此 加入收藏

大家都在看

閱讀一百本計算機著作吧,少年

很多人覺得自己技術進步很慢,學習效率低,我覺得一個重要原因是看的書少了。多少是多呢?起碼得看3、4、5、6米吧。給個具體的數量,那就100本書吧。很多人知識結構不好而且不系統,因為在特定領域有一個足夠量的知識量+足夠良好的知識結構,系統化以后就足以應對大量未曾遇到過的問題。

奉勸自學者:構建特定領域的知識結構體系的路徑中再也沒有比學習該專業的專業課程更好的了。如果我的知識結構體系足以囊括面試官的大部分甚至吞并他的知識結構體系的話,讀到他言語中的一個詞我們就已經知道他要表達什么,我們可以讓他坐“上位”畢竟他是面試官,但是在知識結構體系以及心理上我們就居高臨下。

所以,閱讀一百本計算機著作吧,少年!

《高性能JavaScript》 Nicholas C. Zakas (作者), 趙澤欣 (合著者), 丁琛 (譯者)

《高性能JavaScript》揭示的技術和策略能幫助你在開發過程中消除性能瓶頸。你將會了解如何提升各方面的性能,包括代碼的加載、運行、DOM 交互、頁面生存周期等。雅虎的前端工程師 Nicholas C. Zakas 和其他五位 JavaScript 專家介紹了頁面代碼加載的最佳方法和編程技巧,來幫助你編寫更為高效和快速的代碼。你還會了解到構建和部署文件到生產環境的最佳實踐,以及有助于定位線上問題的工具。如果你使用 JavaScript 構建交互豐富的 Web 應用,那么 JavaScript 代碼可能是造成你的Web應用速度變慢的主要原因。

更多計算機寶庫...

燃烧吧足球登陆