網(wǎng)絡(luò)公司做網(wǎng)站注重前后分離，什么是前后端分離,傳統(tǒng)開發(fā)模式相信很多做過Web開發(fā)童鞋應(yīng)該都會經(jīng)歷這樣一種開發(fā)模式，利用后端語言提供的模版引擎編寫HTML／XML頁面，比如：<br /> <br /> PHP 開發(fā)有 Smarty模板引擎<br /> <br /> Java web工程有jsp頁面<br /> <br /> Python 各個(gè)Web框架都有各自的模板引擎<br /> <br /> NodeJS 的express你懂得<br /> <br /> 都有一個(gè)共同的特點(diǎn)，服務(wù)器端后臺語言生成解析后的HTML/XML格式返回給客戶端，例如瀏覽器端訪問直接返回解析好的HTML，瀏覽器直接就解釋執(zhí)行。<br /> <br /> 在傳統(tǒng)的像ASP，JSP和PHP等開發(fā)模式中，前端是處在一個(gè)混沌的狀態(tài)中，可以說是沒有獨(dú)立的“人格”可言。<br /> <br /> 前端負(fù)責(zé)切圖和編寫靜態(tài)頁面模板，后端將數(shù)據(jù)渲染到前端提供的頁面模板中，最后將頁面渲染到瀏覽器展示。<br /> <br /> 這個(gè)過程中，前端只提供頁面模板或者寫一些JavaScript腳本，有的甚至JS腳本都是后端來寫，前端的作用只局限于切圖和樣式模板文件，這種角色就是傳說中的“切圖仔”。<br /> <br /> 前后端分離，不只是簡單的代碼的分離。<br /> <br /> 首先是要架構(gòu)上分離解耦，逐漸擺脫前后端在架構(gòu)上的依賴，前后端各司其職，分開部署在不同的服務(wù)器上，通過RESTful接口傳遞數(shù)據(jù)。減輕后端服務(wù)器的壓力，后端服務(wù)器不再負(fù)責(zé)頁面渲染，只負(fù)責(zé)輸入數(shù)據(jù)，吞吐量提升了好幾倍。<br /> <br /> 其次是邏輯分離，不分離的時(shí)候，對于業(yè)務(wù)代碼的界限很不明確，業(yè)務(wù)邏輯基本都放在后端，分離之后，前端也承擔(dān)了一部分不該后端來寫的業(yè)務(wù)邏輯，數(shù)據(jù)處理更加清晰。<br /> <br /> 最后是系統(tǒng)分離，同一個(gè)后端系統(tǒng)，可以將同樣的接口數(shù)據(jù)提供給PC端、Mobile端和Native端等不同的前端終端，不需要為每一種終端提供一套接口。同樣，對于前端應(yīng)用來說，可以更方便的調(diào)用多個(gè)后端服務(wù)器的接口，處理和展示多個(gè)系統(tǒng)間的數(shù)據(jù)。<br /> <br /> 為什么要前后端分離<br /> 前后端分離，讓軟件開發(fā)的流程更加清晰，解決了開發(fā)階段的痛點(diǎn)。<br /> <br /> 從前，前端不止要學(xué)習(xí)后端的模板渲染語法，還要配置后端的開發(fā)環(huán)境，并不斷同步后端的代碼，這對于前端來說是非常痛苦的。<br /> <br /> 而現(xiàn)在，前端有自己的服務(wù)器，不需要再依靠后端服務(wù)器來支持項(xiàng)目運(yùn)行，如果在開發(fā)階段，還可以使用mock數(shù)據(jù)（要先和后端確定接口數(shù)據(jù)結(jié)構(gòu)），擺脫對后端接口的依賴，這樣極大的提高了開發(fā)效率，系統(tǒng)分工也更加明確。<br /> <br /> 前后端分離后，需要考慮哪些事情<br /> 分離后的前端，不再是一個(gè)簡單的HTML文件，已經(jīng)是一個(gè)獨(dú)立的應(yīng)用系統(tǒng)。除了要考慮頁面的數(shù)據(jù)渲染展示，還要用工程化的思想來考慮前端的架構(gòu)，前后端的交互和數(shù)據(jù)安全等事情。<br /> <br /> 架構(gòu)<br /> **前端應(yīng)用部署在Nodejs、Nginx或者Nodejs和Nginx組合的服務(wù)器上，通過反向代理轉(zhuǎn)發(fā)頁面請求到后端服務(wù)器，相當(dāng)于在傳統(tǒng)的流程中加了Nodejs這一層。**當(dāng)然，也可以用Nodejs服務(wù)器來承擔(dān)一部分負(fù)載均衡的工作，業(yè)務(wù)邏輯也可以放在Nodejs這一層來處理，例如：通過判斷請求是來自 PC 還是 APP ，將請求發(fā)到不同的后端服務(wù)器<br /> <br /> Nodejs的架構(gòu)中，分層如下<br /> <br /> 讓我們來回想一下軟件開發(fā)流程中的幾個(gè)關(guān)鍵環(huán)節(jié)：<br /> <br /> （1）產(chǎn)品經(jīng)理提需求，畫原型；<br /> <br /> （2）UI設(shè)計(jì)師根據(jù)原型出設(shè)計(jì)圖；<br /> <br /> （3）測試團(tuán)隊(duì)根據(jù)產(chǎn)品原型編寫測試用例，制定測試計(jì)劃；<br /> <br /> （4）架構(gòu)師根據(jù)原型編寫API文檔；<br /> <br /> （5）前后端工程師基于API文檔完成業(yè)務(wù)開發(fā)；<br /> <br /> （6）測試、改BUG、發(fā)布。<br /> <br /> API文檔環(huán)節(jié)直接關(guān)系到了前端和后端兩個(gè)開發(fā)團(tuán)隊(duì)，也是整個(gè)軟件開發(fā)流程中耗時(shí)最大的環(huán)節(jié)。<br /> <br /> RESTful接口交互<br /> 前后端分離之后，更多的是采用 RESTful 風(fēng)格的接口與后端進(jìn)行數(shù)據(jù)交互。（如果你們的項(xiàng)目還在使用靜態(tài)的API文檔，比如word文檔，那你們必定經(jīng)歷著巨大的痛苦）<br /> <br /> REST是“呈現(xiàn)狀態(tài)轉(zhuǎn)移（REpresentational State Transfer）”的縮寫，一種API的架構(gòu)風(fēng)格，在客戶端和服務(wù)端之間通過呈現(xiàn)狀態(tài)的轉(zhuǎn)移來驅(qū)動應(yīng)用狀態(tài)的演進(jìn)。<br /> <br /> 在 REST 樣式的 Web 服務(wù)中，每個(gè)資源都有一個(gè)地址。資源本身都是方法調(diào)用的目標(biāo)，方法列表對所有資源都是一樣的。這些方法都是標(biāo)準(zhǔn)方法，包括 HTTP GET、POST、PUT、DELETE，還可能包括 HEADER 和 OPTIONS。<br /> RESTful的API設(shè)計(jì)，使得后端通過接口向前端傳遞數(shù)據(jù)，數(shù)據(jù)的格式通常是JSON這種通用的格式。對前端來說，只要后端返回過來的是RESTful的數(shù)據(jù)就行，不管后端是用Java寫，還是用python或PHP，拜托對后端的依賴，做到前端系統(tǒng)的獨(dú)立。<br /> <br /> REST服務(wù)的調(diào)試：Postman 和 Insomnia<br /> <br /> 使用模板引擎<br /> 前后端分離之后，前端工程師需要將通過API獲取的數(shù)據(jù)呈現(xiàn)到頁面上，雖然也可以通過jQuery對頁面一個(gè)一個(gè)賦值，但是這種效率太低了，或者也可通過在JavaScript中拼接HTML，但是這種方式太難維護(hù)HTML代碼了，也很難閱讀。因此最好的方式就是使用模板引擎。<br /> <br /> 前端的模板引擎跟后端模板引擎很相似，比如JSP或cshtml（razor），他們的語法都非常相似，他們所實(shí)現(xiàn)的功能也幾乎一樣：將數(shù)據(jù)綁定到HTML模板。VueJs和react都可以充當(dāng)這樣的模板引擎。我們最終沒有選用react而是選用了VueJs的原因只有一個(gè)，那就是VueJs是真正的響應(yīng)式，而react改變model之后需要手工調(diào)用setState才會更新UI，這是完全無法忍受的。<br /> <br /> 因?yàn)檫@個(gè)原因，我們只能選擇VueJS作為模板引擎。<br /> <br /> 工程化構(gòu)建<br /> Nodejs不止可以用來做前端服務(wù)器，在開發(fā)階段，它也能發(fā)揮很大的作用。<br /> 前端生態(tài)的發(fā)展，是圍繞著Nodejs進(jìn)行的。用npm來管理項(xiàng)目依賴，可以很好的維護(hù)和運(yùn)行在Nodejs環(huán)境上。<br /> 打包工具grunt、gulp、webpack和rollup等，都是運(yùn)行在nodejs上，再結(jié)合語法編譯、打包部署等插件，將應(yīng)用輸入成一個(gè)完整的應(yīng)用。<br /> 如果你使用了Angular、React或Vue框架，或者你使用瀏覽器暫時(shí)還不兼容的ES6語法，還需要在應(yīng)用打包前用babel將語法編譯成瀏覽器可識別的ES5的語法。<br /> <br /> SPA<br /> SPA是單頁Web應(yīng)用（single page web application，SPA）的簡寫，就是只有一張Web頁面的應(yīng)用，是加載單個(gè)HTML 頁面并在用戶與應(yīng)用程序交互時(shí)動態(tài)更新該頁面的Web應(yīng)用程序。<br /> <br /> 像Angular、React或Vue就是為了SPA而設(shè)計(jì)的，結(jié)合前端路由庫（react-router、vue-router）和狀態(tài)熱存儲（redux、vuex）等，可以開發(fā)出一個(gè)媲美Native APP的Web APP，用戶體驗(yàn)得到了很大的提升。<br /> <br /> 當(dāng)然，SPA也不是完美的，也不是適合所有的web應(yīng)用，需要結(jié)合項(xiàng)目和場景來選擇。<br /> <br /> SPA有如下缺點(diǎn)：<br /> <br /> 初次加載耗時(shí)增加。可以通過代碼拆分、懶加載來提升性能，減少初次加載耗時(shí)。<br /> <br /> SEO不友好，現(xiàn)在可以通過 Prerender 或 Server render 來解決一部分。<br /> <br /> 頁面的前進(jìn)和后端需要開發(fā)者自己寫，不過現(xiàn)在一些路由庫已經(jīng)幫助我們基本解決了。<br /> <br /> 對開發(fā)者要求高，由于做SPA需要了解一整套技術(shù)棧，所以，要考慮后期是否有合適的人選進(jìn)行維護(hù)。<br /> <br /> mock（模擬數(shù)據(jù)）<br /> 前后端分離框架中的API mock思路<br /> 想要實(shí)現(xiàn)真正的前后端分離，那就必須得用好API mock（模擬數(shù)據(jù)）。使用mock數(shù)據(jù)的好處有兩個(gè)：<br /> <br /> 前端開發(fā)人員可以基于API文檔生成mock數(shù)據(jù)，在后端開發(fā)人員將API發(fā)布出來之前就可以完成整個(gè)業(yè)務(wù)流程的開發(fā)；<br /> <br /> 使用mock數(shù)據(jù)能夠更低成本、更快速地，通過直接修改mock數(shù)據(jù)的方式，調(diào)試頁面樣式、調(diào)試頁面功能。<br /> <br /> 全局的mock開關(guān)<br /> 為什么要設(shè)置這樣一個(gè)全局的mock開關(guān)呢？主要基于以下兩點(diǎn)考慮：<br /> <br /> 設(shè)置全局的mock開關(guān)之后就不再需要針對每一個(gè)頁面設(shè)置mock開關(guān)，更容易維護(hù)，避免項(xiàng)目中有多個(gè)mock開關(guān)而難以統(tǒng)一開關(guān)狀態(tài)；<br /> <br /> 如果發(fā)布時(shí)忘記將mock開關(guān)給關(guān)掉，那么發(fā)布之后一運(yùn)行發(fā)布者就會發(fā)現(xiàn)mock開關(guān)忘了關(guān)，然后可以快速修復(fù)之后再重新發(fā)布，從而避免不小心將正式服更新為mock數(shù)據(jù)源。<br /> <br /> 正是由于以上兩點(diǎn)考慮，我們的全局mock開關(guān)可以幫助程序開發(fā)者和發(fā)布者更不容易犯錯(cuò)。<br /> <br /> 解決請求問題<br /> 前后端分離后，我們只需要Server端告訴我們Api URL即可，那么這會產(chǎn)生一個(gè)問題：Ajax跨域。這里就不能使用一般的跨域解決方法去解決，比如jsonp,iframe信使等等，因?yàn)槲覀冞€有POST請求。<br /> <br /> 于是Http Proxy類工具就有用了，比如我就會在BrowserSync加入中間件判斷每一個(gè)請求，如果是/api前綴就會代理到API Server端，API Server端收到數(shù)據(jù)后再返回給BrowserSync，BrowserSync再返回給瀏覽器端。這樣就解決跨域請求的問題<br /> <br /> 生產(chǎn)環(huán)境有兩種部署，一種是放到后臺項(xiàng)目里，這就沒啥說的，另外一種就是前后端分開部署，那就在前端WebServer處理端寫點(diǎn)轉(zhuǎn)發(fā)規(guī)則就好，如Nginx，Apache都支持。<br /> <br /> 靜態(tài)資源路徑問題<br /> 如果你的項(xiàng)目有上傳資源功能，那自然就會產(chǎn)生用戶資源，那前后端分離后，如何來處理這個(gè)問題呢？得先看模式。<br /> <br /> 資源與后臺項(xiàng)目放一起，后臺處理完后需要返回前臺一個(gè)相對路徑，如果資源時(shí)一臺單獨(dú)的服務(wù)器，那就需要返回資源的絕對URL即可。<br /> <br /> 會話<br /> Web項(xiàng)目最頭疼的就是無狀態(tài)導(dǎo)致會話問題，傳統(tǒng)的Web項(xiàng)目都使用Session/Cookie，但在前后端分離，集群部署模式下這Session明顯缺陷太多。token方式已經(jīng)是當(dāng)前Web端解決會話的主流，并且有很多開源好用的token生成管理程序，基本上拿來就能用。<br /> <br /> 做網(wǎng)站公眾平臺每天為您分享原創(chuàng)Web開發(fā)資訊，開發(fā)經(jīng)驗(yàn)，為您的技能充電。期待您的關(guān)注與分享，同時(shí)歡迎您留言，讓我們每天進(jìn)步一點(diǎn)點(diǎn)！<br />