先後端分離概述

一 先後端分離的目的和做用
       作Web開發也能夠說是B/S架構開發，B端和S端從技術體系角度而言異構性很大，換而言之就是B端使用的技術和S端使用的技術不適於同一個體系，這樣的結果致使實際開發中，很難作到專業分工，若是項目開發過程當中管控不到位，這樣的問題可能會影響到整個項目的開發質量，所以先後端分離的目的之一就是要作到專業化分工，提升項目的質量和開發效率。
       隨着技術的發展，當下的Web開發形勢已經和之前有了很大的不一樣，早期的Web項目是一個封閉的項目，用戶從瀏覽器裏看到的頁面直到後臺數據庫都是在一個項目裏集成的，而如今Web系統的規模愈來愈大，中大型的Web系統是一個開放式的系統，開放型的系統用戶在瀏覽器發起的請求可能會轉發到外部的系統裏進行處理，或者是本地的系統和外部系統一塊兒完成請求的處理，此外有的請求可能不會直接請求數據庫，而是請求緩存服務器，這些變化幾乎都是發生在Web系統的服務端，先後端耦合度很高的Web系統服務端的複雜度提高必然帶來了Web前端的複雜度的提高。所以Web前端從系統架構的角度也須要更加專業的管控，管控的做用之一就是先後端進行分離，下降前端對服務端的依耐性。
      富客戶端應用的普及致使Web前端技術開發更加專業化，Web前端工程師成爲一個獨立的技術崗位，Web前端開發技術的難度也愈來愈高，先後端的分離就是爲Web前端開發營造一個良好的開發環境，不要讓前端工程師被一些不可控的外在因素所影響（例如：先後端的耦合性），最後致使前端不能專心致志作出更加好的做品。因此，先後端分離是讓先後端更加專業化，在技術和管理上將前端角色更加明確，更深刻的挖掘前端開發的價值。

二 現有系統架構給先後端帶來的問題以及解決方法

       上圖是目前大部分系統的架構圖，雖然有些系統採用分佈式架構，層與層之間使用了遠程調用框架，可是本質上都逃不開上面這個架構設計。這張圖是一張比較合理的圖，在實際開發裏最常發生的事情就是控制層（Control）越過服務層（Service）直接處理下面的資源。

　　先後端耦合的問題主要發生在控制層（Control），控制層是前端和服務端交互的邊界，可是在開發過程當中控制層（Control）和服務層（Service）經常混淆不清，這就是先後端耦合度高的重要緣由。

　　所以要先後端解耦，就是要劃清控制層的邊界，控制層到底該屬於前端仍是服務端，在MVC模式裏控制層做用是調度，控制層不是寫業務邏輯的地方，所以將大量業務邏輯寫到控制層實際上是違背了MVC模式的思想，同時控制層是前端和服務端通信的橋樑，其實控制層是參入了前端的工做任務，既然控制層要剝離業務操做同時控制層也要參入前端應用的開發，那麼將控制層歸爲前端的一部分是徹底合情合理合規的。

　　把控制層剝離了業務邏輯處理可能會讓人不知道如何開發了，我以爲有這種想法的人是開發時候沒有理解透MVC模式思想，編程隨意性大養成了壞習慣，這個就須要這些人一點點去適應技術新趨勢的發展。

　　先後端分離的終極目標應該是前端和服務端是徹底獨立的項目，前端項目包含上圖裏的瀏覽器和控制層，服務端項目包括服務層、DAO層等等，前端項目和服務端項目以高效的遠程調用框架作通信介質，項目開發時候前端項目作前端的事情，服務項目作服務端的事情，這樣就讓服務端開發的人員沒有機會在控制層亂寫代碼了，保證了Web前端環境的純粹性，最後生產發佈也要獨立部署，這樣就達到了先後端真正解耦，可是先後端的溝通機制也是不可或缺的，我以爲它們之間的溝通使用高性能的遠程調用框架，先後端相互約定通信報文格式。.

　　其實無論服務端仍是前端宏觀流程無非是輸入數據à數據處理à輸出數據，可是服務端要把心思花在數據處理上，前端要更多關心的是輸入輸出數據時候的用戶體驗操做，服務端開發最大的問題就是違背MVC原則，代碼編寫的隨意性，而前端無論出於安全仍是性能考慮，最好是儘可能少牽涉業務。前端和後端通信層的獨立，會將先後端進行真正的解耦，前面我講到先後真正問題就是前端和後端技術路線不一致，可是傳統Web開發裏先後端又要融爲一體，這就致使先後端很難作到專業化分工，對於前端應該儘可能弱化通信級別的開發工做，前端通信編程只要知道調用哪一個接口，傳什麼參數，怎麼處理響應信息就好了。這樣就能讓前端和後端實現真正的專業化。

 

 

       爲何要分離？
　　若是隻問「先後端分離的意義大麼？」這是廢話，由於從軟件架構的角度 Web 的先後端從一開始不就一直是分離的麼，並且 browser、server 可能將永遠分離下去。
　　爲了瞭解這個問題，咱們有必要先了解一下 Web的研發模式演變，關於這個題材，下面這篇博文說得不錯，這邊就不作搬運工了。
　　https://github.com/lifesinger/blog/issues/184
　　咱們不能「爲了分離而分離」，而應該「爲了真正理解web開發、爲了更好完成需求而分離」

     

    先後端分離的誤區？

　　一、前端人員配備是否充足？

　　因爲所在公司以往項目採用傳統開發風格，即之後端MVC爲主的開發模式，前端人員僅僅提供靜態html頁面，其他工做皆由後端開發人員完成。採用先後端分離模式能夠減後臺負擔，加快研發效率，固然，前提是前端能作好的話。以往只須要提供靜態頁面的前端人員，在先後端分離模式中要負責項目的view+controller部分，即除了靜態頁面，還須要負責頁面的全部交互代碼、以及nodejs與視圖層以及後端API的交互工做，無疑增長了前端人員的學習成本，在沒有足夠知識和人才儲備的狀況下，只能讓前端人員加班加點。結果是大量前端人員離職（PS：作這麼多事，工資總得加吧！）

　　二、先後端職責分配？

　　不少公司認爲採用先後端分離以後，先後端只須要經過指定API進行交互便可，前端負責頁面渲染，Nodejs負責路由分配，後端提供API。忽視了大量關鍵工做，職責分配和細節處理沒有相應文檔規定，緩存機制、圖片上傳下載、數據校驗、語言國際化等等並無出具相應信息。另外，大量忽視了nodejs層的做用，僅僅把nodejs當成一個路由中轉，這一方面也是對nodejs技術的不熟悉致使的，其實nodejs能負責不少事，除了複雜業務邏輯處理和數據操做由Java 負責，大量工做徹底能夠在nodejs層處理。（PS：仍是基礎不夠致使的！）

　　三、後端API是否Restful風格？

　　不少公司採用了先後端分離模式後，後端API仍然採用以往的傳統風格，這是不合理的，Restful風格的API應該是先後端分離的最佳實踐。ResultFul推薦每一個URL能操做具體的資源,並且能準確描述服務器對資源的處理動做，一般服務器對資源支持get/post/put/delete/等，用來實現資源的增刪改查。先後端分離的話，這些api-url是對接的橋樑，採用resultFul接口地址含義才更清晰、見名知意。（PS：用了Spring4.x 居然還不用rest風格，說不過去啊）

　　 四、先後端協做模式？

　　先後端分離後，不管是API接口的對接仍是測試工做，都涉及到先後端人員的溝通，不少公司採用先後端分離後，先後端協做模式配協力度底，互相等待，開發效率低下，反而不如傳統的開發模式。例如：當後端 API 沒有編寫完成時，前端沒法進行調試，這就致使了前端會被後端阻塞的狀況。其實像這種互相等待的模式須要改進， Mock Server 可能能夠解決一些問題。

如何先後端分離？

　　怎麼作先後端分離？大方向就是

　　後端專一於：後端控制層（Restful API） & 服務層 & 數據訪問層；

　　前端專一於：前端控制層（Nodejs） & 視圖層

　　本人認爲的先後端分離模式應該是這樣，固然這不必定正確：

　　一、項目設計階段，先後端架構負責人將項目總體進行分析，討論並肯定API風格、職責分配、開發協助模式，肯定人員配備；設計肯定後，先後端人員共同制定開發接口。

　　二、項目開發階段，先後端分離是各自分工，協同敏捷開發，後端提供Restful API，並給出詳細文檔說明，前端人員進行頁面渲染前臺的任務是發送API請(GET,PUT,POST,DELETE等)獲取數據（json，xml）後渲染頁面。

　　三、項目測試階段，API完成以前，前端人員會使用mock server進行模擬測試，後端人員採用junit進行API單元測試，不用互相等待；API完成以後，先後端再對接測試一下就能夠了，固然並非全部的接口均可以提早定義，有一些是在開發過程當中進行調整的。

　　四、項目部署階段，利用nginx 作反向代理，即Java + nodejs + nginx 方式進行。

能夠在深刻理解一下：http://itindex.net/detail/55771

https://github.com/lifesinger/blog/issues/184

 

本文參考：https://www.cnblogs.com/sharpxiajun/p/3531665.html

https://www.cnblogs.com/shanrengo/p/6397734.html