先後端分離

1、什麼是先後端分離?

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

你們一致認同的先後端分離的例子就是SPA,全部用到的展示的數據都是後端異步接口的方式提供的，前端只管展示。

從某種意義來講。SPA確實作到了先後端分離，但這種方式存在兩個問題：

   WEB服務中。SPA類佔用比例不多。很好狀況下還有同步/異步混合的模式，SPA不能做爲一種通用的解決方案。

   現階段的SPA開發模式，接口一般是按照展示邏輯來提供的。有時候爲了提升效率。後端會幫助咱們處理一些展示的邏輯。這就意味着後端仍是涉及到了View層的工做。不是真正的     後端分離。

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

前端:負責View和Controller層

後端:只負責Model層，業務處理/數據等

 

2、爲何要先後端分離？

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

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

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

   好比後端爲主的MVC,作一些同步展示效率很高，可是遇到了同步和異步結合的頁面，與後端結合起來很麻煩。

Ajax爲主SPA型開發模式，比較適合開發APP類型的場景。但適合作App，由於SEO等問題很差解決。對於不少系統，這種開發方式也太重。

2.2 先後端職責不清

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

2.3 開發效率問題

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

2.4 對前端發揮的侷限

性能優化若是隻在前端作空間很是有限，因而咱們常常須要後端合做才能碰撞成火花，可是因爲後端框架的限制咱們很難使用Coment、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，還很難維護。
因此，雖然工做量會增長一點，可是整體開發效率會提高不少。

另外，測試成本能夠節省不少，之前開發的接口都針對表現層。很難寫測試例。若是作了先後端分離，甚至測試均可以分開。

’