在現(xiàn)在的互聯(lián)網(wǎng)架構(gòu)中，前后端分離已經(jīng)是一個非常常見的系統(tǒng)架構(gòu)方式了，但是我們將前后端分離以后，感覺項(xiàng)目的架構(gòu)比傳統(tǒng)的分層架構(gòu)更復(fù)雜了，需要的人力資源也更多了，甚至項(xiàng)目周期也變得更長了，既然看上去好處不大，為什么還要做前后端分離呢?

[[374770]]

上面這個疑問可能是很多創(chuàng)業(yè)中的互聯(lián)網(wǎng)企業(yè)疑惑的問題，而我們首先要明白，前后端分離并不是一個互聯(lián)網(wǎng)系統(tǒng)必須的架構(gòu)模式，任何的架構(gòu)都是為業(yè)務(wù)服務(wù)的，如果業(yè)務(wù)不需要前后端分離來解決問題，只是單純的為了前后端分離而去分離，那么勢必就會有以上的疑問。

什么時候需要前后端分離呢?

我們一步一步的來看看架構(gòu)的一個演進(jìn)過程：

下圖是一個標(biāo)準(zhǔn)的三層架構(gòu)，Web-Service層通過MVC對系統(tǒng)進(jìn)行了呈現(xiàn)，Business-Service層對業(yè)務(wù)進(jìn)行處理，Data-Service層完成數(shù)據(jù)的交互。每一層都各司其職，而頁面的呈現(xiàn)是交給了后端工程師來完成的(這個時候是可以不要前端工程師的)。

由于頁面的呈現(xiàn)交給了后端工程師，所以后端工程師除了需要深入研究業(yè)務(wù)外，還需要對交互體驗(yàn)、兼容性等等方面的內(nèi)容進(jìn)行關(guān)注，可能在前期業(yè)務(wù)并不復(fù)雜，交互需求并不是很多的時候，我們都可以輕松應(yīng)付，但是隨著業(yè)務(wù)的復(fù)雜度提高，交互性也越來越強(qiáng)，后端工程師變得苦不堪言，甚至后端的業(yè)務(wù)沒有發(fā)生變化，只是頁面進(jìn)行調(diào)整，也需要后端工程師來搞定。

我們在人才引進(jìn)的時候，也就需要越來越全能的程序員，他們既能夠搞定前端的交互、兼容性，還需要對后端的各種技術(shù)非常精通，于是，人才的瓶頸出現(xiàn)了，我們必須解決這個問題。

于是，我們將前端和后端崗位進(jìn)行了劃分(注意，不是前后端分離，只是前端的崗位獨(dú)立出來)，這樣做可以說是緩解了上面出現(xiàn)的問題，交互和兼容性交給了前端工程師，前端工程師將html、css、js搞定后，再拿給后端工程師。前端工程師關(guān)注于前端的事務(wù)，后端工程師關(guān)注于后端的業(yè)務(wù)，看上去好像挺好，但是慢慢的，新的問題出現(xiàn)了。

由于前端的修改頻率遠(yuǎn)遠(yuǎn)的大于后端，特別是很多產(chǎn)品經(jīng)理，對于交互方面有很多的想法，今天調(diào)調(diào)這里，明天調(diào)調(diào)那里，于是，就出現(xiàn)了后端工程師一個地方都沒有改動，但是也需要合并前端的代碼，然后重新編譯、打包、發(fā)布、重啟tomcat。

而且任何的需求，都需要前后端同時完成后才能夠進(jìn)行整體的調(diào)試，任何一個部分出現(xiàn)延期都可能導(dǎo)致整個進(jìn)度的延期。不管是作為后端的研發(fā)還是產(chǎn)品經(jīng)理，都會因?yàn)檫@個問題而被折磨得苦不堪言，于是就開始掉頭發(fā)。

但是沒有關(guān)系，我們作為強(qiáng)大的程序員掉一點(diǎn)頭發(fā)沒什么，還能夠堅(jiān)持。而這個時候，業(yè)務(wù)有了發(fā)展，產(chǎn)品經(jīng)理說，我們的系統(tǒng)需要有手機(jī)移動端，用戶需要在手機(jī)上也能夠使用。需求來了自然就需要響應(yīng)，但是時間緊任務(wù)重，想要快速的實(shí)現(xiàn)手機(jī)端的功能就只有一個方式，那就是Copy。

手機(jī)端的業(yè)務(wù)和PC端大致都是相同的，只是在表現(xiàn)形式上有所不同而已，把PC端的代碼Copy過來，修修改改就有一個手機(jī)端了。說干就干，于是我們的系統(tǒng)架構(gòu)就變成了這樣。

這樣做的話，我們短期的改動最小，能夠快速的讓項(xiàng)目上線，解決目前的問題，但是也會埋下隱患。

很快，新的業(yè)務(wù)需求出現(xiàn)，我們除了PC端和手機(jī)Web端，還需要APP，而對于手機(jī)APP來說，功能和手機(jī)web端是一模一樣，不同的只是原來Mobile版本返回的html數(shù)據(jù)需要改變成json數(shù)據(jù)交給app自己做渲染。

于是，我們又把手機(jī)Web端的代碼Copy出來一份，然后修修補(bǔ)補(bǔ)，變成了APP的Web Api，把原來html格式的返回變成了Json格式。

經(jīng)過產(chǎn)品需求的不斷演進(jìn)變化，在傳統(tǒng)的三層架構(gòu)下，我們的系統(tǒng)架構(gòu)就變成了這樣。

在上面的這種架構(gòu)下，APP端、PC端、Mobile端使用著幾乎相同的Web端代碼，唯一不同的只是前端的呈現(xiàn)方式。但是，Business-Service發(fā)生變化，所有的Web-Service都必須改，幾乎就是把相同的代碼改三次，由于代碼也幾乎都是Copy的，一個地方出現(xiàn)Bug就意味著其他地方都可能出現(xiàn)Bug，改完這個Bug，所有的系統(tǒng)都需要重新發(fā)布。

這種架構(gòu)出現(xiàn)了大量重復(fù)的勞動，而且讓系統(tǒng)維護(hù)的復(fù)雜度變得非常高，既然系統(tǒng)架構(gòu)出現(xiàn)了痛點(diǎn)，自然就需要解決，怎么辦呢?

于是，前后端分離的架構(gòu)就出現(xiàn)了，我們讓后端程序員只負(fù)責(zé)提供統(tǒng)一的接口，而如何調(diào)用這些接口最終做數(shù)據(jù)的呈現(xiàn)和交互，完全交給了前端程序員用Node.js來實(shí)現(xiàn)，這樣，后端的Web-Service避免了大量代碼的Copy，只有一份代碼需要維護(hù)。APP端、PC端、Mobile端需要調(diào)整的時候，也只需要管自己，重新發(fā)布也只是針對自己這個部分，不需要考慮其他端。

這樣前后端就實(shí)現(xiàn)了解耦，也就讓后端程序員能夠更專注于業(yè)務(wù)和性能，不需要再為前端的事情擔(dān)憂。

當(dāng)然，任何的架構(gòu)都是為業(yè)務(wù)服務(wù)的，我們考慮前后端分離也是一樣，如果業(yè)務(wù)不是非常需要前后端分離，那么做前后端分離就是沒有意義的。

例如：

1. 我公司現(xiàn)在是初創(chuàng)階段，人少、產(chǎn)品迭代的速度要快，更需要全棧的程序員，一個人能夠前后端都搞定，這個時候去做前后端分離就是沒有必要的，只會讓系統(tǒng)復(fù)雜度提高，效率變低。
2. 我的產(chǎn)品對于前端的要求不高，沒有什么酷炫的效果，沒有什么兼容性的要求，更重要的是，單純的前端改版的時候不多，那么就放棄前后端分離吧。
3. 公司現(xiàn)在的前端是傳統(tǒng)的前端，技術(shù)體系主要還是在HTML/CSS/JS這個層面，如果去實(shí)現(xiàn)前后端分離，就需要前端具備后端的一些知識，學(xué)習(xí)很多新的技能，這可能很難馬上改變。

總而言之，實(shí)行前后端分離的架構(gòu)，和各方面因素都有關(guān)系，不能只是因?yàn)樽龆プ觥?/p>