關於大型網站技術演進的思考（十六）--網站靜態化處理—先後端分離—下（8）

　　我第一次據說nodejs技術大概是在2009年年底，不過我真正認真在網絡上進一步瞭解nodejs仍是在2010年年中，當時對nodejs的認識和我如今對nodejs的認識有着天壤的區別，開始想了解nodejs我只是爲了感慨谷歌公司開發的V8引擎竟然如此強大，它不只僅能夠做爲chrome瀏覽器的javascript內核運行平臺，竟然還能爲服務端使用javascript語言做爲平臺，經過對nodejs的瞭解讓我認識到chrome瀏覽器是如此的優秀，可是如此相對的是我並不認爲javascript做爲服務端語言真的會有市場。

　　爲何我當時會認爲javascript做爲服務端語言的前景堪憂呢？我當時有以下的思考，這些思考放到時下nodejs已經很是火爆的背景下，我相信對不少朋友任然有參考意義，下面是我當時的思考，具體以下：

　　質疑nodejs思考一：2010年以前我還不是敢自稱本身是一名專業web前端的工程師，所以對於javascript的認識和掌握程度也不能和如今相比，可是對於javascript的難學，難深刻倒是有着切膚之痛，所以我想javascript做爲服務端語言就是讓會其餘服務端語言的工程師更加深刻的學習常被服務端工程師詬病的javascript，這麼作的結果無異於逼迫服務端工程師轉向成web前端工程師嘛，這個想一想就讓人以爲不現實。

　　質疑nodejs思考二：我對web應用開發的技術選型認識比較膚淺。技術的選型是個很寬泛的問題，回到我對nodejs的質疑思考主要是體如今web應用服務端語言選擇上，在中國用做web服務端開發的語言很是多，可是主流的無非就是java、php、C#以及C語言系列，固然web服務端技術發展到如今Python、ruby也是有必定市場，做爲一名具體幹活的軟件工程師對於項目選擇何種技術是沒啥發言權的，所以我經常以爲技術選型就是項目經理或者是技術經理以及架構師的問題，而大多時候咱們去詢問爲何用這個服務端語言獲得的答案都是非技術性的回答，例如：公司主要是使用php啊，java比較流行人好找啊，C#開發快啊能很快的完成工做，不多有人會這麼告訴你咱們的項目是個什麼樣的項目，這個項目使用A語言比使用其餘的B語言、X語言有何種好處和優點，其實中國不少軟件企業作項目在技術選型這塊都很粗，說的難聽點其實就是不少能控制項目的人技術水平很難被恭維，固然大部分項目其實使用什麼技術實現並非過重要的問題，可是這個到了技術架構異常複雜的大型網站技術選型問題就顯得尤其重要，這個認識主要是來自於我閱讀《淘寶技術這十年》所感覺到的，淘寶網站的技術選型隨着業務的發展變化的如此之大，顛覆性如此之高，這個在我待過的不少項目組都是難以使人想象的。

　　Web應用發展這麼多年，那些佔據了天時、地利和人和的現有技術基本都是處於一個壟斷的地位，新的同類型語言想突破重圍必然有着本身獨有的技術優點，這就比如在中國作互聯網若是有家新型互聯網公司能夠突破BAT的圍追堵截，那麼這家公司必定是有着本身得天獨厚的優點，因此nodejs必定是得到一種得天獨厚的優點，那麼nodejs優點在哪裏了？不過在講述nodejs的優點以前咱們先來說講上篇文章裏遺留下來的問題。

　　其實上篇裏我講到前端MVC，文章裏只是着重講到了V層即視圖層和M層即模型層的問題，而惟獨沒有專門講解C層即控制層的問題。在先後端分離文章第一篇裏，我談到若是把MVC框架裏的C層以做爲鏈接web前端和web服務端的角度來理解，C層主要承擔了三個方面的工做，它們分別是：路由、報文格式轉化和頁面渲染的工做。前端MVC在處理報文格式轉化和頁面渲染這兩個方面仍是比較容易作到，可是在作路由這塊存在必定問題，前端MVC框架對於獲取服務端數據這塊以及異步請求處理方面其實和傳統MVC框架的處理的手段本質上是相似，只是實現載體有所不一樣而已，可是控制層還有一個路由功能，其中用於頁面切換的路由存在必定的問題，不過這個切換也要限定一下範圍，頁面經過ajax技術讓頁面部分刷新，假如這種部分刷新讓頁面展現效果發生很大變化，對於用戶而言也是頁面發生了切換，可是這種切換是不會讓地址欄的url產生任何改變，這就是問題的根本所在了，我在上篇裏已經討論過這些問題，經過這些問題咱們發現若是頁面轉化時候地址欄的地址隨之也發生改變是會給用戶體驗、網站的友好度以及SEO優化帶來好處的，如是乎我提供了一種手段，那就是使用錨連接來幫助咱們實現url的變化，由於錨連接只是做用於瀏覽器，所以這種手段是對前端MVC的C層實現頁面路由功能的一種很好的支持，可是由於這種方式須要在javascript裏完成，那麼對於SEO優化就產生了問題，最後我提出了頁面切換咱們最好使用同步請求的方式。

　　這個時候問題來了，若是要使用同步請求，那麼這個同步操做天然是要讓服務端來控制，這麼作的結果就是讓服務端再去回收部分控制層的功能，這樣下來一個使用前端MVC架構的網站就有點不太純粹了，具體點就不是一個單頁面的網站，這裏咱們的討論又迴歸到了單頁面的問題了，前文講前端MVC框架不少熱心網友對個人論述發表了有價值的評論，可是我發現個人想法有些朋友可能沒有真正理解（這也許是個人表述的問題吧），我前端MVC講述的一個思路是以批判前端MVC的角度進行的，我早些時候和一些網友探討過前端MVC的設計問題，有些朋友在沒有作具體web前端MVC架構前老是想實現純粹的前端MVC框架，延着這些朋友的思路咱們就會把全部的C層和M層的東西都移到web前端，我常想若是真的這麼實現了，結果天然就是單頁面網站了，或者就是在前端引入了複雜的模型層設計，不過探討畢竟是探討真的實現時候不少朋友就會知道了難度所在了，因此說理想和現實是有差距的，這話又一次靈驗了。

　　這種理想和現實的差距，其實就告訴咱們必定有個地方出問題了，那麼問題在哪裏了？下面我將我對這個問題的思考，總結以下：

　　問題思考一：讓前端承擔大部分MVC的工做，那麼前端自己的技術能力是否能達到全部的要求嗎？這個回答彷佛是確定的，例如單頁面的出現就表明了這種可能性，javascript也是擁有強大的面向對象的編程能力，所以再寫複雜的業務模型層也是沒問題，可是前端這麼作了之後其實並不能知足全部人的需求，例如：SEO的要求，SEO不少技術都是以同步網站請求技術爲根基，這個和前端MVC框架以ajax技術爲根基產生了衝突，這就讓前端技術產生了侷限性。使用javascript面向對象技術來實現業務模型，這個也是有問題，javascript的面向對象的學習成本和精通難度超出了傳統的面向對象的語言例如像java這樣的語言，並且javascript要設計和寫出更加容易維護的代碼是很是不容易的，這麼作不符合我在存儲系列裏講到的要用最簡單的方式實現的原則，這其實也是說明前端技術能力不足的問題。

　　問題思考二：其實無論什麼形式的先後端分離方案它最根本的思想就是讓先後端進行解耦，讓不一樣技術語言體系下的人能作到工做的隔離，最後協同起來各自發揮出本身的最大價值，可是若是咱們只是按前端，後端的角度來作分離，是否是有點粒度過粗，考慮是否是過於片面了？特別是這個片面的問題，web應用的問題並非一個純技術問題，而是一個技術和業務結合的問題，所以任何應用於生產的技術方案都會受到業務的影響，例如上面當咱們要考慮SEO的問題，考慮開發難度的問題，那麼純粹的前端MVC的框架就會顯示出本身的侷限性。前端技術沒法改變瀏覽器地址欄的url，這個從不少角度思考是個合理的設計，可是到了前端MVC裏對C層的設計而言則變成了一種技術手段的侷限性了。由於這種侷限性就讓咱們不得不回到問題的原點狀態，例如頁面的同步請求，而同步請求最合理的控制地點就是服務端了。

　　問題思考三：本思考是一個延生性的思考，我從事這麼多年的web開發，我其實一直困惑於web應用開發和MVC的關係，爲何咱們作web應用開發時候都要那麼強調和重視MVC設計思想呢？難道web應用開發的世界沒有MVC就不能活了嗎？回首下web應用發展的歷史，在web應用開發的忙慌年代，的確是看不到MVC的影子，那個時代的確很自由，自由到許多web應用混亂不堪，質量和健壯性差的不能再差了，這個時候一個英雄出現了那就是MVC，MVC表明了一種次序，一種基本的法則，這就比如人類社會創建的根本原則同樣，這些原則讓人類和野獸有了區別，人類也由於這些原則而成爲萬物之靈長，相比之下MVC就是web開發世界裏的遊戲規則和行爲準則，所以只有當咱們從MVC角度思考web應用的建設，纔會讓web應用更加的優秀，這也就是在講述先後端分離技術時候我都是以MVC思想做爲準則進行思考的。思考回到具體的場景，MVC思想的運用就是讓咱們把web應用開發裏能夠歸爲一類的場景彙集在一個範疇之下，不一樣範疇使用一種雙發均可以接受的統一準則進行溝通，這麼一來咱們就把須要解決的問題簡單化了，各個獨立的範疇由於減小許多沒必要要的干擾，所以能讓它們發揮出更大的潛力，更重要的MVC還讓web應用伸縮性，健壯性，可維護性大大加強。例如在不少傳統web應用開發裏在控制層這塊先後端的矛盾就是屬於MVC規則使用不完善所致。

　　單頁面的應用存在不少問題，所以須要同步請求的介入，這就致使了服務端再度回收了失去的控制層的功能，這麼作也無可厚非，可是我很擔憂這個改進的引入會不會致使傳統MVC框架裏控制層的混亂問題，根據個人經驗，這種混亂的程度已經下降了不少不少，基本咱們能夠忽視原來C層的問題了。

　　不過不少有追求的web前端工程師對於這種不純粹的前端MVC的異議仍是不少的，大部分異議仍是源自瀏覽器能力的侷限性，當服務端不少方面被弱化後，也許能夠解決咱們之前在前端被服務端束縛的不少問題，可是同時又產生了新的問題，這些新問題我總結以下：

　　新問題一：在傳統的網站動靜劃分裏，咱們常把瀏覽器端的技術html、css和javascript歸結於靜態技術的範疇，若是網站使用Web前端MVC那麼前端就會接過不少動態網站的功能，這個時候傳統的靜態技術就被人爲的演變爲動態技術。回顧網站的發展歷程，基本是從靜態到動態的轉變，這個結論用在時下其實已經有點不太對了，隨着網站愈來愈龐大愈來愈複雜，網站技術發展逐漸開始逆向進行了，網站從動態化向靜態化轉變的需求變得愈來愈強烈了，這也是時下前沿的前端技術正在解決的問題，例如本系列的主題網站靜態化技術就是順應這個發展趨勢而來的，因此前端MVC框架在這點上有點逆歷史潮流的問題了。

　　新問題二：前端MVC讓web前端的技術難度和架構難度成指數級上升，而javascript語言天生有着本身設計的缺陷，這個缺陷在寫大規模複雜應用時候就顯得尤其突出，例如：javascript沒有模塊化管理，javascript面向對象的實現難度，因此前端MVC的應用可能會變相的提高企業的技術成本和開發成本，固然不少新的技術手段能解決javascript固有的缺陷，對這些新技術有個更大的問題就是「你會嗎「，不會的話首先要解決會的問題，這也是個成本問題。

　　新問題三：當前端真的愈來愈獨立於服務端後，這會致使服務端一些能夠優化web前端的重要技術就很難實現了，例如網站靜態化系列裏講到了緩存運用，CDN的運用就很難達到預期效果，或者根本無法使用，由於這些技術的根基都是認爲網站動態性是由服務端發生的，而客戶端霸佔了動態性，那麼這些技術的做用就被限制住了。

　　由此我能夠下個結論：若是先後端分離方案是以瀏覽器和服務器角度來劃分並非最好的前端分離方案，那麼先後端分離方案還有沒有新的解決思路了？這個真的有，那就是nodejs參入的先後端分離方案。

　　其實先後端分離的驅動永遠都是前端強於服務端，而先後端分離的重要目的也是要給web前端創造一個更加乾淨的開發環境，那麼寫的代碼是不是在瀏覽器上跑仍是在服務端上跑這個並非過重要，因此引入nodejs，就是讓服務端也能跑javascript代碼並不會是讓人沒法接受的事情，回到先後端分離方案裏以服務端驅動的先後端分離方案，我曾說過這個方案能得到服務端開發人員更多的掌聲，我相信這個掌聲不會是服務端爲前端的喝彩，而是服務端終於從web前端解脫出來了，這樣服務端運用更加高級的SOA技術就成爲了可能，那麼咱們把web前端的控制層使用nodejs替代，這麼一來咱們既能夠繼承全部傳統MVC框架的優勢，同時也達到之前後端分離的根本的問題就是爲web前端創造一個很乾淨的開發環境問題，那麼咱們在前端MVC框架使用時候遇到的問題都會很好的被解決。

　　Nodejs的運用讓動態網站的動態性再度停留在了服務端，那麼我前面講的那麼多網站靜態化技術就能夠和先後端分離方案很好的融合了，所以本篇先不具體討論nodejs作先後端分離的實現手段了，在下篇講從網站靜態化角度從新審視先後端分離方案時候一塊兒講解，這麼作會更加符合本系列的主題。

　　如今咱們能夠解答爲何nodejs技術能夠突破傳統服務端技術的包圍，由於nodejs可讓先後端達到更高程度的分離，從而讓先後端各自發揮本身的優點，頗有意思的是，雖然nodejs技術屬於服務端範疇，可是它倒是前端工程師驅動來普及的，這絕對是web前端逆襲啊。

　　好了，本文就講到這裏，最後祝你們工做和生活都愉快。