摘要：如何去解決這些問(wèn)題前后端分離大部分的互聯(lián)網(wǎng)公司都分成了前端團(tuán)隊(duì)和后端團(tuán)隊(duì)。方案一采用架構(gòu)業(yè)界很多公司會(huì)采用，單頁(yè)應(yīng)用的架構(gòu)，這種架構(gòu)是天然的前后端分離的。方案二淘寶的大前端方案中途島上圖是淘寶基于的前后端分離分層，以及的職責(zé)范圍。

1.前端無(wú)法調(diào)試后端未完成的 API：如果后端同學(xué)還沒有完成 API 開發(fā)，那么前端同學(xué)就不能對(duì)這個(gè) API 進(jìn)行開發(fā)。之前我們都是在代碼里直接通過(guò)給變量賦假數(shù)據(jù)，又或者是在后端 Controller 里直接 return JSON 的方式來(lái)進(jìn)行調(diào)試的。這樣的方式很容易會(huì)出現(xiàn)的情況就是，每次提交 commit 都要把它刪除掉，有時(shí)忘了沒有刪除掉，那么提交歷史就會(huì)變得很臟。

2.沒有自動(dòng)化測(cè)試：前端對(duì)接口的調(diào)用沒有做自動(dòng)化的測(cè)試。

3.前端需要依賴后端開發(fā)環(huán)境：前端需要后端環(huán)境來(lái)在本地測(cè)試，像我們使用的方案就是 Vagrant + 虛擬機(jī)的來(lái)開發(fā)。這樣的方式其實(shí)很笨重，不但每次啟動(dòng)虛擬機(jī)都得等一段時(shí)間，而且會(huì)占用一定的 CPU 和內(nèi)存資源，拖慢機(jī)器。然而，前端需要的只是數(shù)據(jù)。

如何去解決這些問(wèn)題？ ——前后端分離
大部分的互聯(lián)網(wǎng)公司都分成了前端團(tuán)隊(duì)和后端團(tuán)隊(duì)。在軟件設(shè)計(jì)中，我們有一個(gè)思想就是 Separation of Concerns (Soc)，也就是 關(guān)注點(diǎn)分離 的思想。既然我們采用了前后端由不同團(tuán)隊(duì)開發(fā)的模式，那么我們應(yīng)該有分治的思想，也就是說(shuō)，我們要盡可能更多地關(guān)注自己從事的領(lǐng)域。

1.框架層面

前后端倉(cāng)庫(kù)的分離：

整個(gè)前端工程使用git subtree從后端Git工程中切分出來(lái)。后端應(yīng)用均使用同一個(gè)前端代碼庫(kù)。

前端只clone前端代碼，啟動(dòng)前端工程。前端使用sever來(lái)mock數(shù)據(jù)渲染ftl模板以及頁(yè)面展示

2.開發(fā)層面

前后端約定好接口，各自開發(fā)；節(jié)約時(shí)間（但聯(lián)調(diào)的時(shí)間可能增加），接口有更新及時(shí)溝通

前后端分離 開發(fā)流程圖

上線可以只上前端或后端代碼

怎么做前后端分離，我們認(rèn)為的前后端分離

前端：負(fù)責(zé)View和Controller層。

后端：負(fù)責(zé)Model層，業(yè)務(wù)處理/數(shù)據(jù)處理等。

前后端分離插圖 前后端分工 1

試想一下，如果前端掌握了Controller，我們可以做url design，我們可以根據(jù)場(chǎng)景決定在服務(wù)端同步渲染，還是根據(jù)view層數(shù)據(jù)輸出json數(shù)據(jù)，我們還可以根據(jù)表現(xiàn)層需求很容易的做 Bigpipe,Comet,Socket等等，完全是需求決定使用方式。

實(shí)際上，現(xiàn)在很多的成熟的網(wǎng)站都沒有做到上面的設(shè)計(jì)，很多時(shí)候后端也負(fù)責(zé)一部分View的渲染，例如很多的后端模版，有的時(shí)候這是很需要的。所以我們現(xiàn)在所談的前后端分離，更多的是基于上面我們所遇到的問(wèn)題出發(fā)，即基于現(xiàn)有的前后端共同渲染View，但前端又能獨(dú)立開發(fā)的優(yōu)化角度出發(fā)。

方案一：采用 SPA 架構(gòu)
業(yè)界很多公司會(huì)采用 SPA（Single Page Application，單頁(yè)應(yīng)用）的架構(gòu)，這種架構(gòu)是天然的前后端分離的。所有的數(shù)據(jù)都是后端通過(guò) JSON 的形式來(lái)傳遞到前端，前端本身也有自己的 MV* 框架，從物理上實(shí)現(xiàn)了前后端分離。

WEB服務(wù)中，SPA類占的比例很少。很多場(chǎng)景下還有同步/同步+異步混合的模式，SPA不能作為一種通用的解決方案。

方案二：淘寶 UED 的大前端方案（中途島）
Abc

上圖是淘寶基于Node的前后端分離分層，以及Node的職責(zé)范圍。簡(jiǎn)單解釋下：

－最上端是服務(wù)端，就是我們常說(shuō)的后端。后端對(duì)于我們來(lái)說(shuō)，就是一個(gè)接口的集合，服務(wù)端提供各種各樣的接口供我們使用。因?yàn)橛蠳ode層，也不用局限是什么形式的服務(wù)。對(duì)于后端開發(fā)來(lái)說(shuō)，他們只用關(guān)心業(yè)務(wù)代碼的接口實(shí)現(xiàn)。
－服務(wù)端下面是Node應(yīng)用。
－Node應(yīng)用中有一層Model Proxy與服務(wù)端進(jìn)行通訊。這一層主要目前是抹平我們對(duì)不同接口的調(diào)用方式，封裝一些view層需要的Model。
－Node層還能輕松實(shí)現(xiàn)原來(lái)vmcommon,tms（引用淘寶內(nèi)容管理系統(tǒng)）等需求。
－Node層要使用什么框架由開發(fā)者自己決定。不過(guò)推薦使用express+xTemplate的組合，xTemplate能做到前后端公用。
－怎么用Node大家自己決定，但是令人興奮的是，我們終于可以使用Node輕松實(shí)現(xiàn)我們想要的輸出方式:JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同步、異步，想怎么整就怎么整，完全根據(jù)你的場(chǎng)景決定。
－瀏覽器層在我們這個(gè)架構(gòu)中沒有變化，也不希望因?yàn)橐隢ode改變你以前在瀏覽器中開發(fā)的認(rèn)知。
－引入Node，只是把本該就前端控制的部分交由前端掌控。
淘寶 UED 的大前端方案的思想是非常先進(jìn)的，在前端 HTML/CSS/JS 和后端 Java 之間，架設(shè)了一層 NodeJS，把 View 層和 Controller 層都交由前端團(tuán)隊(duì)去開發(fā)，后端團(tuán)隊(duì)只負(fù)責(zé) Modal 層。然而，這種方案對(duì)項(xiàng)目的改動(dòng)將非常大，改造成本非常高。做到了真正的前后端分離。這并不是我們所要談?wù)摰?。有興趣的可以搜索下相關(guān)的文章。

方案三：構(gòu)建 Mock Server
Mock Server 的概念非常簡(jiǎn)單，就是在開發(fā)環(huán)境構(gòu)建一個(gè)模擬的服務(wù)器，然后構(gòu)建假數(shù)據(jù)（Mock Data），再利用構(gòu)建的假數(shù)據(jù)來(lái)進(jìn)行開發(fā)。

這種方法的好處：

靈活性高：它小到可以只攔截一個(gè) HTTP 請(qǐng)求，對(duì)某一個(gè) API 進(jìn)行調(diào)試；大到前端可以完全使用 Mock Server 進(jìn)行開發(fā)，在本地完全不需要跑后端服務(wù)器。所以它可以以非常平滑柔和的方式融入到前端項(xiàng)目的開發(fā)當(dāng)中。

構(gòu)建簡(jiǎn)單：我們甚至只需要通過(guò) Fiddler 或者 Charles 等抓包攔截軟件，就可以完成一個(gè) Mock Server 的構(gòu)建。

能自動(dòng)生成 API：由于數(shù)據(jù)和接口都是確定的，所以我們可以利用它來(lái)創(chuàng)建 API 文檔，便于前后端開發(fā)。

能為自動(dòng)化測(cè)試鋪路：同樣是由于數(shù)據(jù)和接口都是確定的，所以我們還可以利用它來(lái)做單元測(cè)試。

前后端分離插圖 如何對(duì)我們的項(xiàng)目進(jìn)行改造

我們想要的Mock數(shù)據(jù)的樣子：

1.全工程的數(shù)據(jù)都要Mock；
2.在固定平臺(tái)上創(chuàng)建接口，接口的請(qǐng)求參數(shù)和返回參數(shù)靈活配置；
3.能通過(guò)簡(jiǎn)單的命令實(shí)現(xiàn)數(shù)據(jù)的Mock；
4.只啟動(dòng)前端工程，不啟動(dòng)后端工程；
網(wǎng)上有很多的開源技術(shù)，可以實(shí)現(xiàn)Mock數(shù)據(jù)的功能;
1.sosoapi

Demo1

2.taobo rap的項(xiàng)目,RAP

Demo2

上面開源技術(shù)的優(yōu)缺點(diǎn):

特點(diǎn)：友好的圖形界面，完整的接口文檔

缺點(diǎn)：接口完全托管在網(wǎng)站上，安全隱患

簡(jiǎn)單的數(shù)據(jù)偽造，只實(shí)現(xiàn)本地的數(shù)據(jù)偽造（無(wú)接口文檔）
1.Mock.js

使用參考

Ll

2.faker.js

API參考

Demo5

特點(diǎn)：安全性高，產(chǎn)生本地?cái)?shù)據(jù);根據(jù)語(yǔ)法產(chǎn)生對(duì)應(yīng)的數(shù)據(jù)

缺點(diǎn)：無(wú)圖形界面，手動(dòng)編寫接口文檔

很多時(shí)候，我們寫單頁(yè)面應(yīng)用時(shí)，都需要啟動(dòng)一個(gè)本地sever，這里推薦puer。簡(jiǎn)而言之，Puer是一個(gè)可以實(shí)時(shí)編輯刷新的前端服務(wù)器；同時(shí)它還兼有模擬數(shù)據(jù)的功能。

文檔型
apiary

Se

swagger editor

特點(diǎn)：優(yōu)美的接口文檔

缺點(diǎn)：無(wú)圖形界面，編寫文檔學(xué)習(xí)成本高；適合后端編寫接口文檔

總結(jié):
如果要做工程性的，要建立起我們開始介紹固定站點(diǎn)，圖形化錄入和展示接口；并建立起和工程結(jié)合的mock數(shù)據(jù)功能。
如果我們只是開發(fā)單頁(yè)面應(yīng)用，可以使用Mock.js來(lái)模擬單一化的數(shù)據(jù)。
如果要寫接口文檔，建議使用apiary。
簡(jiǎn)單的先做以上的介紹。

[參考]：
https://www.zhihu.com/questio...