先後端分離實踐（一）

前言

最近這一段時間因爲Nodejs的逐漸成熟和日趨穩定，愈來愈多的公司中的前端團隊開始嘗試使用Nodejs來練一下手，嘗一嚐鮮。

通常的作法都是將本來屬於後端的一部分相對於業務不是很重要的功能遷移到Nodejs上面來，也有一些公司將NodeJS做爲先後端分離的一個解決方案去施行。而像淘寶網這類的大型網站也很早的完成了先後端的分離，給咱們這樣的後來者提供了寶貴的經驗。

一樣，咱們的大網盤團隊也早在去年早早就開始了緊鑼密佈的準備工做，這目前工做也作的差很少了，如今我就來總結一下在過程當中遇到的坑點以及注意事項。

認識先後端分離

在傳統的web應用開發中，大多數的程序員會將瀏覽器做爲先後端的分界線。將瀏覽器中爲用戶進行頁面展現的部分稱之爲前端，而將運行在服務器，爲前端提供業務邏輯和數據準備的全部代碼統稱爲後端。

因爲先後端分離這個概念相對來講剛出現不久，不少人都是隻聞其聲，不見其形，因此可能會對它產生一些誤解，誤覺得先後端分離只是一種web應用開發模式，只要在web應用的開發期進行了先後端開發工做的分工就是先後端分離。

其實先後端分離並不僅是開發模式，而是web應用的一種架構模式。在開發階段，先後端工程師約定好數據交互接口，實現並行開發和測試；在運行階段先後端分離模式須要對web應用進行分離部署，先後端以前使用HTTP或者其餘協議進行交互請求。然而做爲一種架構模式，咱們在實施的過程當中主要對如下四個方面來進行比較和從新認識。

先後端分離大概能夠從四個方面來理解：

1. 交互形式

2. 代碼組織方式

3. 開發模式

4. 數據接口規範流程

1、交互形式

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

2、代碼組織方式

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

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

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

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

3、開發模式

咱們以前的架構屬於傳統的MVC架構，總體沒有進行先後端分離，在項目的開發階段，前端工程師負責編寫HTML，完成前端的頁面設計並套頁面，而後再使用模板技術將寫好的前端代碼轉換爲Smarty腳本，同時內嵌一些後端提供的模板變量和一些邏輯操做。應用運行期，將所有代碼進行打包，和後端代碼部署到同一服務器上，同時會進行簡單的動靜態分離部署。

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

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

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

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

4、數據接口規範流程

在開發期間先後端共同商定好數據接口的交互形式和數據格式。而後實現先後端的並行開發，其中前端工程師再開發完成以後能夠獨自進行mock測試，然後端也可使用接口測試平臺進行接口自測，而後先後端一塊兒進行功能聯調並校驗格式，最終進行自動化測試。

分離的四個好處

先後端分離模式和傳統的web應用架構相比有很大的不一樣，到底分仍是不分，這還真是個問題。

從目前應用軟件開發的發展趨勢來看，主要有兩方面須要注意：

1. 愈來愈注重用戶體驗，隨着互聯網的發展，開始多終端化。

2. 大型應用架構模式正在向雲化、微服務化發展。

咱們主要經過先後端分離架構，爲咱們帶來如下四個方面的提高：

• 爲優質產品打造精益團隊
  經過將開發團隊先後端分離化，讓先後端工程師只須要專一於前端或後端的開發工做，是的先後端工程師實現自治，培養其獨特的技術特性，而後構建出一個全棧式的精益開發團隊。

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

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

• 加強代碼可維護性
  先後端分離後，應用的代碼再也不是先後端混合，只有在運行期纔會有調用依賴關係。

應用代碼將會變得整潔清晰，不管是代碼閱讀仍是代碼維護都會比之前輕鬆。

須要進行先後端分離的場景

任何一項技術以及架構都不是適用於任何場景，先後端分離一樣也是如此。雖然先後端分離架構能帶來許多的好處，但前提是創建在開發團隊合適的基礎上的。

而咱們百度網盤就屬於那種：

1. 頁面佈局複雜，使用了主題和樣式。

2. 須要有較高的頁面渲染效果

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

4. 頁面須要渲染的數據量較大

像這種重前端的應用咱們綜合考慮了各類狀況，最終決定採用先後端分離架構。

部署方案

先後端分離以後，應用在部署時也須要進行先後端分離。在進行先後端分離方案選擇時，須要結合項目的實際狀況和用戶來考慮。

分離以前的架構

先後端分離以前，網盤的後端架構是Nginx服務和後端的PHP服務以及前端的靜態資源都是部署在同一臺服務器上。當瀏覽器發起訪問請求時，如何請求的是靜態資源，Nginx直接把靜態資源返回給服務器；若是請求的是頁面或後端服務，則經Nginx將請求轉發到後端的PHP服務器，完成響應後經Nginx返回到瀏覽器。

注：此圖中的Nginx屬於後端機，主要針對前端機Nginx轉發過來的請求進行識別弄轉發給本機的PHP服務；前端機和後端機各有一個Nginx服務。

這個方案比較簡單，易於實現，並且能到達先後端解耦的目的。並且不少公司目前都是基於這種架構或者必定的變形來實現的web應用。

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

另外，因爲這種架構使得前端工程師的工做範圍只侷限在了瀏覽器一側，致使在進行一些特殊的性能優化時，前端工程師沒法獨立完成，還須要後端開發人員的配合，這也必定程度上影響了雙方的進度。

分離以後的架構

先後端分離以後，咱們在原先的架構只上再單獨增長了一個Node Server做爲中間層，將前端資源部署到Node Server中。Node Server還實現了一層數據代理服務，負責與提供數據的後端服務進行通訊。

而且還在這個基礎上增長並使用了前端機（前端機是對全部的請求進行預處理和負載均衡，而後再轉發給後端機。）的Nginx服務，瀏覽器發起的請求通過前端機的Nginx進行分發，URL請求統一分發到Node Server，在Node Server中根據請求類型從後端服務器上經過RPC服務請求頁面的模板數據，而後進行頁面的組裝和渲染；API請求則直接轉發到後端服務器，完成響應。

注：此圖中的Nginx屬於前端機。

先後端分離方案對比

實現和部署

下一篇將爲你們分享百度網盤先後端分離中的Node Server基礎架構、前端路由管理、模板數據交互以及運維和環境部署相關內容。

結語

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