先後端分離

時間 2019-11-29

標籤後端分離简体版

原文原文鏈接

也談基於NodeJS的全棧式開發（基於NodeJS的先後端分離）

前言

爲了解決傳統Web開發模式帶來的各類問題，咱們進行了許多嘗試，但因爲前/後端的物理鴻溝，嘗試的方案都大同小異。痛定思痛，今天咱們從新思考了「先後端」的定義，引入前端同窗都熟悉的NodeJS，試圖探索一條全新的先後端分離模式。前端

隨着不一樣終端(Pad/Mobile/PC)的興起，對開發人員的要求愈來愈高，純瀏覽器端的響應式已經不能知足用戶體驗的高要求，咱們每每須要針對不一樣的終端開發定製的版本。爲了提高開發效率，先後端分離的需求愈來愈被重視，後端負責業務/數據接口，前端負責展示/交互邏輯，同一份數據接口，咱們能夠定製開發多個版本。java

這個話題最近被討論得比較多，阿里有些BU也在進行一些嘗試。討論了好久以後，咱們團隊決定探索一套基於NodeJS的先後端分離方案，過程當中有一些不斷變化的認識以及思考，記錄在這裏，也但願看到的同窗參與討論，幫咱們完善。node

1、什麼是先後端分離？

最開始組內討論的過程當中我發現，每一個人對先後端分離的理解不同，爲了保證能在同一個頻道討論，先就什麼是」先後端分離」達成一致。git

你們一致認同的先後端分離的例子就是SPA(Single-page application)，全部用到的展示數據都是後端經過異步接口(AJAX/JSONP)的方式提供的，前端只管展示。
從某種意義上來講，SPA確實作到了先後端分離，但這種方式存在兩個問題：github

WEB服務中，SPA類佔的比例不多。不少場景下還有同步/同步+異步混合的模式，SPA不能做爲一種通用的解決方案。
現階段的SPA開發模式，接口一般是按照展示邏輯來提供的，有時候爲了提升效率，後端會幫咱們處理一些展示邏輯，這就意味着後端仍是涉足了View層的工做，不是真正的先後端分離。

SPA式的先後端分離，是從物理層作區分（認爲只要是客戶端的就是前端，服務器端的就是後端），這種分法已經沒法知足咱們先後端分離的需求，咱們認爲從職責上劃分才能知足目前咱們的使用場景：web

前端：負責View和Controller層。
後端：只負責Model層，業務處理/數據等。

爲何去作這種職責的劃分，後面會繼續探討。express

2、爲何要先後端分離？

關於這個問題，玉伯的文章Web研發模式演變中解釋得很是全面，咱們再大概理一下：npm

2.1 現有開發模式的適用場景

玉伯提到的幾種開發模式，各有各的適用場景，沒有哪種徹底取代另一種。json

好比後端爲主的MVC，作一些同步展示的業務效率很高，可是遇到同步異步結合的頁面，與後端開發溝通起來就會比較麻煩。
Ajax爲主SPA型開發模式，比較適合開發APP類型的場景，可是隻適合作APP，由於SEO等問題很差解決，對於不少類型的系統，這種開發方式也太重。

2.2 先後端職責不清

在業務邏輯複雜的系統裏，咱們最怕維護先後端混雜在一塊兒的代碼，由於沒有約束，M-V-C每一層均可能出現別的層的代碼，日積月累，徹底沒有維護性可言。
雖然先後端分離沒辦法徹底解決這種問題，可是能夠大大緩解。由於從物理層次上保證了你不可能這麼作。後端

2.3 開發效率問題

淘寶的Web基本上都是基於MVC框架webx，架構決定了前端只能依賴後端。
因此咱們的開發模式依然是，前端寫好靜態demo，後端翻譯成VM模版，這種模式的問題就不說了，被吐槽了好久。
直接基於後端環境開發也很痛苦，配置安裝使用都很麻煩。爲了解決這個問題，咱們發明了各類工具，好比VMarket，可是前端仍是要寫VM，並且依賴後端數據，效率依然不高。
另外，後端也無法擺脫對展示的強關注，從而專心於業務邏輯層的開發。

2.4 對前端發揮的侷限

性能優化若是隻在前端作空間很是有限，因而咱們常常須要後端合做才能碰撞出火花，但因爲後端框架限制，咱們很難使用Comet、Bigpipe等技術方案來優化性能。

爲了解決以上提到的一些問題，咱們進行了不少嘗試，開發了各類工具，但始終沒有太多轉機，主要是由於咱們只能在後端給咱們劃分的那一小塊空間去發揮。只有真正作到先後端分離，咱們才能完全解決以上問題。

3、怎麼作先後端分離？

怎麼作先後端分離，其實第一節中已經有了答案：

前端：負責View和Controller層。
後端：負責Model層，業務處理/數據等。

試想一下，若是前端掌握了Controller，咱們能夠作url design，咱們能夠根據場景決定在服務端同步渲染，仍是根據view層數據輸出json數據，咱們還能夠根據表現層需求很容易的作Bigpipe,Comet,Socket等等，徹底是需求決定使用方式。

3.1 基於NodeJS「全棧」式開發

若是想實現上圖的分層，就必然須要一種web服務幫咱們實現之前後端作的事情，因而就有了標題提到的「基於NodeJS的全棧式開發」

這張圖看起來簡單並且很好理解，但沒嘗試過，會有不少疑問。

SPA模式中，後端已供了所需的數據接口，view前端已經能夠控制，爲何要多加NodeJS這一層？
多加一層，性能怎麼樣？
多加一層，前端的工做量是否是增長了？
多加一層就多一層風險，怎麼破？
NodeJS什麼都能作，爲何還要JAVA？

這些問題要說清楚不容易，下面說下個人認識過程。

3.2 爲何要增長一層NodeJS？

現階段咱們主要之後端MVC的模式進行開發，這種模式嚴重阻礙了前端開發效率，也讓後端不能專一於業務開發。
解決方案是讓前端能控制Controller層，可是若是在現有技術體系下很難作到，由於不可能讓全部前端都學java，安裝後端的開發環境，寫VM。
NodeJS就能很好的解決這個問題，咱們無需學習一門新的語言，就能作到之前開發幫咱們作的事情，一切都顯得那麼天然。

3.3 性能問題

分層就涉及每層之間的通信，確定會有必定的性能損耗。可是合理的分層能讓職責清晰、也方便協做，會大大提升開發效率。分層帶來的損失，必定能在其餘方面的收益彌補回來。
另外，一旦決定分層，咱們能夠經過優化通信方式、通信協議，儘量把損耗降到最低。

舉個例子：
淘寶寶貝詳情頁靜態化以後，仍是有很多須要實時獲取的信息，好比物流、促銷等等，由於這些信息在不一樣業務系統中，因此須要前端發送5，6個異步請求來回填這些內容。
有了NodeJS以後，前端能夠在NodeJS中去代理這5個異步請求，還能很容易的作Bigpipe,這塊的優化能讓整個渲染效率提高不少。
可能在PC上你以爲發5,6個異步請求也沒什麼，可是在無線端，在客戶手機上創建一個HTTP請求開銷很大，有了這個優化，性能一下提高好幾倍。

淘寶詳情基於NodeJS的優化咱們正在進行中，上線以後我會分享一下優化的過程。

3.4 前端的工做量是否增長了？

相對於只切頁面/作demo，確定是增長了一點，可是當前模式下有聯調、溝通環節，這個過程很是花時間，也容易出bug，還很難維護。
因此，雖然工做量會增長一點，可是整體開發效率會提高不少。

另外，測試成本能夠節省不少。之前開發的接口都是針對表現層的，很難寫測試用例。若是作了先後端分離，甚至測試均可以分開，一撥人專門測試接口，一撥人專一測試UI（這部分工做甚至能夠用工具代替）。

3.5 增長Node層帶來的風險怎麼控制？

隨着Node大規模使用，系統/運維/安所有門的同窗也必定會加入到基礎建設中，他們會幫助咱們去完善各個環節可能出現的問題，保障系的穩定性。

3.6 Node什麼都能作，爲何還要JAVA？

咱們的初衷是作先後端分離，若是考慮這個問題就有點違背咱們的初衷了。即便用Node替代Java，咱們也沒辦法保證不出現今天遇到的種種問題，好比職責不清。咱們的目的是分層開發，專業的人，專一作專業的事。基於JAVA的基礎架構已經很是強大並且穩定，並且更適合作如今架構的事情。

4、淘寶基於Node的先後端分離

上圖是我理解的淘寶基於Node的先後端分離分層，以及Node的職責範圍。簡單解釋下：

最上端是服務端，就是咱們常說的後端。後端對於咱們來講，就是一個接口的集合，服務端提供各類各樣的接口供咱們使用。由於有Node層，也不用侷限是什麼形式的服務。對於後端開發來講，他們只用關心業務代碼的接口實現。
服務端下面是Node應用。
Node應用中有一層Model Proxy與服務端進行通信。這一層主要目前是抹平咱們對不一樣接口的調用方式，封裝一些view層須要的Model。
Node層還能輕鬆實現原來vmcommon,tms（引用淘寶內容管理系統）等需求。
Node層要使用什麼框架由開發者本身決定。不過推薦使用express+xTemplate的組合，xTemplate能作到先後端公用。
怎麼用Node你們本身決定，可是使人興奮的是，咱們終於可使用Node輕鬆實現咱們想要的輸出方式:JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同步、異步，想怎麼整就怎麼整，徹底根據你的場景決定。
瀏覽器層在咱們這個架構中沒有變化，也不但願由於引入Node改變你之前在瀏覽器中開發的認知。
引入Node，只是把本該就前端控制的部分交由前端掌控。

這種模式咱們已經有兩個項目在開發中，雖然還沒上線，可是不管是在開發效率，仍是在性能優化方面，咱們都已經嚐到了甜頭。