先後端分離，是爲了彼此更好

 

1、被誤解的先後端分離

 

在Web應用開發過程當中，業界對先後端的分界線彷佛一直都沒有肯定的概念，不過大多數人以瀏覽器做爲先後端的分界線。將瀏覽器中爲用戶進行頁面展現的部分稱爲前端，而將運行於服務器，爲前端提供業務邏輯和數據準備的全部代碼統稱爲後端。

 

雖然先後端分離在數年前就已經開始受到關注，但不少人對它倒是隻聞其聲，未見其形，因此對它產生了一些誤解，誤覺得先後段分離只是一種Web應用的開發模式，只要在Web應用的開發期進行了先後端開發工做的分工就是先後端分離。

 

其實並不是如此，準確的說，先後端分離並不僅是開發模式，而是Web應用的一種架構模式。在開發期，先後端工程師能夠經過約定好交互接口，實現並行開發；在運行期，先後端分離模式須要對Web應用進行分離部署，先後端之間使用HTTP請求進行交互。然而做爲應用的架構模式，先後端分離並非經過這樣一句話就能一律而談的，咱們能夠從交互形式、代碼組織方式、開發模式三個方面對先後端分離進行認識。

 

一、交互形式

在先後端分離架構中，後端只須要負責按照約定的數據格式向前端提供可調用的API服務便可。先後端之間經過HTTP請求進行交互，前端獲取到數據後，進行頁面的裝配和渲染。

 

二、代碼組織方式

 

在傳統架構模式中，先後端代碼存放於同一個代碼庫中，甚至是同一工程目錄下。頁面中還夾雜着後端代碼。先後端工程師進行開發時，都必須把整個項目導入到開發工具中。

 

而先後端分離模式在代碼組織形式上有如下兩種：

 

半分離

先後端共用一個代碼庫，可是代碼分別存放在兩個工程中。後端不關心或不多關心前端元素的輸出狀況，前端不能獨立進行開發和測試，項目中缺少先後端交互的測試用例。

分離

先後端代碼庫分離，前端代碼中有能夠進行Mock測試（經過構造虛擬測試對象以簡化測試環境的方法）的僞後端，能支持前端的獨立開發和測試。然後端代碼中除了功能實現外，還有着詳細的測試用例，以保證API的可用性，下降集成風險。

 

三、開發模式

 

傳統的MVC架構開發，沒有進行先後端分離，前端工程師負責編寫HTML，完成前端頁面設計，而後給後端工程師員套界面，使用模板技術將前端代碼轉換成JSP頁面，同時內嵌java代碼。應用運行期，將所有代碼進行打包，部署到同一服務器上，或者進行簡單的動靜態分離部署。

 

此時，應用的開發流程以下圖所示。

 

在先後端分離架構中，前端工程師只須要編寫HTML、js、CSS等前端資源，而後經過HTTP請求調用後端提供的服務便可。除了開發期的分離，在運行期先後端資源也會進行分離部署。

 

先後端分離以後，開發流程將以下圖所示。

 

經過上面的兩幅流程圖，不難發現，在開發模式上，先後段分離不只僅只是工程師的分工開發，更重要的意義在於實現了先後端的並行開發，和簡化了開發流程。

 

 

2、爲何要「離」：4個好處

 

 

從新認識先後端分離以後，想必你們內心都會有疑問，先後端分離模式與以前的Web應用架構相比可謂是截然不同，咱們爲何要進行先後端分離呢？正如莎士比亞在《哈姆雷特》中的經典名句同樣，分仍是不分，這是個問題。

 

從目前應用軟件的發展趨勢來看，一方面，用戶愈來愈注重軟件的體驗感，隨着互聯網的蓬勃發展，應用開始走向多終端化；另外一方面，大型應用的架構模式正紛紛向着雲化、微服務化發展。

 

雖然過去的應用架構暫時還能支撐起當下應用的開發，可是各類弊端已經開始浮出水面，幾年前能帶來開發便捷優點的先後端代碼混合模式，在當下已經成爲了拖慢咱們前進步伐的泥沼，讓咱們屢屢吃痛。咱們之因此開始嘗試先後端分離，是爲了能在將來得到更好的發展，指望經過先後端分離架構，來爲咱們帶來如下4個方面的提高。

 

爲孵化優質產品打造精益團隊

 

正如康威定律所述，產品是組織溝通結構的縮影，軟件開發團隊想要孵化出優質的產品，必須先打造一個精益的開發團隊。開發團隊的組織劃分是如何影響產品的孵化呢，咱們經過下面的示例來進行說明。

 

若是開發團隊是按照業務邊界進行劃分的，開發出來的產品將可能會是微服務的架構。

 

 

若是開發團隊分爲前端團隊、後臺服務團隊和DBA團隊，產品將會成長爲下面的架構。

 

 

應用不斷迭代，功能日趨完善，開發團隊也隨之壯大。雖然如今有些人比較推崇全棧工程師，一位全棧工程師就能支持先後端的全部開發。可是試想一下，若是在開發團隊中先後端開發分隔不清，職責邊界模糊不明，代碼均由相同的工程師完成，久而久之先後端代碼的耦合程度可想而知。

 

經過將開發團隊先後端分離化，讓先後端工程師只須要專一於前端或後端的開發工做，使得先後端工程師分別自治，培養其獨特的技術特性，而後構建出一個全棧式的精益開發團隊。這樣的開發團隊可以快速應對需求的變動以及市場的複雜多變，打造出架構清晰、先後端並重的優質產品。

 

提高開發效率

 

傳統開發模式中，先後端開發強依賴。須要前端工程師先完成靜態頁面的Demo，後端工程師才能將頁面Demo翻譯成VM模板，若是前端頁面出現變更，又會須要先後端工程師再走一次開發流程，如此一來開發效率將會變得很低。

 

先後端分離之後，能夠實現先後端代碼的解耦，只要先後端溝通約定好應用所需接口以及接口參數，即可以開始並行開發，無需等待對方的開發工做結束。與此同時，即便需求發生變動，只要接口與數據格式不變，後端開發人員就不須要修改代碼，只要前端進行變更便可。如此一來整個應用的開發效率必然會有質的提高。

 

完美應對複雜多變的前端需求

 

Web應用的用戶體驗關注度與日俱增，使得應用的前端界面須要有華麗酷炫的外觀，簡單易用的操做，變化多樣的界面設計和個性化的自定義展現。這使得前端開始變重，邏輯複雜程度加大，渲染效果多樣化加重。

 

移動終端的大範圍普及，讓應用向着多終端化發展，這就要求前端頁面須要對不一樣終端的顯示都能進行配適。

 

傳統開發模式中，先後端工程師開發職責不明確，面對複雜多變的前端需求，開發團隊勢必會變得捉襟見肘、不堪重負。

 

若是開發團隊能完成先後端分離的轉型，打造優秀的先後端團隊，開發獨立化，讓開發人員作到專一專精，開發能力必然會有所提高，可以完美應對各類複雜多變的前端需求。

 

加強代碼可維護性

 

先後端分離後，應用的代碼再也不是先後端混合，只有在運行期纔會有調用依賴關係。應用代碼將會變得整潔清晰，不管是代碼閱讀仍是代碼維護都會比之前輕鬆。

 

 

 

3、我要不要「離」：4種場景

 

 

然而任何一項技術都不是銀彈，先後端分離也是如此。雖然先後端分離架構能帶來衆多優點，但終究得創建在開發團隊適合的基礎之上。咱們暫且之前端頁面的渲染效果與邏輯複雜程度把Web應用大體分爲輕前端、重前端、先後均衡三種類型，而後加上如今熱門的微服務架構應用，一塊兒探討一下什麼樣的Web應用適合進行先後端分離。

 

輕前端

頁面佈局簡單，顏色、字體類型較少

對前端界面的渲染效果沒有高要求，無動畫效果

只有少許、簡單的業務邏輯

只須要在不一樣終端上佈局能適應

 

對於這樣對前端渲染要求不高，業務邏輯簡單的輕前端應用來講，由於涉及到的前端技術並不複雜，因此不必追求先後端分離。將先後端代碼放到一塊兒，反而更方便進行開發，可是在開發過程當中須要作到關注點分離（Separate Concern）。

 

重前端

頁面佈局複雜，使用了多種顏色和字體

須要有較高的頁面渲染效果，有大量動畫

前端頁面中包含有複雜業務邏輯

須要在不一樣終端和瀏覽器上保證佈局適應和渲染效果

 

對於重前端應用，建議採用先後端分離架構，若是開發團隊中前端工程師不足，須要儘早完善前端團隊的建設，確保先後端並重。

 

先後均衡

頁面佈局適中，使用的顏色和字體種類很少

頁面中使用了少量動畫效果

業務邏輯較爲簡單，可下沉到後端實現

只須要在不一樣終端上佈局能適應

 

對於先後端均衡應用，建議綜合團隊的人員結構和將來發展方向進行考慮。若是在團隊中前端工程師的佔比不高，後續也沒有繼續發展前端的計劃，那麼就不建議過於追求先後端分離。若是對將來有更高指望，即便在前端工程師佔比不高的狀況下，依然建議團隊嘗試先後端分離轉型，開始着手培養合適的前端工程師。若是團隊中已經有了至關規模的前端工程師，建議當即轉向先後端分離，而且儘早作到先後端代碼分離，爲前端提供一個能夠進行開發調試的僞後端。

 

微服務架構應用

 

 

微服務架構應用由大量微服務提供者構成，共同爲用戶提供服務。在微服務架構中，不少微服務提供者都是基於SpringBoot實現的，經過API Getway（API網關）進行微服務的整合，而後在一個統一的前端門戶上爲用戶提供所需服務。

 

微服務基於SpringBoot開發，要達到快速交付的目的，而且每一個微服務的粒度都比較小，這必然須要微服務的先後端由不一樣的工程師分別實現，而後相互之間使用Restful進行通信。若是仍是沿用以前的開發模式，將會增大微服務架構應用的構建難度。而先後段分離模式正是解決這一難題的良藥。

 

 

4、分離部署方案淺析

 

先後端開發分離以後，應用在部署時也須要進行先後端分離。在進行先後端分離方案選擇的時候，須要結合項目的需求狀況和用戶羣體來考慮。目前業內較爲經常使用的先後端分離部署方案有以下幾種。

 

一、Nginx+Server

 

將前端資源部署在Nginx上，後端服務部署在常規的服務器。當瀏覽器發起訪問請求的時候，若是請求的是頁面資源，Nginx直接把資源返回到前端；若是請求是調用後端服務，則通過Nginx轉發到後端服務器，完成響應後經Nginx返回到瀏覽器。

 

 

這個方案比較簡單，易於實現，並且能達到先後端解耦的目的。

 

可是對於頁面量比較大，須要有良好SEO的應用來講，此方案缺點也較爲明顯。由於Nginx只是向瀏覽器返回頁面靜態資源，而國內的搜索引擎爬蟲只會抓取靜態數據，不會解析頁面中的js，這使得應用得不到良好的搜索引擎支持。同時由於Nginx不會進行頁面的組裝渲染，須要把靜態頁面返回到瀏覽器，而後完成渲染工做，這加劇了瀏覽器的渲染負擔。

 

二、Node+Server

 

這是淘寶所使用的先後端分離模式，在瀏覽器與後端服務器之間增長一個了Node Server做爲中間層，將前端資源部署到Node Server中。Node Server中還包含了一層Model Proxy，負責與服務端進行通訊。

瀏覽器發出的請求都被Node Server接收，而後經過Model Proxy調用後端服務器提供的服務。Node Server獲得後端服務器反饋，接着在Node Server中完成頁面的組裝渲染，把最終頁面返回給瀏覽器。

 

如此一來不只達到了先後端解耦的目的，還解決了瀏覽器渲染負擔太重的問題，爲SEO提供了比較好的支持。

 

但在這樣的模式中，瀏覽器全部發出的請求都須要通過Node Server進行中轉，而後才能到達後端服務器。在實際的應用中，並非全部的請求都須要頁面渲染，只要在頁面上直接調用後端服務器提供的服務便可。因此這個模式必然會對請求性能有所消耗

 

三、Nginx+Node+Server

 

爲了能解決方案2中請求性能損失的問題，咱們能夠考慮在其基礎之上增長Nginx。瀏覽器發起的請求通過Nginx進行分發，URL請求統一分發到Node Server，在Node Server中進行頁面組裝渲染；API請求則直接發送到後端服務器，完成響應。

 

目前在已經有一個名爲Goku的Go語言框架提供了這樣的先後端分離解決方案。

 

 

經過對三種先後端分離方案的對比能夠看出：

 

若是是企業級應用，不須要考慮對SEO的支持，瀏覽器渲染也能夠忽略不計，Nginx+Server的模式無疑是最好的選擇，實施成本相對來講比較低；

 

若是是互聯網應用，須要有良好的SEO支持，頁面渲染工做量大，那應該選擇Nginx+Node+Server的方案，各個方面都能獲得比較好的兼顧。

 

 

5、總結

 

先後端分離並不是僅僅只是先後端開發的分工，而是在開發期進行代碼存放分離、先後端開發職責分離，先後端可以獨立進行開發測試；在運行期進行應用部署分離，先後端之間經過HTTP請求進行通信。先後端分離的開發模式與傳統模式相比，能爲咱們提高開發效率、加強代碼可維護性，讓咱們有規劃地打造一個先後端並重的精益開發團隊，更好地應對愈來愈複雜多變的Web應用開發需求。

 

傳統的先後端混合開發模式，雖然久經考驗，到如今依然仍是能支撐起應用的開發。可是放眼將來，應用的雲化、微服務化勢不可擋。同社會分工精細化同樣，先後端開發的精細化也是必然趨勢。技術在持續進步，架構在不斷演進，只有緊跟發展的腳步，不斷調整項目管理方式，軟件開發模式，才能在互聯網浪潮中把握機會，乘風破浪。

 

先後端分離，是爲了讓彼此更好。