本文系轉(zhuǎn)載乡革，原作者，普元摊腋，敖顯奇
轉(zhuǎn)載本文需保留此處版權(quán)聲明：本文版權(quán)屬于EAII企業(yè)架構(gòu)創(chuàng)新研究院（微信號：eaworld）沸版，違者必究。
一兴蒸、被誤解的前后端分離
在Web應(yīng)用開發(fā)過程中视粮，業(yè)界對前后端的分界線似乎一直都沒有確定的概念，不過大多數(shù)人以瀏覽器作為前后端的分界線橙凳。將瀏覽器中為用戶進(jìn)行頁面展示的部分稱為前端蕾殴，而將運(yùn)行于服務(wù)器笑撞，為前端提供業(yè)務(wù)邏輯和數(shù)據(jù)準(zhǔn)備的所有代碼統(tǒng)稱為后端。
雖然前后端分離在數(shù)年前就已經(jīng)開始受到關(guān)注钓觉，但很多人對它卻是只聞其聲茴肥，未見其形，所以對它產(chǎn)生了一些誤解荡灾，誤以為前后段分離只是一種Web應(yīng)用的開發(fā)模式瓤狐，只要在Web應(yīng)用的開發(fā)期進(jìn)行了前后端開發(fā)工作的分工就是前后端分離。
其實(shí)并非如此卧晓，
準(zhǔn)確的說芬首，前后端分離并不只是開發(fā)模式，而是Web應(yīng)用的一種架構(gòu)模式
逼裆。在開發(fā)期郁稍，前后端工程師可以通過約定好交互接口，實(shí)現(xiàn)并行開發(fā)胜宇；在運(yùn)行期耀怜，前后端分離模式需要對Web應(yīng)用進(jìn)行分離部署，前后端之間使用HTTP請求進(jìn)行交互桐愉。然而作為應(yīng)用的架構(gòu)模式财破，前后端分離并不是通過這樣一句話就能一概而談的，我們可以從交互形式从诲、代碼組織方式左痢、開發(fā)模式三個(gè)方面對前后端分離進(jìn)行認(rèn)識。
1系洛、交互形式
在前后端分離架構(gòu)中俊性，后端只需要負(fù)責(zé)按照約定的數(shù)據(jù)格式向前端提供可調(diào)用的API服務(wù)即可。前后端之間通過HTTP請求進(jìn)行交互描扯，前端獲取到數(shù)據(jù)后定页，進(jìn)行頁面的裝配和渲染。
2绽诚、代碼組織方式
在傳統(tǒng)架構(gòu)模式中典徊，前后端代碼存放于同一個(gè)代碼庫中，甚至是同一工程目錄下恩够。頁面中還夾雜著后端代碼卒落。前后端工程師進(jìn)行開發(fā)時(shí)，都必須把整個(gè)項(xiàng)目導(dǎo)入到開發(fā)工具中玫鸟。
而前后端分離模式在代碼組織形式上有以下兩種：
半分離
前后端共用一個(gè)代碼庫导绷，但是代碼分別存放在兩個(gè)工程中。后端不關(guān)心或很少關(guān)心前端元素的輸出情況屎飘，前端不能獨(dú)立進(jìn)行開發(fā)和測試妥曲，項(xiàng)目中缺乏前后端交互的測試用例贾费。
分離
前后端代碼庫分離，前端代碼中有可以進(jìn)行Mock測試（通過構(gòu)造虛擬測試對象以簡化測試環(huán)境的方法）的偽后端檐盟，能支持前端的獨(dú)立開發(fā)和測試褂萧。而后端代碼中除了功能實(shí)現(xiàn)外，還有著詳細(xì)的測試用例葵萎，以保證API的可用性导犹，降低集成風(fēng)險(xiǎn)。
3羡忘、開發(fā)模式
傳統(tǒng)的MVC架構(gòu)開發(fā)谎痢，沒有進(jìn)行前后端分離，前端工程師負(fù)責(zé)編寫HTML卷雕，完成前端頁面設(shè)計(jì)节猿，然后給后端工程師員套界面，使用模板技術(shù)將前端代碼轉(zhuǎn)換成JSP頁面漫雕，同時(shí)內(nèi)嵌java代碼滨嘱。應(yīng)用運(yùn)行期，將全部代碼進(jìn)行打包浸间，部署到同一服務(wù)器上太雨，或者進(jìn)行簡單的動靜態(tài)分離部署。
此時(shí)魁蒜，應(yīng)用的開發(fā)流程如下圖所示囊扳。
在前后端分離架構(gòu)中，前端工程師只需要編寫HTML兜看、js宪拥、CSS等前端資源，然后通過HTTP請求調(diào)用后端提供的服務(wù)即可铣减。除了開發(fā)期的分離，在運(yùn)行期前后端資源也會進(jìn)行分離部署脚作。
前后端分離之后葫哗，開發(fā)流程將如下圖所示。
通過上面的兩幅流程圖球涛，不難發(fā)現(xiàn)劣针，在開發(fā)模式上，前后段分離不僅僅只是工程師的分工開發(fā)亿扁，更重要的意義在于實(shí)現(xiàn)了前后端的并行開發(fā)捺典，和簡化了開發(fā)流程。
二从祝、為什么要“離”：4個(gè)好處
重新認(rèn)識前后端分離之后襟己，想必大家心里都會有疑問引谜，前后端分離模式與之前的Web應(yīng)用架構(gòu)相比可謂是大相徑庭，我們?yōu)槭裁匆M(jìn)行前后端分離呢擎浴？正如莎士比亞在《哈姆雷特》中的經(jīng)典名句一樣员咽，分還是不分，這是個(gè)問題贮预。
從目前應(yīng)用軟件的發(fā)展趨勢來看贝室，一方面，用戶越來越注重軟件的體驗(yàn)感仿吞，隨著互聯(lián)網(wǎng)的蓬勃發(fā)展滑频，應(yīng)用開始走向多終端化；另一方面唤冈，大型應(yīng)用的架構(gòu)模式正紛紛向著云化峡迷、微服務(wù)化發(fā)展。
雖然過去的應(yīng)用架構(gòu)暫時(shí)還能支撐起當(dāng)下應(yīng)用的開發(fā)务傲，但是各種弊端已經(jīng)開始浮出水面凉当，幾年前能帶來開發(fā)便捷優(yōu)勢的前后端代碼混合模式，在當(dāng)下已經(jīng)成為了拖慢我們前進(jìn)步伐的泥沼售葡，讓我們屢屢吃痛看杭。我們之所以開始嘗試前后端分離，是為了能在未來獲得更好的發(fā)展挟伙，期望通過前后端分離架構(gòu)楼雹，來為我們帶來以下4個(gè)方面的提升。
為孵化優(yōu)質(zhì)產(chǎn)品打造精益團(tuán)隊(duì)
正如康威定律所述尖阔，產(chǎn)品是組織溝通結(jié)構(gòu)的縮影贮缅，軟件開發(fā)團(tuán)隊(duì)想要孵化出優(yōu)質(zhì)的產(chǎn)品，必須先打造一個(gè)精益的開發(fā)團(tuán)隊(duì)介却。開發(fā)團(tuán)隊(duì)的組織劃分是如何影響產(chǎn)品的孵化呢谴供，我們通過下面的示例來進(jìn)行說明。
如果開發(fā)團(tuán)隊(duì)是按照業(yè)務(wù)邊界進(jìn)行劃分的齿坷，開發(fā)出來的產(chǎn)品將可能會是微服務(wù)的架構(gòu)桂肌。
如果開發(fā)團(tuán)隊(duì)分為前端團(tuán)隊(duì)、后臺服務(wù)團(tuán)隊(duì)和DBA團(tuán)隊(duì)永淌，產(chǎn)品將會成長為下面的架構(gòu)崎场。
應(yīng)用不斷迭代，功能日趨完善遂蛀，開發(fā)團(tuán)隊(duì)也隨之壯大谭跨。雖然現(xiàn)在有些人比較推崇全棧工程師，一位全棧工程師就能支持前后端的所有開發(fā)。但是試想一下螃宙，如果在開發(fā)團(tuán)隊(duì)中前后端開發(fā)分隔不清蛮瞄，職責(zé)邊界模糊不明，代碼均由相同的工程師完成污呼，長此以往前后端代碼的耦合程度可想而知裕坊。
通過將開發(fā)團(tuán)隊(duì)前后端分離化，讓前后端工程師只需要專注于前端或后端的開發(fā)工作燕酷，使得前后端工程師分別自治籍凝，培養(yǎng)其獨(dú)特的技術(shù)特性，然后構(gòu)建出一個(gè)全棧式的精益開發(fā)團(tuán)隊(duì)苗缩。這樣的開發(fā)團(tuán)隊(duì)能夠快速應(yīng)對需求的變更以及市場的復(fù)雜多變饵蒂，打造出架構(gòu)清晰、前后端并重的優(yōu)質(zhì)產(chǎn)品酱讶。
提升開發(fā)效率
傳統(tǒng)開發(fā)模式中退盯，前后端開發(fā)強(qiáng)依賴。需要前端工程師先完成靜態(tài)頁面的Demo泻肯，后端工程師才能將頁面Demo翻譯成VM模板渊迁，如果前端頁面出現(xiàn)變動，又會需要前后端工程師再走一次開發(fā)流程灶挟，如此一來開發(fā)效率將會變得很低琉朽。
前后端分離以后，可以實(shí)現(xiàn)前后端代碼的解耦稚铣，只要前后端溝通約定好應(yīng)用所需接口以及接口參數(shù)箱叁，便可以開始并行開發(fā)，無需等待對方的開發(fā)工作結(jié)束惕医。與此同時(shí)耕漱，即使需求發(fā)生變更，只要接口與數(shù)據(jù)格式不變抬伺，后端開發(fā)人員就不需要修改代碼螟够，只要前端進(jìn)行變動即可。如此一來整個(gè)應(yīng)用的開發(fā)效率必然會有質(zhì)的提升峡钓。
完美應(yīng)對復(fù)雜多變的前端需求
Web應(yīng)用的用戶體驗(yàn)關(guān)注度與日俱增齐鲤，使得應(yīng)用的前端界面需要有華麗酷炫的外觀，簡單易用的操作椒楣，變化多樣的界面設(shè)計(jì)和個(gè)性化的自定義展示。這使得前端開始變重牡肉，邏輯復(fù)雜程度加大捧灰，渲染效果多樣化加劇。
移動終端的大范圍普及，讓應(yīng)用向著多終端化發(fā)展毛俏，這就要求前端頁面需要對不同終端的顯示都能進(jìn)行配適炭庙。
傳統(tǒng)開發(fā)模式中，前后端工程師開發(fā)職責(zé)不明確煌寇，面對復(fù)雜多變的前端需求焕蹄，開發(fā)團(tuán)隊(duì)勢必會變得捉襟見肘、不堪重負(fù)阀溶。
如果開發(fā)團(tuán)隊(duì)能完成前后端分離的轉(zhuǎn)型腻脏，打造優(yōu)秀的前后端團(tuán)隊(duì)，開發(fā)獨(dú)立化银锻，讓開發(fā)人員做到專注專精永品，開發(fā)能力必然會有所提升，能夠完美應(yīng)對各種復(fù)雜多變的前端需求击纬。
增強(qiáng)代碼可維護(hù)性
前后端分離后鼎姐，應(yīng)用的代碼不再是前后端混合，只有在運(yùn)行期才會有調(diào)用依賴關(guān)系更振。應(yīng)用代碼將會變得整潔清晰炕桨，不論是代碼閱讀還是代碼維護(hù)都會比以前輕松。
三肯腕、我要不要“離”：4種場景
然而任何一項(xiàng)技術(shù)都不是銀彈献宫，前后端分離也是如此。雖然前后端分離架構(gòu)能帶來眾多優(yōu)勢乎芳，但終究得建立在開發(fā)團(tuán)隊(duì)適合的基礎(chǔ)之上遵蚜。我們暫且以前端頁面的渲染效果與邏輯復(fù)雜程度把Web應(yīng)用大致分為輕前端、重前端、前后均衡三種類型，然后加上現(xiàn)在熱門的微服務(wù)架構(gòu)應(yīng)用每庆，一起探討一下什么樣的Web應(yīng)用適合進(jìn)行前后端分離艰管。
輕前端
頁面布局簡單，顏色蹋盆、字體類型較少
對前端界面的渲染效果沒有高要求，無動畫效果
只有少量、簡單的業(yè)務(wù)邏輯
只需要在不同終端上布局能適應(yīng)
對于這樣對前端渲染要求不高友扰，業(yè)務(wù)邏輯簡單的輕前端應(yīng)用來說，因?yàn)樯婕暗降那岸思夹g(shù)并不復(fù)雜庶柿，所以沒必要追求前后端分離村怪。將前后端代碼放到一起，反而更方便進(jìn)行開發(fā)浮庐，但是在開發(fā)過程中需要做到關(guān)注點(diǎn)分離（Separate
Concern）甚负。
重前端
頁面布局復(fù)雜，使用了多種顏色和字體
需要有較高的頁面渲染效果，有大量動畫
前端頁面中包含有復(fù)雜業(yè)務(wù)邏輯
需要在不同終端和瀏覽器上保證布局適應(yīng)和渲染效果
對于重前端應(yīng)用梭域，建議采用前后端分離架構(gòu)斑举，如果開發(fā)團(tuán)隊(duì)中前端工程師不足，需要盡早完善前端團(tuán)隊(duì)的建設(shè)病涨，確保前后端并重富玷。
前后均衡
頁面布局適中，使用的顏色和字體種類不多
頁面中使用了少許動畫效果
業(yè)務(wù)邏輯較為簡單既穆，可下沉到后端實(shí)現(xiàn)
只需要在不同終端上布局能適應(yīng)
對于前后端均衡應(yīng)用赎懦，建議綜合團(tuán)隊(duì)的人員結(jié)構(gòu)和未來發(fā)展方向進(jìn)行考慮。如果在團(tuán)隊(duì)中前端工程師的占比不高循衰，后續(xù)也沒有繼續(xù)發(fā)展前端的計(jì)劃铲敛，那么就不建議過于追求前后端分離。如果對未來有更高期望会钝，即使在前端工程師占比不高的情況下伐蒋，依然建議團(tuán)隊(duì)嘗試前后端分離轉(zhuǎn)型，開始著手培養(yǎng)合適的前端工程師迁酸。如果團(tuán)隊(duì)中已經(jīng)有了相當(dāng)規(guī)模的前端工程師先鱼，建議立即轉(zhuǎn)向前后端分離，并且盡早做到前后端代碼分離奸鬓，為前端提供一個(gè)可以進(jìn)行開發(fā)調(diào)試的偽后端焙畔。
微服務(wù)架構(gòu)應(yīng)用
微服務(wù)架構(gòu)應(yīng)用由大量微服務(wù)提供者構(gòu)成，共同為用戶提供服務(wù)串远。在微服務(wù)架構(gòu)中宏多，很多微服務(wù)提供者都是基于SpringBoot實(shí)現(xiàn)的，通過API
Getway（API網(wǎng)關(guān)）進(jìn)行微服務(wù)的整合澡罚，然后在一個(gè)統(tǒng)一的前端門戶上為用戶提供所需服務(wù)伸但。
微服務(wù)基于SpringBoot開發(fā)，要達(dá)到快速交付的目的留搔，并且每個(gè)微服務(wù)的粒度都比較小更胖，這必然需要微服務(wù)的前后端由不同的工程師分別實(shí)現(xiàn)，然后相互之間使用Restful進(jìn)行通訊隔显。如果還是沿用之前的開發(fā)模式却妨，將會增大微服務(wù)架構(gòu)應(yīng)用的構(gòu)建難度。而前后段分離模式正是解決這一難題的良藥括眠。
四彪标、分離部署方案淺析
前后端開發(fā)分離之后，應(yīng)用在部署時(shí)也需要進(jìn)行前后端分離掷豺。在進(jìn)行前后端分離方案選擇的時(shí)候捞烟，需要結(jié)合項(xiàng)目的需求情況和用戶群體來考慮账锹。目前業(yè)內(nèi)較為常用的前后端分離部署方案有如下幾種。
1坷襟、Nginx+Server
將前端資源部署在Nginx上，后端服務(wù)部署在常規(guī)的服務(wù)器生年。當(dāng)瀏覽器發(fā)起訪問請求的時(shí)候婴程，如果請求的是頁面資源，Nginx直接把資源返回到前端抱婉；如果請求是調(diào)用后端服務(wù)档叔，則經(jīng)過Nginx轉(zhuǎn)發(fā)到后端服務(wù)器，完成響應(yīng)后經(jīng)Nginx返回到瀏覽器蒸绩。
這個(gè)方案比較簡單衙四，易于實(shí)現(xiàn)，而且能達(dá)到前后端解耦的目的患亿。
但是對于頁面量比較大传蹈，需要有良好SEO的應(yīng)用來說，此方案缺點(diǎn)也較為明顯步藕。因?yàn)镹ginx只是向?yàn)g覽器返回頁面靜態(tài)資源惦界，而國內(nèi)的搜索引擎爬蟲只會抓取靜態(tài)數(shù)據(jù)，不會解析頁面中的js咙冗，這使得應(yīng)用得不到良好的搜索引擎支持沾歪。同時(shí)因?yàn)镹ginx不會進(jìn)行頁面的組裝渲染，需要把靜態(tài)頁面返回到瀏覽器雾消，然后完成渲染工作灾搏，這加重了瀏覽器的渲染負(fù)擔(dān)。
2立润、Node+Server
這是淘寶所使用的前后端分離模式狂窑，在瀏覽器與后端服務(wù)器之間增加一個(gè)了Node Server作為中間層，將前端資源部署到Node Server中范删。Node
Server中還包含了一層Model Proxy蕾域，負(fù)責(zé)與服務(wù)端進(jìn)行通信。
瀏覽器發(fā)出的請求都被Node Server接收到旦，然后通過Model Proxy調(diào)用后端服務(wù)器提供的服務(wù)旨巷。Node
Server得到后端服務(wù)器反饋，接著在Node Server中完成頁面的組裝渲染添忘，把最終頁面返回給瀏覽器采呐。
如此一來不僅達(dá)到了前后端解耦的目的，還解決了瀏覽器渲染負(fù)擔(dān)過重的問題搁骑，為SEO提供了比較好的支持斧吐。
但在這樣的模式中又固，瀏覽器所有發(fā)出的請求都需要經(jīng)過Node
Server進(jìn)行中轉(zhuǎn)，然后才能到達(dá)后端服務(wù)器煤率。在實(shí)際的應(yīng)用中仰冠，并不是所有的請求都需要頁面渲染，只要在頁面上直接調(diào)用后端服務(wù)器提供的服務(wù)即可蝶糯。所以這個(gè)模式必然會對請求性能有所消耗
3洋只、Nginx+Node+Server
為了能解決方案2中請求性能損失的問題，我們可以考慮在其基礎(chǔ)之上增加Nginx昼捍。瀏覽器發(fā)起的請求經(jīng)過Nginx進(jìn)行分發(fā)识虚，URL請求統(tǒng)一分發(fā)到Node
Server，在Node Server中進(jìn)行頁面組裝渲染妒茬；API請求則直接發(fā)送到后端服務(wù)器担锤，完成響應(yīng)。
目前在已經(jīng)有一個(gè)名為Goku的Go語言框架提供了這樣的前后端分離解決方案乍钻。
通過對三種前后端分離方案的對比可以看出：
如果是企業(yè)級應(yīng)用肛循，不需要考慮對SEO的支持，瀏覽器渲染也可以忽略不計(jì)团赁，Nginx+Server的模式無疑是最好的選擇育拨，實(shí)施成本相對來說比較低；
如果是互聯(lián)網(wǎng)應(yīng)用欢摄，需要有良好的SEO支持熬丧，頁面渲染工作量大，那應(yīng)該選擇Nginx+Node+Server的方案怀挠，各個(gè)方面都能得到比較好的兼顧析蝴。
五、總結(jié)
前后端分離并非僅僅只是前后端開發(fā)的分工绿淋，而是在開發(fā)期進(jìn)行代碼存放分離闷畸、前后端開發(fā)職責(zé)分離，前后端能夠獨(dú)立進(jìn)行開發(fā)測試吞滞；在運(yùn)行期進(jìn)行應(yīng)用部署分離佑菩，前后端之間通過HTTP請求進(jìn)行通訊。前后端分離的開發(fā)模式與傳統(tǒng)模式相比裁赠，能為我們提升開發(fā)效率殿漠、增強(qiáng)代碼可維護(hù)性，讓我們有規(guī)劃地打造一個(gè)前后端并重的精益開發(fā)團(tuán)隊(duì)佩捞，更好地應(yīng)對越來越復(fù)雜多變的Web應(yīng)用開發(fā)需求绞幌。
傳統(tǒng)的前后端混合開發(fā)模式，雖然久經(jīng)考驗(yàn)一忱，到現(xiàn)在依然還是能支撐起應(yīng)用的開發(fā)莲蜘。但是放眼未來谭确，應(yīng)用的云化、微服務(wù)化勢不可擋票渠。同社會分工精細(xì)化一樣逐哈，前后端開發(fā)的精細(xì)化也是必然趨勢。技術(shù)在持續(xù)進(jìn)步问顷，架構(gòu)在不斷演進(jìn)鞠眉，只有緊跟發(fā)展的腳步，不斷調(diào)整項(xiàng)目管理方式择诈，軟件開發(fā)模式，才能在互聯(lián)網(wǎng)浪潮中把握機(jī)會出皇，乘風(fēng)破浪羞芍。
前后端分離，是為了讓彼此更好郊艘。
關(guān)于作者
敖顯奇
現(xiàn)任普元信息SOA產(chǎn)品部開發(fā)工程師荷科，普元新一代數(shù)字化企業(yè)云平臺開發(fā)團(tuán)隊(duì)成員，參與云平臺中VCS纱注、Portal Server領(lǐng)域系統(tǒng)開發(fā)畏浆。過去兩年中參與了普元
Platform產(chǎn)品 7.3~7.5版本以及快速流程實(shí)施框架等功能組件的開發(fā)。
關(guān)于EAII
EAII（Enterprise Architecture Innovation
Institute）企業(yè)架構(gòu)創(chuàng)新研究院狞贱，致力于軟件架構(gòu)創(chuàng)新與實(shí)踐刻获，加速企業(yè)數(shù)字化轉(zhuǎn)型。
