有水友在評(píng)論中留言問(wèn)我：

今天，簡(jiǎn)單說(shuō)說(shuō)，互聯(lián)網(wǎng)分層架構(gòu)里的前后端分離。

畫(huà)外音：“別人在搞xxoo技術(shù)”一定不能成為，一家公司推動(dòng)“xxoo技術(shù)”的理由。

上圖，是一個(gè)典型的互聯(lián)網(wǎng)分層架構(gòu)：

• 業(yè)務(wù)站點(diǎn)層：web-server;
• 業(yè)務(wù)服務(wù)層：biz-service;
• 基礎(chǔ)數(shù)據(jù)服務(wù)層：data-service;
• 數(shù)據(jù)存儲(chǔ)層：db+cache;

隨著時(shí)間的推移，業(yè)務(wù)越來(lái)越復(fù)雜，改版越來(lái)越多，此時(shí)業(yè)務(wù)站點(diǎn)層web-server層雖然使用了MVC架構(gòu)，但以下諸多痛點(diǎn)是否似曾相識(shí)?

(1)產(chǎn)品追求絢麗的效果，并對(duì)設(shè)備兼容性要求高，這些需求不斷折磨著使用MVC的Java工程師們;

畫(huà)外音：本文以Java后端舉例。

(2)不管是PC，還是手機(jī)H5，還是APP，應(yīng)用前端展現(xiàn)的變化頻率遠(yuǎn)遠(yuǎn)大于后端邏輯的變化頻率，改velocity模版并不是Java工程師喜歡和擅長(zhǎng)的工作;

畫(huà)外音：感謝那些喜歡做改版的產(chǎn)品經(jīng)理。

此時(shí)，為了緩解這些問(wèn)題，一般會(huì)成立單獨(dú)的前端FE部門，來(lái)負(fù)責(zé)交互與展現(xiàn)的研發(fā)，其職責(zé)與后端Java工程師分離開(kāi)，但痛點(diǎn)真的解決了嗎?

• 一點(diǎn)點(diǎn)展現(xiàn)的改動(dòng)，需要Java工程師們重新編譯，打包，上線，重啟tomcat，效率極低;
• 原先Java工程師負(fù)責(zé)所有MVC的研發(fā)工作，現(xiàn)在分為Java和FE兩塊，需要等前端和后端都完成研發(fā)，才能一起調(diào)試整體效果，不僅增加了溝通成本，任何一塊出問(wèn)題，都可能導(dǎo)致項(xiàng)目延期;

畫(huà)外音：你有沒(méi)有被折磨過(guò)?

更具體的，看一個(gè)這樣的例子，最開(kāi)始產(chǎn)品只有PC版本，此時(shí)其系統(tǒng)分層架構(gòu)如下：

客戶端，web-server，service，非常清晰。

隨著業(yè)務(wù)的發(fā)展，產(chǎn)品需要新增Mobile版本，Mobile版本和PC版本大部分業(yè)務(wù)邏輯都一樣，區(qū)別是什么呢?

• 信息展現(xiàn)的條數(shù)會(huì)比較少，即調(diào)用service服務(wù)時(shí)，傳入的參數(shù)會(huì)不一樣;
• 產(chǎn)品功能會(huì)比較少，大部分service的調(diào)用一樣，少數(shù)service不需要調(diào)用;
• 展現(xiàn)，交互會(huì)有所區(qū)別;

由于工期較緊，Mobile版本的web-server一般怎么來(lái)呢?

沒(méi)錯(cuò)，把PC版本的工程拷貝一份，然后再做小量的修改：

• service調(diào)用的參數(shù)有些變化;
• 大部分service的調(diào)用一樣，少數(shù)service的調(diào)用去掉;
• 修改展現(xiàn)，交互相關(guān)的代碼;

畫(huà)外音：你有沒(méi)有拷貝過(guò)代碼?

業(yè)務(wù)繼續(xù)發(fā)展，產(chǎn)品又需要新增APP版本，APP版本和Mobile版本業(yè)務(wù)邏輯完全相同，區(qū)別是什么呢?

(1)Mobile版本返回html格式的數(shù)據(jù)，APP版本返回json格式的數(shù)據(jù)，然后進(jìn)行本地渲染;

由于工期較緊，APP版本的web-server一般怎么來(lái)呢?

沒(méi)錯(cuò)，把Mobile版本的工程拷貝一份，然后再做小量的修改：

(2) 把拼裝html數(shù)據(jù)的代碼，修改為拼裝json數(shù)據(jù);

這么迭代演化，架構(gòu)會(huì)進(jìn)化成什么樣子?

• 端：是PC，Mobile，APP;
• 站點(diǎn)應(yīng)用層：是PC站，M站，APP站;
• 服務(wù)層：通用的業(yè)務(wù)服務(wù)，以及基礎(chǔ)數(shù)據(jù)服務(wù);

這個(gè)架構(gòu)圖中的依賴關(guān)系是不是看上去很別扭?

• 端到web-server之間連接關(guān)系很清晰;
• web-server與service之間的連接關(guān)系變成了蜘蛛網(wǎng);

上述分層架構(gòu)，可能存在什么問(wèn)題呢?

PC/H5/APP的web-server層大部分業(yè)務(wù)是相同的，只有少數(shù)的邏輯/展現(xiàn)/交互不一樣：

• 一旦一個(gè)服務(wù)RPC接口有稍許變化，所有web-server系統(tǒng)都需要升級(jí)修改;
• web-server之間存在大量代碼拷貝;
• 一旦拷貝代碼，出現(xiàn)一個(gè)bug，多個(gè)子系統(tǒng)都需要升級(jí)修改;

如何讓數(shù)據(jù)的獲取更加高效快捷，如何讓數(shù)據(jù)生產(chǎn)與數(shù)據(jù)展現(xiàn)解耦分離呢?

前后端分離的分層抽象勢(shì)在必行。

通過(guò)前后端分離分層抽象：

• 站點(diǎn)展示層：node.js，負(fù)責(zé)數(shù)據(jù)的展現(xiàn)與交互，由FE維護(hù);
• 站點(diǎn)數(shù)據(jù)層：web-server，負(fù)責(zé)業(yè)務(wù)邏輯與json數(shù)據(jù)接口的提供，由Java工程師維護(hù);

這樣做有什么好處呢?

• 復(fù)雜的業(yè)務(wù)邏輯與數(shù)據(jù)生成，只有在站點(diǎn)數(shù)據(jù)層處寫了一次，沒(méi)有代碼拷貝;
• 底層service接口發(fā)生變化，只有站點(diǎn)數(shù)據(jù)層一處需要升級(jí)修改;
• 底層service如果有bug，只有站點(diǎn)數(shù)據(jù)層一處需要升級(jí)修改;
• 站點(diǎn)展現(xiàn)層可以根據(jù)產(chǎn)品的不同形態(tài)，傳入不同的參數(shù)，調(diào)用不同的站點(diǎn)數(shù)據(jù)層接口;

除此之外，還有其他諸多優(yōu)點(diǎn)：

• 產(chǎn)品追求絢麗的效果，并對(duì)設(shè)備兼容性要求高，不再困擾Java工程師，由更專業(yè)的FE對(duì)接;
• 一點(diǎn)點(diǎn)展現(xiàn)的改動(dòng)，不再需要Java工程師們重新編譯，打包，上線，重啟tomcat;
• 約定好json接口后，Java和FE分開(kāi)開(kāi)發(fā)，F(xiàn)E可以用mock的接口自測(cè)，不再等待一起聯(lián)調(diào);

于是乎，如上圖所示，架構(gòu)進(jìn)化了，前后端分離了。

當(dāng)業(yè)務(wù)越來(lái)越復(fù)雜，端上的產(chǎn)品越來(lái)越多，展現(xiàn)層的變化越來(lái)越快越來(lái)越多，站點(diǎn)層存在大量代碼拷貝，數(shù)據(jù)獲取復(fù)雜性成為通用痛點(diǎn)的時(shí)候，就應(yīng)該進(jìn)行前后端分離分層抽象，簡(jiǎn)化數(shù)據(jù)獲取過(guò)程，提高數(shù)據(jù)獲取效率，向上游屏蔽底層的復(fù)雜性。

另外要強(qiáng)調(diào)的是，是否需要前后端分離，和業(yè)務(wù)復(fù)雜性，業(yè)務(wù)發(fā)展階段，人員素質(zhì)模型有關(guān)，千萬(wàn)不可一概而論。

要實(shí)施前后端分離，以下四點(diǎn)是必須要考慮的。

(1) 第一點(diǎn)，SEO的考慮。

如果是 PC 端的站點(diǎn)，需要考慮是否需要強(qiáng)支持 SEO ，前后端分離的架構(gòu)，很可能對(duì)搜索引擎的 spider 不友好，可能影響站點(diǎn)的收錄。

當(dāng)然，如果是原生 APP ，后端 node.js 只返回 json 數(shù)據(jù)，或者單頁(yè)應(yīng)用 SPA (對(duì)百度來(lái)說(shuō)就是一個(gè)頁(yè)面)，則不太需要考慮這方面的問(wèn)題。

(2) 第二點(diǎn)，產(chǎn)品特性的考慮。

很多產(chǎn)品追求酷炫的前端效果，并且對(duì)前端兼容性要求很高，前端產(chǎn)品改版頻率很高，那么前后端分離是有必要的。

否則，前后端分離只會(huì)帶來(lái)更多系統(tǒng)架構(gòu)的復(fù)雜性。

第三點(diǎn)，公司發(fā)展階段考慮。

公司發(fā)展的初級(jí)階段，人比較少，對(duì)產(chǎn)品迭代速度的要求較高，此時(shí)更多的需要一些全棧的工程師，一個(gè)人開(kāi)發(fā)從前到后全搞定。如果此時(shí)實(shí)施前后端分離，將引入“聯(lián)調(diào)”一說(shuō)，并且增加了溝通成本比，可能導(dǎo)致產(chǎn)品迭代的速度降低。

第四點(diǎn)、人員技能考慮。傳統(tǒng) FE 與后端 Java/PHP 工程師的合作方式， FE 工程師不需要有很深的后端功底，一旦引入前后端分離， node.js 層的前端同學(xué)需要了解更多的后端知識(shí)體系，不排除有 FE 同學(xué)對(duì)后端技能的排斥，引發(fā)人員的不穩(wěn)定。

總之，前后端分離不只是一個(gè)分層架構(gòu)的技術(shù)決策，和SEO、產(chǎn)品特性、公司發(fā)展階段、人員知識(shí)體系相關(guān)，千萬(wàn)不可一概而論。

任何脫離業(yè)務(wù)的架構(gòu)設(shè)計(jì)，都是耍流氓。

希望大家有收獲。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文