前言：分離模式

　　對(duì)前后端分離研究了一段時(shí)間，恰逢公司有一個(gè)大項(xiàng)目決定嘗試使用前后端分離模式進(jìn)行，便參與其中。該項(xiàng)目從2016年初立項(xiàng)至今，平平穩(wěn)穩(wěn)得度過(guò)，但也涌現(xiàn)出越來(lái)越多的問(wèn)題，絕對(duì)不是說(shuō)前后端分離模式不好，而是很多公司在嘗試前后端分離的時(shí)候沒(méi)有做好充分得準(zhǔn)備。

　　網(wǎng)上對(duì)前后端分離介紹的文章已經(jīng)屢見(jiàn)不鮮，接下來(lái)本人用一點(diǎn)粗淺的言語(yǔ)也談?wù)勥@塊，獻(xiàn)丑了。

為什么要分離？

　　如果只問(wèn)“前后端分離的意義大么？”這是廢話(huà)，因?yàn)閺能浖軜?gòu)的角度 Web 的前后端從一開(kāi)始不就一直是分離的么，而且 browser、server 可能將永遠(yuǎn)分離下去。

　　為了了解這個(gè)問(wèn)題，我們有必要先了解一下 Web的研發(fā)模式演變，關(guān)于這個(gè)題材，下面這篇博文說(shuō)得不錯(cuò)，這邊就不做搬運(yùn)工了。

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

　　我們不能“為了分離而分離”，而應(yīng)該“為了真正理解web開(kāi)發(fā)、為了更好完成需求而分離”。

前后端分離的誤區(qū)？

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

　　由于所在公司以往項(xiàng)目采用傳統(tǒng)開(kāi)發(fā)風(fēng)格，即以后端MVC為主的開(kāi)發(fā)模式，前端人員僅僅提供靜態(tài)html頁(yè)面，其余工作皆由后端開(kāi)發(fā)人員完成。采用前后端分離模式可以減后臺(tái)負(fù)擔(dān)，加快研發(fā)效率，當(dāng)然，前提是前端能做好的話(huà)。以往只需要提供靜態(tài)頁(yè)面的前端人員，在前后端分離模式中要負(fù)責(zé)項(xiàng)目的view+controller部分，即除了靜態(tài)頁(yè)面，還需要負(fù)責(zé)頁(yè)面的所有交互代碼、以及nodejs與視圖層以及后端API的交互工作，無(wú)疑增加了前端人員的學(xué)習(xí)成本，在沒(méi)有足夠知識(shí)和人才儲(chǔ)備的情況下，只能讓前端人員加班加點(diǎn)。結(jié)果是大量前端人員離職（PS：做這么多事，工資總得加吧！）

　　2、前后端職責(zé)分配？

　　很多公司認(rèn)為采用前后端分離之后，前后端只需要通過(guò)指定API進(jìn)行交互即可，前端負(fù)責(zé)頁(yè)面渲染，Nodejs負(fù)責(zé)路由分配，后端提供API。忽視了大量關(guān)鍵工作，職責(zé)分配和細(xì)節(jié)處理沒(méi)有相應(yīng)文檔規(guī)定，緩存機(jī)制、圖片上傳下載、數(shù)據(jù)校驗(yàn)、語(yǔ)言國(guó)際化等等并沒(méi)有出具相應(yīng)信息。另外，大量忽視了nodejs層的作用，僅僅把nodejs當(dāng)成一個(gè)路由中轉(zhuǎn)，這一方面也是對(duì)nodejs技術(shù)的不熟悉導(dǎo)致的，其實(shí)nodejs能負(fù)責(zé)很多事，除了復(fù)雜業(yè)務(wù)邏輯處理和數(shù)據(jù)操作由Java 負(fù)責(zé)，大量工作完全可以在nodejs層處理。（PS：還是基礎(chǔ)不夠?qū)е碌?#xff01;）

　　3、后端API是否Restful風(fēng)格？

　　很多公司采用了前后端分離模式后，后端API仍然采用以往的傳統(tǒng)風(fēng)格，這是不合理的，Restful風(fēng)格的API應(yīng)該是前后端分離的最佳實(shí)踐。ResultFul推薦每個(gè)URL能操作具體的資源,而且能準(zhǔn)確描述服務(wù)器對(duì)資源的處理動(dòng)作，通常服務(wù)器對(duì)資源支持get/post/put/delete/等，用來(lái)實(shí)現(xiàn)資源的增刪改查。前后端分離的話(huà)，這些api-url是對(duì)接的橋梁，采用resultFul接口地址含義才更清晰、見(jiàn)名知意。（PS：用了Spring4.x 竟然還不用rest風(fēng)格，說(shuō)不過(guò)去啊）

　　4、前后端協(xié)作模式？

　　前后端分離后，無(wú)論是API接口的對(duì)接還是測(cè)試工作，都涉及到前后端人員的溝通，很多公司采用前后端分離后，前后端協(xié)作模式配合力度底，互相等待，開(kāi)發(fā)效率低下，反而不如傳統(tǒng)的開(kāi)發(fā)模式。例如：當(dāng)后端 API 沒(méi)有編寫(xiě)完成時(shí)，前端無(wú)法進(jìn)行調(diào)試，這就導(dǎo)致了前端會(huì)被后端阻塞的情況。其實(shí)像這種互相等待的模式需要改進(jìn)，?Mock Server 可能可以解決一些問(wèn)題。

如何前后端分離？

　　怎么做前后端分離？大方向就是

　　后端專(zhuān)注于：后端控制層（Restful API）?& 服務(wù)層 & 數(shù)據(jù)訪問(wèn)層；

　　前端專(zhuān)注于：前端控制層（Nodejs） & 視圖層

　　本人認(rèn)為的前后端分離模式應(yīng)該是這樣，當(dāng)然這不一定正確：

　　1、項(xiàng)目設(shè)計(jì)階段，前后端架構(gòu)負(fù)責(zé)人將項(xiàng)目整體進(jìn)行分析，討論并確定API風(fēng)格、職責(zé)分配、開(kāi)發(fā)協(xié)助模式，確定人員配備；設(shè)計(jì)確定后，前后端人員共同制定開(kāi)發(fā)接口。

　　2、項(xiàng)目開(kāi)發(fā)階段，前后端分離是各自分工，協(xié)同敏捷開(kāi)發(fā)，后端提供Restful API，并給出詳細(xì)文檔說(shuō)明，前端人員進(jìn)行頁(yè)面渲染前臺(tái)的任務(wù)是發(fā)送API請(qǐng)(GET,PUT,POST,DELETE等)獲取數(shù)據(jù)（json，xml）后渲染頁(yè)面。

　　3、項(xiàng)目測(cè)試階段，API完成之前，前端人員會(huì)使用mock server進(jìn)行模擬測(cè)試，后端人員采用junit進(jìn)行API單元測(cè)試，不用互相等待；API完成之后，前后端再對(duì)接測(cè)試一下就可以了，當(dāng)然并不是所有的接口都可以提前定義，有一些是在開(kāi)發(fā)過(guò)程中進(jìn)行調(diào)整的。

　　4、項(xiàng)目部署階段，利用nginx 做反向代理，即Java + nodejs + nginx 方式進(jìn)行。

編后語(yǔ)

　　從經(jīng)典的JSP+Servlet+JavaBean的MVC時(shí)代，到SSM（Spring + SpringMVC + Mybatis）和SSH（Spring + Struts + Hibernate）的Java 框架時(shí)代，再到前端框架（KnockoutJS、AngularJS、vueJS、ReactJS）為主的MV*時(shí)代，然后是Nodejs引領(lǐng)的全棧時(shí)代，技術(shù)和架構(gòu)一直都在進(jìn)步。雖然“基于NodeJS的全棧式開(kāi)發(fā)”模式很讓人興奮，但是把基于Node的全棧開(kāi)發(fā)變成一個(gè)穩(wěn)定，讓大家都能接受的東西還有很多路要走。創(chuàng)新之路不會(huì)止步，無(wú)論是前后端分離模式還是其他模式，都是為了更方便得解決需求，但它們都只是一個(gè)“中轉(zhuǎn)站”。

　　走過(guò)的“中轉(zhuǎn)站”可能越來(lái)越多，但是不要漸行漸遠(yuǎn)才是。

總結(jié)

以上是生活随笔為你收集整理的《浅谈架构之路：前后端分离模式》 - 山人行 - 博客园的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。