前言

為了解決傳統(tǒng)Web開發(fā)模式帶來的各種問題，我們進(jìn)行了許多嘗試，但由于前/后端的物理鴻溝，嘗試的方案都大同小異。痛定思痛，今天我們重新思考了“前后端”的定義，引入前端同學(xué)都熟悉的NodeJS，試圖探索一條全新的前后端分離模式。

隨著不同終端(Pad/Mobile/PC)的興起，對(duì)開發(fā)人員的要求越來越高，純?yōu)g覽器端的響應(yīng)式已經(jīng)不能滿足用戶體驗(yàn)的高要求，我們往往需要針對(duì)不同的終端開發(fā)定制的版本。為了提升開發(fā)效率，前后端分離的需求越來越被重視，后端負(fù)責(zé)業(yè)務(wù)/數(shù)據(jù)接口，前端負(fù)責(zé)展現(xiàn)/交互邏輯，同一份數(shù)據(jù)接口，我們可以定制開發(fā)多個(gè)版本。

這個(gè)話題最近被討論得比較多，阿里有些BU也在進(jìn)行一些嘗試。討論了很久之后，我們團(tuán)隊(duì)決定探索一套基于NodeJS的前后端分離方案，過程中有一些不斷變化的認(rèn)識(shí)以及思考，記錄在這里，也希望看到的同學(xué)參與討論，幫我們完善。

一、什么是前后端分離？

最開始組內(nèi)討論的過程中我發(fā)現(xiàn)，每個(gè)人對(duì)前后端分離的理解不一樣，為了保證能在同一個(gè)頻道討論，先就什么是”前后端分離”達(dá)成一致。

大家一致認(rèn)同的前后端分離的例子就是SPA(Single-page application)，所有用到的展現(xiàn)數(shù)據(jù)都是后端通過異步接口(AJAX/JSONP)的方式提供的，前端只管展現(xiàn)。
從某種意義上來說，SPA確實(shí)做到了前后端分離，但這種方式存在兩個(gè)問題：

WEB服務(wù)中，SPA類占的比例很少。很多場(chǎng)景下還有同步/同步+異步混合的模式，SPA不能作為一種通用的解決方案。
現(xiàn)階段的SPA開發(fā)模式，接口通常是按照展現(xiàn)邏輯來提供的，有時(shí)候?yàn)榱颂岣咝?，后端?huì)幫我們處理一些展現(xiàn)邏輯，這就意味著后端還是涉足了View層的工作，不是真正的前后端分離。
SPA式的前后端分離，是從物理層做區(qū)分（認(rèn)為只要是客戶端的就是前端，服務(wù)器端的就是后端），這種分法已經(jīng)無法滿足我們前后端分離的需求，我們認(rèn)為從職責(zé)上劃分才能滿足目前我們的使用場(chǎng)景：

前端：負(fù)責(zé)View和Controller層。
后端：只負(fù)責(zé)Model層，業(yè)務(wù)處理/數(shù)據(jù)等。
為什么去做這種職責(zé)的劃分，后面會(huì)繼續(xù)探討。

二、為什么要前后端分離？

關(guān)于這個(gè)問題，玉伯的文章Web研發(fā)模式演變中解釋得非常全面，我們?cè)俅蟾爬硪幌拢?/p>

2.1 現(xiàn)有開發(fā)模式的適用場(chǎng)景

玉伯提到的幾種開發(fā)模式，各有各的適用場(chǎng)景，沒有哪一種完全取代另外一種。

比如后端為主的MVC，做一些同步展現(xiàn)的業(yè)務(wù)效率很高，但是遇到同步異步結(jié)合的頁面，與后端開發(fā)溝通起來就會(huì)比較麻煩。
Ajax為主SPA型開發(fā)模式，比較適合開發(fā)APP類型的場(chǎng)景，但是只適合做APP，因?yàn)镾EO等問題不好解決，對(duì)于很多類型的系統(tǒng)，這種開發(fā)方式也過重。
2.2 前后端職責(zé)不清

在業(yè)務(wù)邏輯復(fù)雜的系統(tǒng)里，我們最怕維護(hù)前后端混雜在一起的代碼，因?yàn)闆]有約束，M-V-C每一層都可能出現(xiàn)別的層的代碼，日積月累，完全沒有維護(hù)性可言。
雖然前后端分離沒辦法完全解決這種問題，但是可以大大緩解。因?yàn)閺奈锢韺哟紊媳ＷC了你不可能這么做。

2.3 開發(fā)效率問題

淘寶的Web基本上都是基于MVC框架webx，架構(gòu)決定了前端只能依賴后端。
所以我們的開發(fā)模式依然是，前端寫好靜態(tài)demo，后端翻譯成VM模版，這種模式的問題就不說了，被吐槽了很久。
直接基于后端環(huán)境開發(fā)也很痛苦，配置安裝使用都很麻煩。為了解決這個(gè)問題，我們發(fā)明了各種工具，比如VMarket，但是前端還是要寫VM，而且依賴后端數(shù)據(jù)，效率依然不高。
另外，后端也沒法擺脫對(duì)展現(xiàn)的強(qiáng)關(guān)注，從而專心于業(yè)務(wù)邏輯層的開發(fā)。

2.4 對(duì)前端發(fā)揮的局限

性能優(yōu)化如果只在前端做空間非常有限，于是我們經(jīng)常需要后端合作才能碰撞出火花，但由于后端框架限制，我們很難使用Comet、Bigpipe等技術(shù)方案來優(yōu)化性能。

為了解決以上提到的一些問題，我們進(jìn)行了很多嘗試，開發(fā)了各種工具，但始終沒有太多起色，主要是因?yàn)槲覀冎荒茉诤蠖私o我們劃分的那一小塊空間去發(fā)揮。只有真正做到前后端分離，我們才能徹底解決以上問題。

三、怎么做前后端分離？

怎么做前后端分離，其實(shí)第一節(jié)中已經(jīng)有了答案：

前端：負(fù)責(zé)View和Controller層。
后端：負(fù)責(zé)Model層，業(yè)務(wù)處理/數(shù)據(jù)等。

試想一下，如果前端掌握了Controller，我們可以做url design，我們可以根據(jù)場(chǎng)景決定在服務(wù)端同步渲染，還是根據(jù)view層數(shù)據(jù)輸出json數(shù)據(jù)，我們還可以根據(jù)表現(xiàn)層需求很容易的做Bigpipe,Comet,Socket等等，完全是需求決定使用方式。

3.1 基于NodeJS“全?！笔介_發(fā)

如果想實(shí)現(xiàn)上圖的分層，就必然需要一種web服務(wù)幫我們實(shí)現(xiàn)以前后端做的事情，于是就有了標(biāo)題提到的“基于NodeJS的全棧式開發(fā)”

這張圖看起來簡(jiǎn)單而且很好理解，但沒嘗試過，會(huì)有很多疑問。

SPA模式中，后端已供了所需的數(shù)據(jù)接口，view前端已經(jīng)可以控制，為什么要多加NodeJS這一層？
多加一層，性能怎么樣？
多加一層，前端的工作量是不是增加了？
多加一層就多一層風(fēng)險(xiǎn)，怎么破？
NodeJS什么都能做，為什么還要JAVA？
這些問題要說清楚不容易，下面說下我的認(rèn)識(shí)過程。

3.2 為什么要增加一層NodeJS？

現(xiàn)階段我們主要以后端MVC的模式進(jìn)行開發(fā)，這種模式嚴(yán)重阻礙了前端開發(fā)效率，也讓后端不能專注于業(yè)務(wù)開發(fā)。
解決方案是讓前端能控制Controller層，但是如果在現(xiàn)有技術(shù)體系下很難做到，因?yàn)椴豢赡茏屗星岸硕紝W(xué)java，安裝后端的開發(fā)環(huán)境，寫VM。
NodeJS就能很好的解決這個(gè)問題，我們無需學(xué)習(xí)一門新的語言，就能做到以前開發(fā)幫我們做的事情，一切都顯得那么自然。

3.3 性能問題

分層就涉及每層之間的通訊，肯定會(huì)有一定的性能損耗。但是合理的分層能讓職責(zé)清晰、也方便協(xié)作，會(huì)大大提高開發(fā)效率。分層帶來的損失，一定能在其他方面的收益彌補(bǔ)回來。
另外，一旦決定分層，我們可以通過優(yōu)化通訊方式、通訊協(xié)議，盡可能把損耗降到最低。

舉個(gè)例子：
淘寶寶貝詳情頁靜態(tài)化之后，還是有不少需要實(shí)時(shí)獲取的信息，比如物流、促銷等等，因?yàn)檫@些信息在不同業(yè)務(wù)系統(tǒng)中，所以需要前端發(fā)送5，6個(gè)異步請(qǐng)求來回填這些內(nèi)容。
有了NodeJS之后，前端可以在NodeJS中去代理這5個(gè)異步請(qǐng)求，還能很容易的做Bigpipe,這塊的優(yōu)化能讓整個(gè)渲染效率提升很多。
可能在PC上你覺得發(fā)5,6個(gè)異步請(qǐng)求也沒什么，但是在無線端，在客戶手機(jī)上建立一個(gè)HTTP請(qǐng)求開銷很大，有了這個(gè)優(yōu)化，性能一下提升好幾倍。

淘寶詳情基于NodeJS的優(yōu)化我們正在進(jìn)行中，上線之后我會(huì)分享一下優(yōu)化的過程。

3.4 前端的工作量是否增加了？

相對(duì)于只切頁面/做demo，肯定是增加了一點(diǎn)，但是當(dāng)前模式下有聯(lián)調(diào)、溝通環(huán)節(jié)，這個(gè)過程非常花時(shí)間，也容易出bug，還很難維護(hù)。
所以，雖然工作量會(huì)增加一點(diǎn)，但是總體開發(fā)效率會(huì)提升很多。

另外，測(cè)試成本可以節(jié)省很多。以前開發(fā)的接口都是針對(duì)表現(xiàn)層的，很難寫測(cè)試用例。如果做了前后端分離，甚至測(cè)試都可以分開，一撥人專門測(cè)試接口，一撥人專注測(cè)試UI（這部分工作甚至可以用工具代替）。

3.5 增加Node層帶來的風(fēng)險(xiǎn)怎么控制？

隨著Node大規(guī)模使用，系統(tǒng)/運(yùn)維/安全部門的同學(xué)也一定會(huì)加入到基礎(chǔ)建設(shè)中，他們會(huì)幫助我們?nèi)ネ晟聘鱾€(gè)環(huán)節(jié)可能出現(xiàn)的問題，保障系的穩(wěn)定性。

3.6 Node什么都能做，為什么還要JAVA？

我們的初衷是做前后端分離，如果考慮這個(gè)問題就有點(diǎn)違背我們的初衷了。即使用Node替代Java，我們也沒辦法保證不出現(xiàn)今天遇到的種種問題，比如職責(zé)不清。我們的目的是分層開發(fā)，專業(yè)的人，專注做專業(yè)的事?；贘AVA的基礎(chǔ)架構(gòu)已經(jīng)非常強(qiáng)大而且穩(wěn)定，而且更適合做現(xiàn)在架構(gòu)的事情。

四、淘寶基于Node的前后端分離

上圖是我理解的淘寶基于Node的前后端分離分層，以及Node的職責(zé)范圍。簡(jiǎn)單解釋下：

最上端是服務(wù)端，就是我們常說的后端。后端對(duì)于我們來說，就是一個(gè)接口的集合，服務(wù)端提供各種各樣的接口供我們使用。因?yàn)橛蠳ode層，也不用局限是什么形式的服務(wù)。對(duì)于后端開發(fā)來說，他們只用關(guān)心業(yè)務(wù)代碼的接口實(shí)現(xiàn)。
服務(wù)端下面是Node應(yīng)用。
Node應(yīng)用中有一層Model Proxy與服務(wù)端進(jìn)行通訊。這一層主要目前是抹平我們對(duì)不同接口的調(diào)用方式，封裝一些view層需要的Model。
Node層還能輕松實(shí)現(xiàn)原來vmcommon,tms（引用淘寶內(nèi)容管理系統(tǒng)）等需求。
Node層要使用什么框架由開發(fā)者自己決定。不過推薦使用express+xTemplate的組合，xTemplate能做到前后端公用。
怎么用Node大家自己決定，但是令人興奮的是，我們終于可以使用Node輕松實(shí)現(xiàn)我們想要的輸出方式:JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同步、異步，想怎么整就怎么整，完全根據(jù)你的場(chǎng)景決定。
瀏覽器層在我們這個(gè)架構(gòu)中沒有變化，也不希望因?yàn)橐隢ode改變你以前在瀏覽器中開發(fā)的認(rèn)知。
引入Node，只是把本該就前端控制的部分交由前端掌控。
這種模式我們已經(jīng)有兩個(gè)項(xiàng)目在開發(fā)中，雖然還沒上線，但是無論是在開發(fā)效率，還是在性能優(yōu)化方面，我們都已經(jīng)嘗到了甜頭。

五、我們還需要要做什么？

把Node的開發(fā)流程集成到淘寶現(xiàn)有的SCM流程中。
基礎(chǔ)設(shè)施建設(shè)，比如session,logger等通用模塊。
最佳開發(fā)實(shí)踐
線上成功案例
大家對(duì)Node前后端分離概念的認(rèn)識(shí)
安全
性能
…
技術(shù)上不會(huì)有太多需要去創(chuàng)新和研究的，已經(jīng)有非常多現(xiàn)成的積累。其實(shí)關(guān)鍵是一些流程的打通和通用解決方案的積累，相信隨著更多的項(xiàng)目實(shí)踐，這塊慢慢會(huì)變成一個(gè)穩(wěn)定的流程。

六、“中途島”

雖然“基于NodeJS的全棧式開發(fā)”模式很讓人興奮，但是把基于Node的全棧開發(fā)變成一個(gè)穩(wěn)定，讓大家都能接受的東西還有很多路要走，我們正在進(jìn)行的“中途島”項(xiàng)目就是為了解決這個(gè)問題。雖然我們起步不久，但是離目標(biāo)已經(jīng)越來越近！！