當前位置：首頁 > 單片機 > 架構師社區(qū)

[導讀]1.前言隨著互聯網的高速發(fā)展，前端頁面的展示、交互體驗越來越靈活、炫麗，響應體驗也要求越來越高，后端服務的高并發(fā)、高可用、高性能、高擴展等特性的要求也愈加苛刻，從而導致前后端研發(fā)各自專注于自己擅長的領域深耕細作。然而帶來的另一個問題：前后端的對接界面雙方卻關注甚少，沒有任何接口約...

1. 前言

隨著互聯網的高速發(fā)展，前端頁面的展示、交互體驗越來越靈活、炫麗，響應體驗也要求越來越高，后端服務的高并發(fā)、高可用、高性能、高擴展等特性的要求也愈加苛刻，從而導致前后端研發(fā)各自專注于自己擅長的領域深耕細作。

然而帶來的另一個問題：前后端的對接界面雙方卻關注甚少，沒有任何接口約定規(guī)范情況下各自擼起袖子就是干，導致我們在產品項目開發(fā)過程中，前后端的接口聯調對接
工作量占比在30%-50%左右，甚至會更高。往往前后端接口聯調對接及系統(tǒng)間的聯調對接都是整個產品項目研發(fā)的軟肋。

本文的主要初衷就是規(guī)范約定先行，盡量避免溝通聯調產生的不必要的問題，讓大家身心愉快地專注于各自擅長的領域。

2. 為何要分離

參考兩篇文章《Web 研發(fā)模式的演變》、《Web應用的組件化開發(fā)》, 目前現有前后端開發(fā)模式：“后端為主的MVC時代”，如下圖所示：

后端為主的MVC時代

代碼可維護性得到明顯好轉，MVC 是個非常好的協作模式，從架構層面讓開發(fā)者懂得什么代碼應該寫在什么地方。為了讓 View 層更簡單干脆，還可以選擇 Velocity、Freemaker 等模板，使得模板里寫不了 Java 代碼。看起來是功能變弱了，但正是這種限制使得前后端分工更清晰。然而依舊并不是那么清晰，這個階段的典型問題是：

前端開發(fā)重度依賴開發(fā)環(huán)境，開發(fā)效率低。這種架構下，前后端協作有兩種模式：一種是前端寫demo，寫好后，讓后端去套模板?。淘寶早期包括現在依舊有大量業(yè)務線是這種模式。好處很明顯，demo 可以本地開發(fā)，很高效。不足是還需要后端套模板，有可能套錯，套完后還需要前端確定，來回溝通調整的成本比較大。另一種協作模式是前端負責瀏覽器端的所有開發(fā)和服務器端的 View 層模板開發(fā)，支付寶是這種模式。?好處是 UI 相關的代碼都是前端去寫就好，后端不用太關注，不足就是前端開發(fā)重度綁定后端環(huán)境，環(huán)境成為影響前端開發(fā)效率的重要因素。
前后端職責依舊糾纏不清。Velocity 模板還是蠻強大的，變量、邏輯、宏等特性，依舊可以通過拿到的上下文變量來實現各種業(yè)務邏輯。這樣，只要前端弱勢一點，往往就會被后端要求在模板層寫出不少業(yè)務代碼。還有一個很大的灰色地帶是 Controller，頁面路由等功能本應該是前端最關注的，但卻是由后端來實現。Controller 本身與 Model 往往也會糾纏不清，看了讓人咬牙的業(yè)務代碼經常會出現在 Controller 層。這些問題不能全歸結于程序員的素養(yǎng)，否則 JSP 就夠了。
對前端發(fā)揮的局限。性能優(yōu)化如果只在前端做空間非常有限，于是我們經常需要后端合作才能碰撞出火花，但由于后端框架限制，我們很難使用Comet、Bigpipe等技術方案來優(yōu)化性能。

總上所述，就跟為什麼要代碼重構一樣：

關注點分離
職責分離
對的人做對的事
更好的共建模式
快速的反應變化

3. 什么是分離

我們現在要做的前后分離第一階段：“基于 Ajax 帶來的 SPA 時代”，如圖：

基于 Ajax 帶來的 SPA 時代

這種模式下，前后端的分工非常清晰，前后端的關鍵協作點是 Ajax 接口。?看起來是如此美妙，但回過頭來看看的話，這與 JSP 時代區(qū)別不大。復雜度從服務端的 JSP 里移到了瀏覽器的 JavaScript，瀏覽器端變得很復雜。類似 Spring MVC，這個時代開始出現瀏覽器端的分層架構：

瀏覽器端的分層架構

對于這一SPA階段，前后端分離有幾個重要挑戰(zhàn)：

前后端接口的約定。?如果后端的接口一塌糊涂，如果后端的業(yè)務模型不夠穩(wěn)定，那么前端開發(fā)會很痛苦。這一塊在業(yè)界有 API Blueprint 等方案來約定和沉淀接口，==在阿里，不少團隊也有類似嘗試，通過接口規(guī)則、接口平臺等方式來做。有了和后端一起沉淀的接口規(guī)則，還可以用來模擬數據，使得前后端可以在約定接口后實現高效并行開發(fā)。== 相信這一塊會越做越好。
前端開發(fā)的復雜度控制。?SPA 應用大多以功能交互型為主，JavaScript 代碼過十萬行很正常。大量 JS 代碼的組織，與 View 層的綁定等，都不是容易的事情。典型的解決方案是業(yè)界的 Backbone，但 Backbone 做的事還很有限，依舊存在大量空白區(qū)域需要挑戰(zhàn)。

4. 如何做分離

4.1 職責分離

職責分離

前后端僅僅通過異步接口(AJAX/JSONP)來編程
前后端都各自有自己的開發(fā)流程，構建工具，測試集合
關注點分離，前后端變得相對獨立并松耦合

后端	前端
提供數據	接收數據，返回數據
處理業(yè)務邏輯	處理渲染邏輯
Server-side MVC架構	Client-side MV* 架構
代碼跑在服務器上	代碼跑在瀏覽器上

4.2 開發(fā)流程

后端編寫和維護接口文檔，在 API 變化時更新接口文檔
后端根據接口文檔進行接口開發(fā)
前端根據接口文檔進行開發(fā) Mock平臺
開發(fā)完成后聯調和提交測試

Mock 服務器根據接口文檔自動生成 Mock 數據，實現了接口文檔即API：

開發(fā)流程

4.3 具體實施

現在已基本完成了，接口方面的實施：

接口文檔服務器：可實現接口變更實時同步給前端展示；
Mock接口數據平臺：可實現接口變更實時Mock數據給前端使用；
接口規(guī)范定義：很重要，接口定義的好壞直接影響到前端的工作量和實現邏輯；具體定義規(guī)范見下節(jié)；

接口文檔 Mock平臺服務器

5. 接口規(guī)范V1.0.0

5.1 規(guī)范原則

接口返回數據即顯示：前端僅做渲染邏輯處理；
渲染邏輯禁止跨多個接口調用；
前端關注交互、渲染邏輯，盡量避免業(yè)務邏輯處理的出現；
請求響應傳輸數據格式：JSON，JSON數據盡量簡單輕量，避免多級JSON的出現；

5.2 基本格式

5.2.1 請求基本格式

GET請求、POST請求==必須包含key為body的入參，所有請求數據包裝為JSON格式，并存放到入參body中==，示例如下：

GET請求：

xxx/login?body={"username":"admin","password":"123456","captcha":"scfd","rememberMe":1}

POST請求：
POST請求

5.2.2 響應基本格式

{
????code:?200,
????data:?{
????????message:?"success"
????}
}

code : 請求處理狀態(tài)

200: 請求處理成功
500: 請求處理失敗
401: 請求未認證，跳轉登錄頁
406: 請求未授權，跳轉未授權提示頁

data.message: 請求處理消息

code=200 且 data.message="success": 請求處理成功
code=200 且 data.message!="success": 請求處理成功, 普通消息提示：message內容
code=500: 請求處理失敗，警告消息提示：message內容

5.3 響應實體格式

{
????code:?200,
????data:?{
????????message:?"success",
????????entity:?{
????????????id:?1,
????????????name:?"XXX",
????????????code:?"XXX"
????????}
????}
}

data.entity: 響應返回的實體數據

5.4 響應列表格式

{
????code:?200,
????data:?{
????????message:?"success",
????????list:?[
????????????{
????????????????id:?1,
????????????????name:?"XXX",
????????????????code:?"XXX"
????????????},
????????????{
????????????????id:?2,
????????????????name:?"XXX",
????????????????code:?"XXX"
????????????}
????????]
????}
}

data.list: 響應返回的列表數據

5.5 響應分頁格式

{
????code:?200,
????data:?{
????????recordCount:?2,
????????message:?"success",
????????totalCount:?2,
????????pageNo:?1,
????????pageSize:?10,
????????list:?[
????????????{
????????????????id:?1,
????????????????name:?"XXX",
????????????????code:?"H001"
????????????},
????????????{
????????????????id:?2,
????????????????name:?"XXX",
????????????????code:?"H001"
????????????}?],
????????totalPage:?1
????}
}

data.recordCount: 當前頁記錄數
data.totalCount: 總記錄數
data.pageNo: 當前頁碼
data.pageSize: 每頁大小
data.totalPage: 總頁數

5.6 特殊內容規(guī)范

5.6.1 下拉框、復選框、單選框

由后端接口統(tǒng)一邏輯判定是否選中，通過isSelect標示是否選中，示例如下：

{
????code:?200,
????data:?{
????????message:?"success",
????????list:?[{
????????????id:?1,
????????????name:?"XXX",
????????????code:?"XXX",
????????????isSelect:?1
????????},?{
????????????id:?1,
????????????name:?"XXX",
????????????code:?"XXX",
????????????isSelect:?0
????????}]
????}
}