原文:http://ued.taobao.org/blog/2014/04/full-stack-development-with-nodejs/
作者:常胤
為了解決傳統(tǒng)Web開發(fā)模式帶來的各種問題,我們進行了許多嘗試,但由于前/后端的物理鴻溝,嘗試的方案都大同小異。痛定思痛,今天我們重新思考了“前后端”的定義,引入前端同學都熟悉的NodeJS,試圖探索一條全新的前后端分離模式。
隨著不同終端(Pad/Mobile/PC)的興起,對開發(fā)人員的要求越來越高,純?yōu)g覽器端的響應式已經(jīng)不能滿足用戶體驗的高要求,我們往往需要針對不同的終端開發(fā)定制的版本。為了提升開發(fā)效率,前后端分離的需求越來越被重視,后端負責業(yè)務/數(shù)據(jù)接口,前端負責展現(xiàn)/交互邏輯,同一份數(shù)據(jù)接口,我們可以定制開發(fā)多個版本。
這個話題最近被討論得比較多,阿里有些BU也在進行一些嘗試。討論了很久之后,我們團隊決定探索一套基于NodeJS的前后端分離方案,過程中有一些不斷變化的認識以及思考,記錄在這里,也希望看到的同學參與討論,幫我們完善。
最開始組內(nèi)討論的過程中我發(fā)現(xiàn),每個人對前后端分離的理解不一樣,為了保證能在同一個頻道討論,先就什么是”前后端分離”達成一致。
大家一致認同的前后端分離的例子就是SPA(Single-page application),所有用到的展現(xiàn)數(shù)據(jù)都是后端通過異步接口(AJAX/JSONP)的方式提供的,前端只管展現(xiàn)。
從某種意義上來說,SPA確實做到了前后端分離,但這種方式存在兩個問題:
SPA式的前后端分離,是從物理層做區(qū)分(認為只要是客戶端的就是前端,服務器端的就是后端),這種分法已經(jīng)無法滿足我們前后端分離的需求,我們認為從職責上劃分才能滿足目前我們的使用場景:
為什么去做這種職責的劃分,后面會繼續(xù)探討。
關于這個問題,玉伯的文章Web研發(fā)模式演變中解釋得非常全面,我們再大概理一下:
玉伯提到的幾種開發(fā)模式,各有各的適用場景,沒有哪一種完全取代另外一種。
在業(yè)務邏輯復雜的系統(tǒng)里,我們最怕維護前后端混雜在一起的代碼,因為沒有約束,M-V-C每一層都可能出現(xiàn)別的層的代碼,日積月累,完全沒有維護性可言。
雖然前后端分離沒辦法完全解決這種問題,但是可以大大緩解。因為從物理層次上保證了你不可能這么做。
淘寶的Web基本上都是基于MVC框架webx,架構決定了前端只能依賴后端。
所以我們的開發(fā)模式依然是,前端寫好靜態(tài)demo,后端翻譯成VM模版,這種模式的問題就不說了,被吐槽了很久。
直接基于后端環(huán)境開發(fā)也很痛苦,配置安裝使用都很麻煩。為了解決這個問題,我們發(fā)明了各種工具,比如VMarket,但是前端還是要寫VM,而且依賴后端數(shù)據(jù),效率依然不高。
另外,后端也沒法擺脫對展現(xiàn)的強關注,從而專心于業(yè)務邏輯層的開發(fā)。
性能優(yōu)化如果只在前端做空間非常有限,于是我們經(jīng)常需要后端合作才能碰撞出火花,但由于后端框架限制,我們很難使用Comet、Bigpipe等技術方案來優(yōu)化性能。
為了解決以上提到的一些問題,我們進行了很多嘗試,開發(fā)了各種工具,但始終沒有太多起色,主要是因為我們只能在后端給我們劃分的那一小塊空間去發(fā)揮。只有真正做到前后端分離,我們才能徹底解決以上問題。
怎么做前后端分離,其實第一節(jié)中已經(jīng)有了答案:
試想一下,如果前端掌握了Controller,我們可以做url design,我們可以根據(jù)場景決定在服務端同步渲染,還是根據(jù)view層數(shù)據(jù)輸出json數(shù)據(jù),我們還可以根據(jù)表現(xiàn)層需求很容易的做Bigpipe,Comet,Socket等等,完全是需求決定使用方式。
如果想實現(xiàn)上圖的分層,就必然需要一種web服務幫我們實現(xiàn)以前后端做的事情,于是就有了標題提到的“基于NodeJS的全棧式開發(fā)”
這張圖看起來簡單而且很好理解,但沒嘗試過,會有很多疑問。
這些問題要說清楚不容易,下面說下我的認識過程。
現(xiàn)階段我們主要以后端MVC的模式進行開發(fā),這種模式嚴重阻礙了前端開發(fā)效率,也讓后端不能專注于業(yè)務開發(fā)。
解決方案是讓前端能控制Controller層,但是如果在現(xiàn)有技術體系下很難做到,因為不可能讓所有前端都學java,安裝后端的開發(fā)環(huán)境,寫VM。
NodeJS就能很好的解決這個問題,我們無需學習一門新的語言,就能做到以前開發(fā)幫我們做的事情,一切都顯得那么自然。
分層就涉及每層之間的通訊,肯定會有一定的性能損耗。但是合理的分層能讓職責清晰、也方便協(xié)作,會大大提高開發(fā)效率。分層帶來的損失,一定能在其他方面的收益彌補回來。
另外,一旦決定分層,我們可以通過優(yōu)化通訊方式、通訊協(xié)議,盡可能把損耗降到最低。
舉個例子:
淘寶寶貝詳情頁靜態(tài)化之后,還是有不少需要實時獲取的信息,比如物流、促銷等等,因為這些信息在不同業(yè)務系統(tǒng)中,所以需要前端發(fā)送5,6個異步請求來回填這些內(nèi)容。
有了NodeJS之后,前端可以在NodeJS中去代理這5個異步請求,還能很容易的做Bigpipe,這塊的優(yōu)化能讓整個渲染效率提升很多。
可能在PC上你覺得發(fā)5,6個異步請求也沒什么,但是在無線端,在客戶手機上建立一個HTTP請求開銷很大,有了這個優(yōu)化,性能一下提升好幾倍。
淘寶詳情基于NodeJS的優(yōu)化我們正在進行中,上線之后我會分享一下優(yōu)化的過程。
相對于只切頁面/做demo,肯定是增加了一點,但是當前模式下有聯(lián)調(diào)、溝通環(huán)節(jié),這個過程非?;〞r間,也容易出bug,還很難維護。
所以,雖然工作量會增加一點,但是總體開發(fā)效率會提升很多。
另外,測試成本可以節(jié)省很多。以前開發(fā)的接口都是針對表現(xiàn)層的,很難寫測試用例。如果做了前后端分離,甚至測試都可以分開,一撥人專門測試接口,一撥人專注測試UI(這部分工作甚至可以用工具代替)。
隨著Node大規(guī)模使用,系統(tǒng)/運維/安全部門的同學也一定會加入到基礎建設中,他們會幫助我們?nèi)ネ晟聘鱾€環(huán)節(jié)可能出現(xiàn)的問題,保障系的穩(wěn)定性。
我們的初衷是做前后端分離,如果考慮這個問題就有點違背我們的初衷了。即使用Node替代Java,我們也沒辦法保證不出現(xiàn)今天遇到的種種問題,比如職責不清。我們的目的是分層開發(fā),專業(yè)的人,專注做專業(yè)的事?;贘AVA的基礎架構已經(jīng)非常強大而且穩(wěn)定,而且更適合做現(xiàn)在架構的事情。
上圖是我理解的淘寶基于Node的前后端分離分層,以及Node的職責范圍。簡單解釋下:
這種模式我們已經(jīng)有兩個項目在開發(fā)中,雖然還沒上線,但是無論是在開發(fā)效率,還是在性能優(yōu)化方面,我們都已經(jīng)嘗到了甜頭。
技術上不會有太多需要去創(chuàng)新和研究的,已經(jīng)有非常多現(xiàn)成的積累。其實關鍵是一些流程的打通和通用解決方案的積累,相信隨著更多的項目實踐,這塊慢慢會變成一個穩(wěn)定的流程。
雖然“基于NodeJS的全棧式開發(fā)”模式很讓人興奮,但是把基于Node的全棧開發(fā)變成一個穩(wěn)定,讓大家都能接受的東西還有很多路要走,我們正在進行的“中途島”項目就是為了解決這個問題。雖然我們起步不久,但是離目標已經(jīng)越來越近?。?/p>
更多建議: