建站
咨詢
售后
建站咨詢
新聞中心
有水友在評論中留言問我：
| 沈老師，我在一家創(chuàng)業(yè)公司，大概有20人左右的研發(fā)團隊。 團隊正在推進前后端分離，我覺得架構變得復雜了，項目研發(fā)周期變長了，但組長說，互聯(lián)網公司都在搞前后端分離，所以我們也要搞。 我還是不理解，為什么要進行前后端分離呀? |
今天，簡單說說，互聯(lián)網分層架構里的前后端分離。
畫外音：“別人在搞xxoo技術”一定不能成為，一家公司推動“xxoo技術”的理由。
上圖，是一個典型的互聯(lián)網分層架構：
- 業(yè)務站點層：web-server;
- 業(yè)務服務層：biz-service;
- 基礎數(shù)據(jù)服務層：data-service;
- 數(shù)據(jù)存儲層：db+cache;
隨著時間的推移，業(yè)務越來越復雜，改版越來越多，此時業(yè)務站點層web-server層雖然使用了MVC架構，但以下諸多痛點是否似曾相識?
(1)產品追求絢麗的效果，并對設備兼容性要求高，這些需求不斷折磨著使用MVC的Java工程師們;
畫外音：本文以Java后端舉例。
(2)不管是PC，還是手機H5，還是APP，應用前端展現(xiàn)的變化頻率遠遠大于后端邏輯的變化頻率，改velocity模版并不是Java工程師喜歡和擅長的工作;
畫外音：感謝那些喜歡做改版的產品經理。
此時，為了緩解這些問題，一般會成立單獨的前端FE部門，來負責交互與展現(xiàn)的研發(fā)，其職責與后端Java工程師分離開，但痛點真的解決了嗎?
- 一點點展現(xiàn)的改動，需要Java工程師們重新編譯，打包，上線，重啟tomcat，效率極低;
- 原先Java工程師負責所有MVC的研發(fā)工作，現(xiàn)在分為Java和FE兩塊，需要等前端和后端都完成研發(fā)，才能一起調試整體效果，不僅增加了溝通成本，任何一塊出問題，都可能導致項目延期;
畫外音：你有沒有被折磨過?
更具體的，看一個這樣的例子，最開始產品只有PC版本，此時其系統(tǒng)分層架構如下：
客戶端，web-server，service，非常清晰。
隨著業(yè)務的發(fā)展，產品需要新增Mobile版本，Mobile版本和PC版本大部分業(yè)務邏輯都一樣，區(qū)別是什么呢?
- 信息展現(xiàn)的條數(shù)會比較少，即調用service服務時，傳入的參數(shù)會不一樣;
- 產品功能會比較少，大部分service的調用一樣，少數(shù)service不需要調用;
- 展現(xiàn)，交互會有所區(qū)別;
由于工期較緊，Mobile版本的web-server一般怎么來呢?
沒錯，把PC版本的工程拷貝一份，然后再做小量的修改：
- service調用的參數(shù)有些變化;
- 大部分service的調用一樣，少數(shù)service的調用去掉;
- 修改展現(xiàn)，交互相關的代碼;
畫外音：你有沒有拷貝過代碼?
業(yè)務繼續(xù)發(fā)展，產品又需要新增APP版本，APP版本和Mobile版本業(yè)務邏輯完全相同，區(qū)別是什么呢?
(1)Mobile版本返回html格式的數(shù)據(jù)，APP版本返回json格式的數(shù)據(jù)，然后進行本地渲染;
由于工期較緊，APP版本的web-server一般怎么來呢?
沒錯，把Mobile版本的工程拷貝一份，然后再做小量的修改：
(2) 把拼裝html數(shù)據(jù)的代碼，修改為拼裝json數(shù)據(jù);
這么迭代演化，架構會進化成什么樣子?
- 端：是PC，Mobile，APP;
- 站點應用層：是PC站，M站，APP站;
- 服務層：通用的業(yè)務服務，以及基礎數(shù)據(jù)服務;
這個架構圖中的依賴關系是不是看上去很別扭?
- 端到web-server之間連接關系很清晰;
- web-server與service之間的連接關系變成了蜘蛛網;
上述分層架構，可能存在什么問題呢?
PC/H5/APP的web-server層大部分業(yè)務是相同的，只有少數(shù)的邏輯/展現(xiàn)/交互不一樣：
- 一旦一個服務RPC接口有稍許變化，所有web-server系統(tǒng)都需要升級修改;
- web-server之間存在大量代碼拷貝;
- 一旦拷貝代碼，出現(xiàn)一個bug，多個子系統(tǒng)都需要升級修改;
如何讓數(shù)據(jù)的獲取更加高效快捷，如何讓數(shù)據(jù)生產與數(shù)據(jù)展現(xiàn)解耦分離呢?
前后端分離的分層抽象勢在必行。
通過前后端分離分層抽象：
- 站點展示層：node.js，負責數(shù)據(jù)的展現(xiàn)與交互，由FE維護;
- 站點數(shù)據(jù)層：web-server，負責業(yè)務邏輯與json數(shù)據(jù)接口的提供，由Java工程師維護;
這樣做有什么好處呢?
- 復雜的業(yè)務邏輯與數(shù)據(jù)生成，只有在站點數(shù)據(jù)層處寫了一次，沒有代碼拷貝;
- 底層service接口發(fā)生變化，只有站點數(shù)據(jù)層一處需要升級修改;
- 底層service如果有bug，只有站點數(shù)據(jù)層一處需要升級修改;
- 站點展現(xiàn)層可以根據(jù)產品的不同形態(tài)，傳入不同的參數(shù)，調用不同的站點數(shù)據(jù)層接口;
除此之外，還有其他諸多優(yōu)點：
- 產品追求絢麗的效果，并對設備兼容性要求高，不再困擾Java工程師，由更專業(yè)的FE對接;
- 一點點展現(xiàn)的改動，不再需要Java工程師們重新編譯，打包，上線，重啟tomcat;
- 約定好json接口后，Java和FE分開開發(fā)，F(xiàn)E可以用mock的接口自測，不再等待一起聯(lián)調;
于是乎，如上圖所示，架構進化了，前后端分離了。
當業(yè)務越來越復雜，端上的產品越來越多，展現(xiàn)層的變化越來越快越來越多，站點層存在大量代碼拷貝，數(shù)據(jù)獲取復雜性成為通用痛點的時候，就應該進行前后端分離分層抽象，簡化數(shù)據(jù)獲取過程，提高數(shù)據(jù)獲取效率，向上游屏蔽底層的復雜性。
另外要強調的是，是否需要前后端分離，和業(yè)務復雜性，業(yè)務發(fā)展階段，人員素質模型有關，千萬不可一概而論。
要實施前后端分離，以下四點是必須要考慮的。
(1) 第一點，SEO的考慮。
如果是 PC 端的站點，需要考慮是否需要強支持 SEO ，前后端分離的架構，很可能對搜索引擎的 spider 不友好，可能影響站點的收錄。
當然，如果是原生 APP ，后端 node.js 只返回 json 數(shù)據(jù)，或者單頁應用 SPA (對百度來說就是一個頁面)，則不太需要考慮這方面的問題。
(2) 第二點，產品特性的考慮。
很多產品追求酷炫的前端效果，并且對前端兼容性要求很高，前端產品改版頻率很高，那么前后端分離是有必要的。
否則，前后端分離只會帶來更多系統(tǒng)架構的復雜性。
第三點，公司發(fā)展階段考慮。
公司發(fā)展的初級階段，人比較少，對產品迭代速度的要求較高，此時更多的需要一些全棧的工程師，一個人開發(fā)從前到后全搞定。如果此時實施前后端分離，將引入“聯(lián)調”一說，并且增加了溝通成本比，可能導致產品迭代的速度降低。
第四點、人員技能考慮。傳統(tǒng) FE 與后端 Java/PHP 工程師的合作方式， FE 工程師不需要有很深的后端功底，一旦引入前后端分離， node.js 層的前端同學需要了解更多的后端知識體系，不排除有 FE 同學對后端技能的排斥，引發(fā)人員的不穩(wěn)定。
總之，前后端分離不只是一個分層架構的技術決策，和SEO、產品特性、公司發(fā)展階段、人員知識體系相關，千萬不可一概而論。
任何脫離業(yè)務的架構設計，都是耍流氓。
希望大家有收獲。
【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯(lián)系原作者】
網頁標題：互聯(lián)網分層架構，為啥要前后端分離？
URL地址：http://fisionsoft.com.cn/article/djcidoc.html
