1. 程式人生 > >轉Web開發的發展史---Web開發技術的演變

轉Web開發的發展史---Web開發技術的演變

即使 包括 另一個 dlink 演變 取數據 等待 php 概念

轉自:http://blog.csdn.net/zzzkk2009/article/details/9849431

在接下來的幾個月時間裏,我打算寫一系列關於完整web開發的文章。這第一篇文章雖然有所粗略,但也能夠充分概括了在之前15年或者更久的時間裏web應用程序如何進行演變。並且最後我會囊括下這段時間內所寫的相關技術。

在過去的美好日子裏,我們使用的是簡單的web頁面(包括動態gif圖片!)。作為精美設計的典範,蘋果有著這樣的一個網站:

技術分享

在那時,Web開發還比較簡單,開發者經常會去操作web服務器(主要還是他自己的機器),並且他會寫一些HTML頁面放到服務器指定的文件夾(/www)下。這些HTML頁面,就在瀏覽器請求頁面時使用。

技術分享

問題就出現了,你只能獲取到靜態內容。倘若你想讓訪問者看到有多少其他訪問者訪問了這個網站呢(還記得那些統計流量的旋轉圖片嗎?!),或者倘若你想讓訪問者去填寫這樣一個表單,包含有姓名和郵件地址呢?於此就轉向了CGI和Perl腳本,在web服務器端運行一段短小的代碼,並能與文件系統或者數據庫進行交互。

技術分享

當時組織CGI/Perl這樣的腳本代碼太混亂了。CGI伸縮性不是太好(經常是為每個請求分配一個新的進程),也不太安全(直接使用文件系統或者環境變量),同時也沒提供一種結構化的方式去構造動態應用程序。幾年來一直很困惑,直到大約2005年左右,出現了Java Server Pages(JSP),微軟的ASP,以及PHP!我喜歡把當時的參考架構比作成IIS和ASP.NET,你可以用Visual Studio快速構建一個可伸縮並且安全的應用程序。

技術分享

直到當時,web服務器多半會返回整個頁面或者文檔,但AJAX(2005)的出現,讓事情變得很有意思。AJAX允許客戶端的JavaScript腳本為局部頁面提供請求服務,然後可以在無需回到服務器情況下動態刷新部分頁面,也就是更新瀏覽器中的document對象,通常稱作DOM,或者文檔對象模型。

雖然從服務器端返回的仍然是HTML,但瀏覽器上的代碼能把這HTML片段內嵌到當前頁面中。也就是說web應用的響應可以更快,這時我們真正用web應用取代了web頁面。谷歌的GMail和谷歌地圖都是當時AJAX的殺手級產品。隨後用AJAX局部刷新就如雨後春筍般出現。

技術分享

在隨後的幾年時間裏,AJAX成為了焦點,但在服務器端仍然使用著舊有的技術。大概在2007年,37signals公司公開其成員–Ruby on Rails。那個基於Ruby on Rails 5分鐘構建博客的演示完全征服了全世界的開發者。一夜之間,所以談論的焦點都是關於Rails!Rails的不同之處在於使用規定的方式去設計你的web應用程序,運用一種已經廣泛在桌面應用開發,但未被搬到web應用上的開發模式。這種模式就叫做模式(數據)-視圖(模板)-控制器(業務邏輯)。Rails強調,“這事就該這麽做”,並且通過許多插件讓構建web應用再一次更加健全。

技術分享

在2007到2010年期間,湧現了3種開發潮流:

第一個是智能手機和移動應用潮流。通常情況下,許多應用程序同時有web和移動應用兩種版本。盡管如此,服務端仍然返回的是HTML頁面,而不是其它移動應用可以識別。因此,你需要返回的是結構化數據來取代HTML。

第二個開發潮流是jQuery。這是一個非常流行的JavaScript庫,能夠很容易構建動態、美妙的web應用,甚至是AJAX!

第三個潮流是Node.js的發布。這是第一次能讓你用JavaScript開發高性能的服務端程序,進而可能結束“客戶端開發者”要知道HTML/JavaScript,“服務端開發者”要知道.NET/C#/Ruby這樣的噩夢。

技術分享

盡管這是一個不錯的架構,但我們可以重用一些在客戶端的收獲去簡化那些曾經發生在像客戶端意大利面似的jQuery代碼。和Rails精神類似,我們需要用一種規定的方式從服務端獲取到數據,再對客戶端的HTML頁面進行包裝。因此,在接下來的2年時間裏,業界出現了許多用於簡化客戶端開發的框架,諸如Backbone,Ember,Derby和Meteor,當然也包括我的最愛,AngularJS。

技術分享

因此,這就是我們看到的今天,而我後面要講到的參考架構是這樣的,MongoDB作為數據庫服務器,node/express作為web應用服務器,客戶端使用AngularJS,同時也使用Bootstrap樣式風格。我發現這種架構允許我能夠快速構建web服務以及基於AngularJS的客戶端接口,甚至和其它的服務,如PhoneGap或者其它原生移動開發工具一樣,進行移動應用的開發。

技術分享

在接下來的幾個星期裏,我會發表一些文章來說明這些涉及到的組件,包括:MongoDB,Node/ExpressJS,JSON和REST接口,AngularJS,Karma-mocha測試和Bootstrap樣式風格頁面。

推薦閱讀:《Web開發技術的演變 》

受到好文《Web開發的發展史》(英文)激發的靈感,寫下我對web開發技術的認識。

1. 靜態頁面時代

大學時候,上機還得換卡穿拖鞋,Novell的網絡是很神奇的,然而更神奇的是通訊原理老師半神秘的講他上 Internet,“Cernet(教育網)有條64K的出口,半年前還很快,現在已經比較卡了”。就這樣,我們用Netscape指向Yahoo。那是一個HTML加圖片的世界,充斥著各種花哨閃耀的字體和鞠躬的小人,藍色連接點擊後會奇幻的變色。

我們開始用不熟練的HTML和簡陋的設計來設計網頁,並且知道這邊有個瀏覽器,那邊有個叫WebServer的東西,但管理Sun工作站的機房老師總是盯的很緊,不會讓你動系統半分。聽說有個叫Linux的神奇東西,好吧我想嘗試,可是我只有一臺攢的電腦,以及若幹張5寸3寸的軟盤。我至今感謝一位師兄,他幫我下載並切分了一個版本的Mandrake,就這樣室友看到非常奇怪的一幕,我奔波在機房宿舍之間,仔細計算容量來拷貝,就這樣在假期裏我第一次搭建了Apache。

2. CGI時代

很快頁面上流行一個叫做計數器的東西,免費的收費的建站網站都把它當作賣點,“立體超炫變色時尚計數器”,很快我們看到幾乎每個頁面都有了一個點擊量在88888的酷裝置,只是無論怎麽點都不會變化。而校園裏張貼著令人眼紅的廣告,“征人寫CGI程序,一支500元!“。

慢慢的,知道了CGI是利用進程間輸入輸出通信,和WebServer進行通信,從而可以寫程序來控制頁面輸出的內容。但在當時會給硬盤分區就在中關村被看成電腦高手的年代,實在是會者寥寥。即便到了今天,我依然對Perl敬而遠之。一些前輩用C寫出更高級的CGI應用,比如WebMail,挖到第一桶金,成為今天互聯網的先驅。

3. PHP露出鋒芒

說實話,我認為PHP是最受益於互聯網浪潮的語言,在合適的時間和好夥伴MySQL一起出現。利用Apache的模塊mod-php,將php作為web服務器的一部分運行,效率和維護性都達到很好的提升。腳本語言成為互聯網前端開發主力一直到今天。PHP和大哥Perl,以及兄弟Python,Ruby一起盤據在編程語言排行榜5-10名位置。

同樣的Mysql也是時代的嬌子,它快速靈活易用成為網站數據庫的首選,但很長時間裏,Mysql被其他數據庫詬病,別說Oracle等高富帥,即便是同為開源的Postgres社區裏,也會有這樣的聲音,“不支持事務也叫數據庫?”。沒關系,開源社區很快為其加入各種引擎,如今Mysql絕對是裝機總量第一的數據庫。

4. J2EE

Java時代來臨,一杯咖啡,一個可跳動的小精靈牽動了所有的大型軟件公司。沒錯是所有,包括微軟,Sun公司一時星光無限,所有的開發人員都在談Java。人們對其桌面表現失望進而質疑時,J2EE及時出現了,Servlet+JSP快速成為Web開發的好用技術。能夠跨平臺,獨立解包使用的Web服務器,掛接任意數據庫的JDBC接口,一時世界變得很美好。

微軟的ASP也出現了,一開始也是腳本解釋,和PHP等技術類似。很快微軟的C#和dotNET戰略出臺,ASP也升級為ASP.Net,從此dotNET和J2EE是競爭者,更是一對站在相同站壕的朋友,互相學習和抄襲對方的技術和設計,直到今天。

5. Web層框架百花齊放

Servlet是一個優異的Web技術規範,但面對叢多的開發需求,還是不能很好的覆蓋。Struts框架很快成為主流,今天我們依然看到很多.do後綴的頁面。Struts主要做了三件事,一是對請求Url進行很好的梳理,通過Command模式把請求指配到Action對象上,並可以用同期出現的Ioc框架進行註入。二是梳理出若幹有用好用的Intecepter,並可以自由組合構成自己的Stack。三是對頁面流轉流程通過xml的方式可以靈活定義。

同期,數以百計的各種框架出現了,多數都是針對Servlet的空白點,在幾個方面進行代碼或者配置的約定,可謂百花齊放,百家爭鳴,我想Java社區能到今天依然繁榮,這種海納百川,開放的態度是根本原因。如今很多框架已經走過生命期,但還有很多活躍的,其中Webwork即Struts2,和SpringMVC是模板技術類別最出色的。GWT,Wicket等在頁面組件類表現不錯,還有脫離Servlet束縛Play等框架。

6. WithoutEJB

J2EE裏,除了Servlet外另一個重量級的規範就是EJB。EJB設計的來源是Corba技術,分布式對象技術在EJB規範中有完整的體現。Rod在著作中對EJB規範粗重龐大難用提出各種質疑,尤其是針對其強制分布的要求。我的觀念是分布式支持沒有錯,現在EJB規範中對於Local和Remote的劃分定義是正確的。開發人員應該一開始就需要了解接口粒度的劃分,本地和遠程接口是不同的。對於一般的小型應用,Servlet和EJB容器都在一個虛擬機中,本地接口是合理的,但對於大型企業應用和互聯網級別應用,勢必需要服務的遠程劃分和調用。所以早期的EJB,可以說一方面設計不完備,另一方面又過度設計。但EJB自從3以後完全脫胎換骨,成為設計良好的規範。

spring作為開發框架,把Ioc和AOP能力發揮的淋漓盡致,在各個層次很好融合其他技術和項目庫,一直是Java Web開發的主流。不過面對CDI等JavaEE規範,在註入,生命期管理,對象解耦等優勢不在。我預計今後Spring, JavaEE和Osgi會在主流Java開發框架方向競爭,也會相互借鑒和融合。

7. Ajax

Javascript是瀏覽器正統的腳本語言,但在那個機器性能不佳的年代,一段Js代碼造成鼠標沒有響應的情況比比皆是。Js的給人影響就是頁面上飄來飄去“點擊我”對話框,頁面上走馬燈效果的變色通告,或者是幾十層模態對話框的惡意頁面,很多網吧的機器默認Js是禁用的。在很長的一段時間裏,Java web開發一個潛規則就是少手寫Js文件,這樣可以很好的支持多種瀏覽器和提高效率。

谷歌火了,Ajax也成為火爆的前端技術,我們在使用gmail,google map等產品時,有了另一種體驗,點擊鏈接或按鈕後,即便網絡不算流暢,頁面不再全白重新刷新,而是內容漸漸的出現。其原理就是利用Js腳本到後臺服務器獲取數據,在瀏覽器前端對數據進行解析和渲染,在這個過程中,大多數頁面並不需要進行改變,只是更新頁面中一部分即可。谷歌公司大力支持Firefox使其重生,並和蘋果一起發展webkit項目,各自發展了chrome和safari瀏覽器,伴隨者頁面渲染能力大力提升同時,Js腳本的解析能力也突飛猛進。我個人認為Ajax這個技術看似簡單,但卻是新一代Web,所謂Web2.0的基石性質技術,為互聯網泡沫後互聯網的復興和今日騰飛起到了重要作用。

8. Ruby and Rails

快速成長的互聯網需要快速的web開發能力,Rails框架出現了,同時火爆的還有Ruby語言,它的出現滿足了當時開發者的需要,快速開發,玩cool的東西,有完備的後端模型支持。讓我們仔細分析一下Rails中MVC就能發現,Model中對實體對象的關系定義,和JavaEE的JPA很多概念一致,但利用Ruby語言的元能力,可以直接對實體對象進行功能擴展,而其時Java社區還在為貧血,充血對象爭論不休。Control,View等層次也能和Java的一些框架概念一致,不過有些設計構思更巧妙,而且Rails的基因就是滿足互聯網開發需要,和JavaEE企業級應用有所不同。

很快的,各種語言紛紛出現模仿Rails的項目,Java的Grails, SpringROO,JBossForge,Python的Django,PHP的Symfony等等。毫無例外的,能有影響力的都是開源的,有良好社區能力建設的項目。

9. JSF和CDI

讓我們回到企業應用開發,大家有沒有想過所謂企業應用和互聯網應用之間最大的差別是什麽?我認為是用戶數量級別的差異,導致前端設計方式,軟件體系,後臺數據庫,緩存技術應用,有不同的設計理念和方式。用更技術化來說,就是會話和事務。企業應用是有強會話和事務需求的,而這兩個技術詞語也會一並關聯存在。很簡單,在一個事務中會經過多次會話過程,直到這個事務全部做完。和我們日常辦事是一樣的,填單子,和辦事人員溝通,修改單據,蓋章,各種口舌,最終感慨,辦事真難。

從軟件層面考慮,一個企業應用軟件可能用戶數並不太多,就企業中百十號人,但前後臺的交互是長時間,多次會話交互的。JSF技術其實是借鑒了微軟ASP.net,它們繼承了傳統IDE快速開發的思路,希望通過拖拽連接可以快速開發一個應用。頁面上的組件,對應後臺服務器的業務組件,在得到服務器請求之後,組件需要做一系列動作來完成解析,校驗,模型重建,業務方法調用,頁面渲染等步驟,這些必然有個較長的過程。復雜性,效率,和其他技術的融合,JSF技術從誕生起就被質疑不斷,而且面對每個明星技術,都有些格格不入,比如Ajax出現了,而JSF要求的Post方式還需要重刷頁面。但JSF一直在改進,越來越科學完善。如今,配合CDI,JSF是企業應用開發的首選技術之一,大家可以研究一下Oracle的應用產品和ADF開發框架。

CDI是Seam框架的技術精華形成的JavaEE規範,在JavaEE7裏面已經成為最重要的規範之一。和hibernate最終形成JPA一樣,CDI也是GavinKing構思,開發推動的。仔細分析就會發現,CDI幾乎彌補了JavaEE在現代開發需求中,對象方面定義的絕大多數不足,比如和DI規範定義了註入,生命期管理和會話範圍定義,完善了EJB對於普通POJO對於事務,異步通知機制的定義,還有註解的堆疊定義,裝飾模式等等。有時候我就在想,假如JavaEE是GK從頭打造,我們開發人員會少走很多彎路,因為他對企業應用的理解和用Java構建框架和定義規範,都是貼近一線開發人員需求。唯一遺憾的就是CDI還沒有推動完成,他轉移興趣玩起語言了。關於JSF和CDI,我建議做相關產品的朋友,即便不用這樣的組合,最好也對其技術基本內容有所了解,我想對思路擴展是非常有好處的。

10. Netty,NodeJs,Vertx和異步化趨勢

Netty的領導者和Mina的主力開發者TrustLee,是一個說話慢條斯裏的韓國人。面試時問我一個關於volatile問題,雙方都覺得非母語很別扭,所以就都簡單表達一下就算。可我沒想到這個同齡的開發人員,日後對Java在互聯網公司的地位提升,起到這麽大的作用,這個項目就是Netty。我們都知道Java異步集合庫的作者DougLea的功勞,Nio1代,對於Socket的異步化還不是很完善,即便是Nio2,工作重心還是文件系統的異步化處理,網絡層的異步化設計逐步加強改進。因為Java的設計理念,正交化,接口堆疊,底層功能平臺統一化等給異步分布式網絡框架留出足夠的空間去發揮,Netty,Mina,Grizzly等項目紛紛出現。Twitter宣布從Ruby轉向Scala,並使用Netty讓其大紅大紫。

所謂異步網絡框架,就是對網絡層調用,進行異步化,並進行接口封裝,使得容易理解和使用。異步能力還是通過Java虛擬機現有功能實現的,通過對數據流的處理和狀態感知來進行處理,而不是傳統的阻塞式的收發消息。這個符合我們生活中的感受,當你訂票時,你會打電話告訴你需要什麽,說訂好票給我電話,然後你就去做別的事情,直到訂票員通知你訂好了來支付取票再進行下一步操作,如果訂票是同步的,那你就要一直等待訂票完成,遇到春運可能會搭上整天的時間。

為什麽異步網絡框架也受到重視,答案也是互聯網,數以億計的請求點擊湧來時,傳統的webserver頂不住了,采用一個線程服務一個請求模型的webserver,無法承受這麽大的數據訪問,特別對於Java這樣的吃內存語言,一個請求占用了一個線程,同時也占用了相對應的若幹資源。用企業應用的設計的整個架構面對互聯網級別的應用時,有點崩潰的感覺。解決高並發大量請求的途徑是高吞吐量加上可擴展的軟件架構。異步化可以提升吞吐量,就和銀行的排隊機一樣,顧客來了得到排隊服務,當有可用的櫃臺服務時會主動通知顧客,我們可以設想,即使有再多的顧客,也可以通過增加業務櫃臺,少許增加排隊機和少量人工協調處理來解決。

NodeJs是一個異步化的基於Javascript的開發框架,是當前的明星技術,符合了一些當前開發需求,如異步化,前端Js技術廣泛應用,Js引擎能力極大提升,NoSQL的火爆,組件構建模式變化等。利用Js語言函數式編程能力,Js開發人員可以很輕松的利用已有的組件開發後端應用,前端可以直接用瀏覽器處理Js,別忘了Js是瀏覽器唯一能統一識別的腳本語言,或者用JQuery,AngularJS等流行框架,世界很清凈,都是Js。

但我們需要了解在常駐內存服務型程序方面,Java等語言占有極大優勢,Java社區很快出現了和NodeJs有相同設計思路的項目,Vertx就是其中的優秀代表。它充分借鑒了NodeJs和Erlang/OTP Actor模型的優秀設計,利用分布式消息機制進行對象間通信,利用Netty進行網絡異步操作,方法調用倡導異步調用,有自己的模塊化機制。這樣,Java社區出現了和NodeJs競爭的技術框架,良好使用,可以解決大規模互聯網應用的需求。

Java領域的異步化趨勢可以說剛剛開始,我們看到Servlet和EJB都加入異步支持,Spring的Reactor,JBoss的undertow,隨著Java8對函數語言能力的增強,可以預見又會有叢多的項目產生。我關註著異步化趨勢和JavaEE開發方式的融合之路,相信那是Web開發的明天。

轉Web開發的發展史---Web開發技術的演變