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

[[374770]]

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

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

我們一步一步的來看看架構的一個演進過程：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例如：

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

總而言之，實行前后端分離的架構，和各方面因素都有關系，不能只是因為做而去做。