為什么要前后端分離
前后端分離本質(zhì)上是工作職責(zé)的細(xì)化。這兩年前后端分離的呼聲越發(fā)高漲急前，最重要的原因在于后端工程師不能簡(jiǎn)單的完成前端方面的工作械荷。前端這段時(shí)間以來新的技術(shù)層出不窮，這種情況下后端無法簡(jiǎn)單的掌握前端技術(shù)，即使對(duì)前端來說也有一定的負(fù)擔(dān)朗徊。
前端的門檻越來越高，一個(gè)人無法將所有的事情都做完偎漫，也是前后端分離的一方面因素爷恳。
典型的業(yè)務(wù)場(chǎng)景
前后端分離其實(shí)也并非萬能良藥，對(duì)應(yīng)不同的業(yè)務(wù)場(chǎng)景情況會(huì)有所不同象踊。同樣的應(yīng)用場(chǎng)景也有所不同温亲，前端傳統(tǒng)的應(yīng)用場(chǎng)景有PC端、移動(dòng)端杯矩，另外還App hybrid栈虚、小程序等。針對(duì)不同的應(yīng)用場(chǎng)景所使用的技術(shù)都會(huì)有所不同史隆，應(yīng)用場(chǎng)景眾多讓架構(gòu)復(fù)雜度變的更高魂务。
技術(shù)挑戰(zhàn)
我們?cè)谇岸朔矫嬗龅搅撕芏嗟募夹g(shù)挑戰(zhàn)，其中最重要的就是在大流量下要求高可用逆害。對(duì)于訪問量較小的網(wǎng)站头镊，測(cè)試量并不是很大，只有在極少數(shù)情況下用戶才能感知到BUG魄幕。但是大流量下感知人數(shù)會(huì)明顯增多相艇，所遇到的各方面問題也會(huì)增多，比如網(wǎng)絡(luò)纯陨、接口緩慢的問題坛芽。針對(duì)大流量前端可以采用CDN方式抗住，這時(shí)后端的壓力會(huì)比較大翼抠。當(dāng)后端扛不住的時(shí)候咙轩，就需要前端來分擔(dān)一部分壓力，不能讓用戶感知到網(wǎng)頁出現(xiàn)的問題阴颖，這種情況下高可用的要求會(huì)非常的高活喊。
第二點(diǎn)是所有的前端工程師都非常討厭的問題，瀏覽器的兼容性要求高量愧。相信沒有人會(huì)喜歡兼容IE7的需求钾菊，但是用戶量多的情況下總有用會(huì)使用IE7的，為了避免用戶投訴這一需求就必須得到滿足偎肃。
前后端常用技術(shù)利弊
技術(shù)方案
目前使用的技術(shù)方案有四種：前端模板（Ajax + 字符串模板）煞烫、MVVM（Vue、React）累颂、Node模板（Express + ejs）滞详、SSR（Node + Vue SSR）。這其中最古老的方案就是Ajax + 字符串模板，它本質(zhì)上是拼接字符串料饥。
-
瀏覽器兼容
image
無論是服務(wù)器渲染還是平常的渲染方式都支持IE6+蒲犬，使用SSR或Node做渲染在瀏覽器兼容方面則會(huì)比較弱∠』穑基于現(xiàn)代MVVM框架的技術(shù)方案暖哨，同樣也處于劣勢(shì)，在瀏覽器兼容要求較高的場(chǎng)合中凰狞，無法使用篇裁。
- SEO支持
對(duì)于SEO有要求的網(wǎng)頁來說，使用web模板和Vue方案赡若，不太合適达布。相對(duì)來說web模板要好一點(diǎn)，可以在頁面未渲染之前添加一些介紹之類逾冬。Node和SSR在SEO方面問題不大黍聂，它們都是服務(wù)端渲染，首屏都包含足夠多的數(shù)據(jù)身腻。
- 首屏渲染耗時(shí)
現(xiàn)在的各種技術(shù)方案中對(duì)于首屏渲染耗時(shí)产还，顯然使用Node是最快的。畢竟它是服務(wù)端渲染嘀趟，數(shù)據(jù)是由Node服務(wù)端向服務(wù)提供方獲取的脐区。SSR渲染的花費(fèi)時(shí)間相對(duì)于Node會(huì)多30%-50%。Web模板和Vue都是讀取數(shù)據(jù)然后加載她按，其中Vue的渲染耗時(shí)會(huì)更久一些牛隅。總體來看在首屏渲染耗時(shí)方面MVVM框架是最慢的酌泰。
- 異步接口速度
在首屏加載完成后媒佣，很多頁面都會(huì)有懶加載，需要向服務(wù)端請(qǐng)求相應(yīng)的數(shù)據(jù)接口陵刹。這方面MVVM框架和web模板是直連后端的默伍，而Node和SSR的方案都使用Nodejs做中間層轉(zhuǎn)發(fā)一次，消耗掉一部分的網(wǎng)絡(luò)連接衰琐，多出來的是Node服務(wù)器到服務(wù)提供方的服務(wù)巡验。
- 高可用
Web模板毫無疑問在高可用方面是做的最好的，只要后臺(tái)服務(wù)提供方?jīng)]有掛碘耳，一般來說Web模板不會(huì)出太多問題。MVVM情況會(huì)復(fù)雜一些框弛，在瀏覽器兼容上要求更高辛辨，測(cè)驗(yàn)量也會(huì)更多，但總歸有些地方會(huì)測(cè)試不到。
Node作為中間平臺(tái)斗搞，不僅要關(guān)心前端CDN還要注意Node服務(wù)器會(huì)不會(huì)出現(xiàn)問題指攒，這樣每多一個(gè)環(huán)節(jié)在高可用方面的就會(huì)差上一些。而SSR不僅要在Node上有高可用的要求僻焚，如果還引入了前后端代碼同構(gòu)允悦，同構(gòu)代碼就有可能會(huì)在Node上出現(xiàn)各種問題÷瞧。基于這種情況我們認(rèn)為SSR在高可用方面是最差的隙弛。
技術(shù)門檻
技術(shù)的選擇上首先要考慮是否合適當(dāng)前團(tuán)隊(duì)，不同的團(tuán)隊(duì)情況都會(huì)有所不同狞山。技術(shù)門檻方面就拿校招來說一般在web模板上都不會(huì)有太大問題全闷，Vue這樣的MVVM框架可能會(huì)了解一種，但是比較熟悉的就相對(duì)少一些萍启。Web模板和Vue至少還是在前端方面总珠，而Node情況就有些不同，它的知識(shí)點(diǎn)對(duì)前端來說復(fù)雜了很多勘纯。SSR情況則更糟糕局服，不僅僅需要知道Node方面的知識(shí)，還需要知道同樣一套代碼在Node上如何運(yùn)行驳遵，以及SSR框架的運(yùn)行情況淫奔，這樣的話門檻就會(huì)更高。
前后端分離度
使用web模板或MVVM框架至少還需要和運(yùn)維等人員配合找臺(tái)服務(wù)器放置頁面超埋，多少還會(huì)和后端方面有些聯(lián)系搏讶。而使用Node中間件則可以獨(dú)立解決所有的問題。
第一個(gè)問題就是你的項(xiàng)目是否需要SEO霍殴。如果需要那么Node.js就是不二選擇媒惕，但是也要面對(duì)Node.js的風(fēng)險(xiǎn)，目前Node.js極度缺少企業(yè)級(jí)工具来庭，錯(cuò)誤調(diào)試?yán)щy妒蔚，資料也少于主流語言。
第二個(gè)問題是項(xiàng)目是否需要兼容IE月弛，目前很多的前端工程師都喜歡使用前端框架肴盏。但是如果當(dāng)前項(xiàng)目需要兼容IE，那么就可以和這些框架說再見了帽衙。
第三個(gè)問題就是是否有足夠多的前端工程師菜皂。前后端分離的越徹底，前端工作量越多厉萝。如果沒有足夠的前端工程師恍飘，就會(huì)面臨各種各樣的招聘風(fēng)險(xiǎn)榨崩，即很難招到有經(jīng)驗(yàn)的前端工程師，現(xiàn)階段只能靠加班章母。
漸進(jìn)式前后端分離
在前后端分離方面整體上都是轉(zhuǎn)向Node.js中間件母蛛，我們有一個(gè)人數(shù)不多的架構(gòu)團(tuán)隊(duì)，主要負(fù)責(zé)生產(chǎn)各種工具和中間件為Node.js服務(wù)乳怎。
對(duì)于瀏覽器兼容要求彩郊、可用性要求、頁面性能要求都極高的頁面不使用前后端分離配合少量web模板蚪缀。
對(duì)于瀏覽器兼容要求較高的活動(dòng)展示頁秫逝，逐漸從web模板過渡為Node模板。 核心應(yīng)用型web頁椿胯，可用性要求占主導(dǎo)的頁面筷登，過渡為Node + Vue.js方案。某些以前用Vue編寫的頁面現(xiàn)在要想兼容SEO且對(duì)性能要求高哩盲，可以漸進(jìn)過渡到SSR方案前方。
前后端分離在團(tuán)隊(duì)推進(jìn)中，根據(jù)團(tuán)隊(duì)實(shí)際情況廉油，也應(yīng)該是漸進(jìn)的惠险。架構(gòu)師要嚴(yán)格評(píng)估風(fēng)險(xiǎn)邊界，保持業(yè)務(wù)的穩(wěn)定抒线。業(yè)務(wù)開發(fā)中班巩，多選擇新業(yè)務(wù)推進(jìn)高級(jí)分離方案。對(duì)于老業(yè)務(wù)改造嘶炭，應(yīng)該循序漸進(jìn)抱慌，選擇新需求。
前后端分離的優(yōu)勢(shì)
前端靜態(tài)化
前端有且僅有靜態(tài)內(nèi)容,再明確些,只有HTML/CSS/js. 其內(nèi)容來自于完全靜態(tài)的資源而不需要任何后臺(tái)技術(shù)進(jìn)行動(dòng)態(tài)化組裝.前端內(nèi)容的運(yùn)行環(huán)境和引擎完全基于瀏覽器本身后端數(shù)據(jù)化
后端可以用任何語言,技術(shù)和平臺(tái)實(shí)現(xiàn),但它們必須遵循一個(gè)原則:只提供數(shù)據(jù),不提供任何和界面表現(xiàn)有關(guān)的內(nèi)容.換言之,他們提供的數(shù)據(jù)可以用于任何其他客戶端(如本地化程序,移動(dòng)端程序)平臺(tái)無關(guān)化
前端3大技術(shù)本身就是平臺(tái)無關(guān)的,而后臺(tái)連接部分的本質(zhì)是實(shí)現(xiàn)合適的RESTful接口和交互Json數(shù)據(jù),就這2者而言,任何技術(shù)和平臺(tái)都可以實(shí)現(xiàn)構(gòu)架分離化
前端架構(gòu)完全基于HTML/CSS的發(fā)展和JS框架的演變,與我們耳熟能詳?shù)暮笈_(tái)語言(如C#, Java, NodeJs等)完全無關(guān). 由于前臺(tái)是純靜態(tài)內(nèi)容,大型構(gòu)架方面可以考慮向CDN方向發(fā)展.
后端構(gòu)架幾乎可以基于任何語言和平臺(tái)的任何解決方案,大型構(gòu)架方面, RESTful Api可以考慮負(fù)載均衡;而數(shù)據(jù),業(yè)務(wù)實(shí)現(xiàn)等可以考慮數(shù)據(jù)庫優(yōu)化和分布式,但總而言之,前后端的分離也實(shí)現(xiàn)了前后端構(gòu)架的分離
前后端流量大幅減少
我們知道,前后端流量的大頭是HTML/JS/IMG資源,而數(shù)據(jù)僅僅是小頭,資源占到100K以上的頁面不算大,但數(shù)據(jù)充其量10K左右,比如一個(gè)1萬條記錄的數(shù)據(jù)經(jīng)過壓縮也僅僅在100K左右,而一個(gè)稍大的JS庫或圖片就不止這些.流量的減少在于”前端靜態(tài)化”這個(gè)規(guī)則,在第一次獲取以后靜態(tài)資源會(huì)被瀏覽器緩存,即使瀏覽器繼續(xù)輪詢,服務(wù)端也會(huì)返回一個(gè)非常小Not Modified響應(yīng),流量幾乎可以忽略不計(jì).舉例說明,在一個(gè)頁面為100K,數(shù)據(jù)為10K的頁面中,100次請(qǐng)求的流量是100K+10X100 = 1.1M. 顯而易見,其流量是大幅低于每次獲取完整HTML的情況的表現(xiàn)性能的提高
有人質(zhì)疑這種模式的頁面性能問題,其實(shí)情況沒有那么悲觀: 第一次獲取的確會(huì)有些許損失,但我認(rèn)為,損失微乎其微,一個(gè)HTML頁面的加載,同時(shí)加載10多個(gè)幾十K的JS, Image的情況非常常見,再多1-2個(gè)10K的Json也并非沉重負(fù)擔(dān).但后續(xù)使用這個(gè)頁面,性能優(yōu)勢(shì)就完全體現(xiàn)了,頁面的絕大部分內(nèi)容都是本地緩存直接加載,遠(yuǎn)程獲取的僅僅是1-2個(gè)10K的內(nèi)容,其加載時(shí)間百毫秒內(nèi),這和本地頁面幾無區(qū)別,其前端加載和響應(yīng)速度得到非常大的提高是顯而易見的.前后端平臺(tái)無關(guān)和技術(shù)無關(guān)
前端是純HTML技術(shù),前端人員只需要記事本就可以開發(fā)并非一句”戲言”,而后端能夠?qū)崿F(xiàn)RESTful的框架和平臺(tái)比比皆是, 完全可以選擇更適合團(tuán)隊(duì),人員和公司的技術(shù)路線而不在糾結(jié)于平臺(tái)和技術(shù)的選擇安全性方面的集中優(yōu)化
前端靜態(tài)化以后,前端頁面攻擊幾無可能,一些注入式攻擊在分離模式下被很好的規(guī)避; 而后端安全問題集中化了,僅僅只處理一個(gè)RESEful接口的安全考慮,安全架設(shè)和集中優(yōu)化變得更明確和便利開發(fā)的分離和構(gòu)架的分離
也許很多團(tuán)隊(duì)還是1個(gè)開發(fā)人員全包前后端的模式,但前端的要求越來越高,前后端人員的需求分化日益明顯,一旦系統(tǒng)上級(jí)別上檔次,其分離的需求必將出現(xiàn).
前后端人員的完全分離可以使得他們?cè)诟髯灶I(lǐng)域進(jìn)一步求深求專,成為更加專業(yè)的高手;另外,前后端的構(gòu)架也可以分開考慮和架設(shè),前端構(gòu)架就能集中考慮性能和優(yōu)化,而業(yè)務(wù),安全和存儲(chǔ)等問題就能集中到后端考慮.
