互聯網分層架構，爲啥要先後端分離？

有水友在評論中留言問我：

沈老師，我在一家創業公司，大概有20人左右的研發團隊。

團隊正在推動先後端分離，我以爲架構變得複雜了，項目研發週期變長了，但組長說，互聯網公司都在搞先後端分離，因此咱們也要搞。

我仍是不理解，爲何要進行先後端分離呀？

今天，簡單說說，互聯網分層架構裏的先後端分離。

畫外音：「別人在搞xxoo技術」必定不能成爲，一家公司推進「xxoo技術」的理由。

上圖，是一個典型的互聯網分層架構：

（1）業務站點層：web-server；

（2）業務服務層：biz-service；

（3）基礎數據服務層：data-service；

（4）數據存儲層：db+cache；

 

隨着時間的推移，業務愈來愈複雜，改版愈來愈多，此時業務站點層web-server層雖然使用了MVC架構，但如下諸多痛點是否似曾相識？

（1）產品追求絢麗的效果，並對設備兼容性要求高，這些需求不斷折磨着使用MVC的Java工程師們；

畫外音：本文以Java後端舉例。

（2）不論是PC，仍是手機H5，仍是APP，應用前端展示的變化頻率遠遠大於後端邏輯的變化頻率，改velocity模版並非Java工程師喜歡和擅長的工做；

畫外音：感謝那些喜歡作改版的產品經理。

 

此時，爲了緩解這些問題，通常會成立單獨的前端FE部門，來負責交互與展示的研發，其職責與後端Java工程師分離開，但痛點真的解決了嗎？

（1）一點點展示的改動，須要Java工程師們從新編譯，打包，上線，重啓tomcat，效率極低；

（2）原先Java工程師負責全部MVC的研發工做，如今分爲Java和FE兩塊，須要等前端和後端都完成研發，才能一塊兒調試總體效果，不只增長了溝通成本，任何一塊出問題，均可能致使項目延期；

畫外音：你有沒有被折磨過？

 

更具體的，看一個這樣的例子，最開始產品只有PC版本，此時其系統分層架構以下：

客戶端，web-server，service，很是清晰。

 

隨着業務的發展，產品須要新增Mobile版本，Mobile版本和PC版本大部分業務邏輯都同樣，區別是什麼呢？

（1）信息展示的條數會比較少，即調用service服務時，傳入的參數會不同；

（2）產品功能會比較少，大部分service的調用同樣，少數service不須要調用；

（3）展示，交互會有所區別；

 

因爲工期較緊，Mobile版本的web-server通常怎麼來呢？

沒錯，把PC版本的工程拷貝一份，而後再作小量的修改：

（1）service調用的參數有些變化；

（2）大部分service的調用同樣，少數service的調用去掉；

（3）修改展示，交互相關的代碼；

畫外音：你有沒有拷貝過代碼？

 

業務繼續發展，產品又須要新增APP版本，APP版本和Mobile版本業務邏輯徹底相同，區別是什麼呢？

（1）Mobile版本返回html格式的數據，APP版本返回json格式的數據，而後進行本地渲染；

 

因爲工期較緊，APP版本的web-server通常怎麼來呢？

沒錯，把Mobile版本的工程拷貝一份，而後再作小量的修改：

（1）把拼裝html數據的代碼，修改成拼裝json數據；

這麼迭代演化，架構會進化成什麼樣子？

（1）端：是PC，Mobile，APP；

（2）站點應用層：是PC站，M站，APP站；

（3）服務層：通用的業務服務，以及基礎數據服務；

 

這個架構圖中的依賴關係是否是看上去很彆扭？

（1）端到web-server之間鏈接關係很清晰；

（2）web-server與service之間的鏈接關係變成了蜘蛛網；

 

上述分層架構，可能存在什麼問題呢？

PC/H5/APP的web-server層大部分業務是相同的，只有少數的邏輯/展示/交互不同：

（1）一旦一個服務RPC接口有稍許變化，全部web-server系統都須要升級修改；

（2）web-server之間存在大量代碼拷貝；

（3）一旦拷貝代碼，出現一個bug，多個子系統都須要升級修改；

 

如何讓數據的獲取更加高效快捷，如何讓數據生產與數據展示解耦分離呢？

先後端分離的分層抽象勢在必行。

經過先後端分離分層抽象：

（1）站點展現層：node.js，負責數據的展示與交互，由FE維護；

（2）站點數據層：web-server，負責業務邏輯與json數據接口的提供，由Java工程師維護；

 

這樣作有什麼好處呢？

（1）複雜的業務邏輯與數據生成，只有在站點數據層處寫了一次，沒有代碼拷貝；

（2）底層service接口發生變化，只有站點數據層一處須要升級修改；

（3）底層service若是有bug，只有站點數據層一處須要升級修改；

（4）站點展示層能夠根據產品的不一樣形態，傳入不一樣的參數，調用不一樣的站點數據層接口；

 

除此以外，還有其餘諸多優勢：

（1）產品追求絢麗的效果，並對設備兼容性要求高，再也不困擾Java工程師，由更專業的FE對接；

（2）一點點展示的改動，再也不須要Java工程師們從新編譯，打包，上線，重啓tomcat；

（3）約定好json接口後，Java和FE分開開發，FE能夠用mock的接口自測，再也不等待一塊兒聯調；

 

因而乎，如上圖所示，架構進化了，先後端分離了。

當業務愈來愈複雜，端上的產品愈來愈多，展示層的變化愈來愈快愈來愈多，站點層存在大量代碼拷貝，數據獲取複雜性成爲通用痛點的時候，就應該進行先後端分離分層抽象，簡化數據獲取過程，提升數據獲取效率，向上遊屏蔽底層的複雜性。

 

另外要強調的是，是否須要先後端分離，和業務複雜性，業務發展階段，人員素質模型有關，千萬不可一律而論。

要實施先後端分離，如下四點是必需要考慮的。

第一點，SEO的考慮。

若是是 PC 端的站點，須要考慮是否須要強支持 SEO ，先後端分離的架構，極可能對搜索引擎的 spider 不友好，可能影響站點的收錄。

固然，若是是原生 APP ，後端 node.js 只返回 json 數據，或者單頁應用 SPA （對百度來講就是一個頁面），則不太須要考慮這方面的問題。

 

第二點，產品特性的考慮。

不少產品追求酷炫的前端效果，而且對前端兼容性要求很高，前端產品改版頻率很高，那麼先後端分離是有必要的。

不然，先後端分離只會帶來更多系統架構的複雜性。

 

第三點，公司發展階段考慮。

公司發展的初級階段，人比較少，對產品迭代速度的要求較高，此時更多的須要一些全棧的工程師，一我的開發從前到後全搞定。若是此時實施先後端分離，將引入「聯調」一說，而且增長了溝通成本比，可能致使產品迭代的速度下降。

 

第四點、人員技能考慮。

傳統 FE 與後端 Java/PHP 工程師的合做方式， FE 工程師不須要有很深的後端功底，一旦引入先後端分離， node.js 層的前端同窗須要瞭解更多的後端知識體系，不排除有 FE 同窗對後端技能的排斥，引起人員的不穩定。

 

總之，先後端分離不僅是一個分層架構的技術決策，和SEO、產品特性、公司發展階段、人員知識體系相關，千萬不可一律而論。

 

任何脫離業務的架構設計，都是耍流氓。

但願你們有收穫。

若是你喜歡這種講技術的方式， 掃碼 一塊兒玩 。

有方法論，能落地，視頻講架構

本文分享自微信公衆號 - 架構師之路（road5858）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。