建站
咨詢
售后
建站咨詢
新聞中心
在現(xiàn)在的互聯(lián)網(wǎng)架構(gòu)中，前后端分離已經(jīng)是一個(gè)非常常見(jiàn)的系統(tǒng)架構(gòu)方式了，但是我們將前后端分離以后，感覺(jué)項(xiàng)目的架構(gòu)比傳統(tǒng)的分層架構(gòu)更復(fù)雜了，需要的人力資源也更多了，甚至項(xiàng)目周期也變得更長(zhǎng)了，既然看上去好處不大，為什么還要做前后端分離呢?
上面這個(gè)疑問(wèn)可能是很多創(chuàng)業(yè)中的互聯(lián)網(wǎng)企業(yè)疑惑的問(wèn)題，而我們首先要明白，前后端分離并不是一個(gè)互聯(lián)網(wǎng)系統(tǒng)必須的架構(gòu)模式，任何的架構(gòu)都是為業(yè)務(wù)服務(wù)的，如果業(yè)務(wù)不需要前后端分離來(lái)解決問(wèn)題，只是單純的為了前后端分離而去分離，那么勢(shì)必就會(huì)有以上的疑問(wèn)。
什么時(shí)候需要前后端分離呢?
我們一步一步的來(lái)看看架構(gòu)的一個(gè)演進(jìn)過(guò)程：
下圖是一個(gè)標(biāo)準(zhǔn)的三層架構(gòu)，Web-Service層通過(guò)MVC對(duì)系統(tǒng)進(jìn)行了呈現(xiàn)，Business-Service層對(duì)業(yè)務(wù)進(jìn)行處理，Data-Service層完成數(shù)據(jù)的交互。每一層都各司其職，而頁(yè)面的呈現(xiàn)是交給了后端工程師來(lái)完成的(這個(gè)時(shí)候是可以不要前端工程師的)。
由于頁(yè)面的呈現(xiàn)交給了后端工程師，所以后端工程師除了需要深入研究業(yè)務(wù)外，還需要對(duì)交互體驗(yàn)、兼容性等等方面的內(nèi)容進(jìn)行關(guān)注，可能在前期業(yè)務(wù)并不復(fù)雜，交互需求并不是很多的時(shí)候，我們都可以輕松應(yīng)付，但是隨著業(yè)務(wù)的復(fù)雜度提高，交互性也越來(lái)越強(qiáng)，后端工程師變得苦不堪言，甚至后端的業(yè)務(wù)沒(méi)有發(fā)生變化，只是頁(yè)面進(jìn)行調(diào)整，也需要后端工程師來(lái)搞定。
我們?cè)谌瞬乓M(jìn)的時(shí)候，也就需要越來(lái)越全能的程序員，他們既能夠搞定前端的交互、兼容性，還需要對(duì)后端的各種技術(shù)非常精通，于是，人才的瓶頸出現(xiàn)了，我們必須解決這個(gè)問(wèn)題。
于是，我們將前端和后端崗位進(jìn)行了劃分(注意，不是前后端分離，只是前端的崗位獨(dú)立出來(lái))，這樣做可以說(shuō)是緩解了上面出現(xiàn)的問(wèn)題，交互和兼容性交給了前端工程師，前端工程師將html、css、js搞定后，再拿給后端工程師。前端工程師關(guān)注于前端的事務(wù)，后端工程師關(guān)注于后端的業(yè)務(wù)，看上去好像挺好，但是慢慢的，新的問(wèn)題出現(xiàn)了。
由于前端的修改頻率遠(yuǎn)遠(yuǎn)的大于后端，特別是很多產(chǎn)品經(jīng)理，對(duì)于交互方面有很多的想法，今天調(diào)調(diào)這里，明天調(diào)調(diào)那里，于是，就出現(xiàn)了后端工程師一個(gè)地方都沒(méi)有改動(dòng)，但是也需要合并前端的代碼，然后重新編譯、打包、發(fā)布、重啟tomcat。
而且任何的需求，都需要前后端同時(shí)完成后才能夠進(jìn)行整體的調(diào)試，任何一個(gè)部分出現(xiàn)延期都可能導(dǎo)致整個(gè)進(jìn)度的延期。不管是作為后端的研發(fā)還是產(chǎn)品經(jīng)理，都會(huì)因?yàn)檫@個(gè)問(wèn)題而被折磨得苦不堪言，于是就開(kāi)始掉頭發(fā)。
但是沒(méi)有關(guān)系，我們作為強(qiáng)大的程序員掉一點(diǎn)頭發(fā)沒(méi)什么，還能夠堅(jiān)持。而這個(gè)時(shí)候，業(yè)務(wù)有了發(fā)展，產(chǎn)品經(jīng)理說(shuō)，我們的系統(tǒng)需要有手機(jī)移動(dòng)端，用戶需要在手機(jī)上也能夠使用。需求來(lái)了自然就需要響應(yīng)，但是時(shí)間緊任務(wù)重，想要快速的實(shí)現(xiàn)手機(jī)端的功能就只有一個(gè)方式，那就是Copy。
手機(jī)端的業(yè)務(wù)和PC端大致都是相同的，只是在表現(xiàn)形式上有所不同而已，把PC端的代碼Copy過(guò)來(lái)，修修改改就有一個(gè)手機(jī)端了。說(shuō)干就干，于是我們的系統(tǒng)架構(gòu)就變成了這樣。
這樣做的話，我們短期的改動(dòng)最小，能夠快速的讓項(xiàng)目上線，解決目前的問(wèn)題，但是也會(huì)埋下隱患。
很快，新的業(yè)務(wù)需求出現(xiàn)，我們除了PC端和手機(jī)Web端，還需要APP，而對(duì)于手機(jī)APP來(lái)說(shuō)，功能和手機(jī)web端是一模一樣，不同的只是原來(lái)Mobile版本返回的html數(shù)據(jù)需要改變成json數(shù)據(jù)交給app自己做渲染。
于是，我們又把手機(jī)Web端的代碼Copy出來(lái)一份，然后修修補(bǔ)補(bǔ)，變成了APP的Web Api，把原來(lái)html格式的返回變成了Json格式。
經(jīng)過(guò)產(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的，一個(gè)地方出現(xiàn)Bug就意味著其他地方都可能出現(xiàn)Bug，改完這個(gè)Bug，所有的系統(tǒng)都需要重新發(fā)布。
這種架構(gòu)出現(xiàn)了大量重復(fù)的勞動(dòng)，而且讓系統(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來(lái)實(shí)現(xiàn)，這樣，后端的Web-Service避免了大量代碼的Copy，只有一份代碼需要維護(hù)。APP端、PC端、Mobile端需要調(diào)整的時(shí)候，也只需要管自己，重新發(fā)布也只是針對(duì)自己這個(gè)部分，不需要考慮其他端。
這樣前后端就實(shí)現(xiàn)了解耦，也就讓后端程序員能夠更專注于業(yè)務(wù)和性能，不需要再為前端的事情擔(dān)憂。
當(dāng)然，任何的架構(gòu)都是為業(yè)務(wù)服務(wù)的，我們考慮前后端分離也是一樣，如果業(yè)務(wù)不是非常需要前后端分離，那么做前后端分離就是沒(méi)有意義的。
例如：
- 我公司現(xiàn)在是初創(chuàng)階段，人少、產(chǎn)品迭代的速度要快，更需要全棧的程序員，一個(gè)人能夠前后端都搞定，這個(gè)時(shí)候去做前后端分離就是沒(méi)有必要的，只會(huì)讓系統(tǒng)復(fù)雜度提高，效率變低。
- 我的產(chǎn)品對(duì)于前端的要求不高，沒(méi)有什么酷炫的效果，沒(méi)有什么兼容性的要求，更重要的是，單純的前端改版的時(shí)候不多，那么就放棄前后端分離吧。
- 公司現(xiàn)在的前端是傳統(tǒng)的前端，技術(shù)體系主要還是在HTML/CSS/JS這個(gè)層面，如果去實(shí)現(xiàn)前后端分離，就需要前端具備后端的一些知識(shí)，學(xué)習(xí)很多新的技能，這可能很難馬上改變。
總而言之，實(shí)行前后端分離的架構(gòu)，和各方面因素都有關(guān)系，不能只是因?yàn)樽龆プ觥?/p>
本文名稱：互聯(lián)網(wǎng)系統(tǒng)架構(gòu)為什么要做前后端分離呢？
鏈接URL：http://fisionsoft.com.cn/article/cosdpso.html
