網際網路分層架構，為啥要前後端分離？

出處：

http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651960501&idx=1&sn=a452bab31c0457063241df237f955332&chksm=bd2d01698a5a887f9dfa5c6966d9e71bf492a040ab2dbe4e469ef38dd8ee5ab00b7c562a88e8&mpshare=1&scene=1&srcid=0429qWHxsQf3gqxYKW39Zxt9#rd

通用業務服務化之後，系統的典型後端結構如上：

• web-server通過RPC介面，從通用業務服務獲取資料

• biz-service通過RPC介面，從多個基礎資料service獲取資料

• 基礎資料service通過DAO，從獨立db/cache獲取資料

• db/cache儲存資料

 

隨著時間的推移，系統架構並不會一成不變，業務越來越複雜，改版越來越多，此時web-server層雖然使用了MVC架構，但以下諸多痛點是否似曾相識？

• 產品追求絢麗的效果，並對裝置相容性要求高，這些需求不斷折磨著使用MVC的Java工程師們（本文以Java舉例）

• 不管是PC，還是手機H5，還是APP，應用前端展現的變化頻率遠遠大於後端邏輯的變化頻率（感謝那些喜歡做改版的產品經理），改velocity模版並不是Java工程師喜歡和擅長的工作

 

此時，為了緩解這些問題，一般會成立單獨的前端FE部門，來負責互動與展現的研發，其職責與後端Java工程師分離開，但痛點依然沒有完全解決：

• 一點點展現的改動，需要Java工程師們重新編譯，打包，上線，重啟tomcat，效率極低

• 原先Java工程師負責所有MVC的研發工作，現在分為Java和FE兩塊，需要等前端和後端都完成研發，才能一起除錯整體效果，不僅增加了溝通成本，任何一塊出問題，都可能導致專案延期

 

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

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

 

隨著業務的發展，產品需要新增Mobile版本，Mobile版本和PC版本大部分業務邏輯都一樣，唯一的區別是螢幕比較小：

• 資訊展現的條數會比較少，即呼叫service服務時，傳入的引數會不一樣

• 產品功能會比較少，大部分service的呼叫一樣，少數service不需要呼叫

• 展現，互動會有所區別

 

由於工期較緊，Mobile版本的web-server一般怎麼來呢？

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

• service呼叫的引數有些變化

• 大部分service的呼叫一樣，少數service的呼叫去掉

• 修改展現，互動相關的程式碼

 

業務繼續發展，產品又需要新增APP版本，APP版本和Mobile版本業務邏輯完全相同，唯一的區別是：

• Mobile版本返回html格式的資料，APP版本返回json格式的資料，然後進行本地渲染

 

由於工期較緊，APP版本的web-server一般怎麼來呢？

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

• 把拼裝html資料的程式碼，修改為拼裝json資料

這麼迭代，演化，發展，架構會變成這個樣子：

• 端，是PC，Mobile，APP

• web-server接入，是PC站，M站，APP站

• 服務層，通用的業務服務，以及基礎資料服務

 

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

• 端到web-server之間連線關係很清晰

• web-server與service之間的連線關係變成了蜘蛛網

 

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

• 一旦一個服務RPC介面有稍許變化，所有web-server系統都需要升級修改

• web-server之間存在大量程式碼拷貝

• 一旦拷貝程式碼，出現一個bug，多個子系統都需要升級修改

 

如何讓資料的獲取更加高效快捷，如何讓資料生產與資料展現解耦分離呢？

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

通過前後端分離分層抽象：

• 站點展示層，node.js，負責資料的展現與互動，由FE維護

• 站點資料層，web-server，負責業務邏輯與json資料介面的提供，由Java工程師維護

 

這樣的好處是：

• 複雜的業務邏輯與資料生成，只有在站點資料層處寫了一次，沒有程式碼拷貝

• 底層service介面發生變化，只有站點資料層一處需要升級修改

• 底層service如果有bug，只有站點資料層一處需要升級修改

• 站點展現層可以根據產品的不同形態，傳入不同的引數，呼叫不同的站點資料層介面

 

除此之外：

• 產品追求絢麗的效果，並對裝置相容性要求高，不再困擾Java工程師，由更專業的FE對接

• 一點點展現的改動，不再需要Java工程師們重新編譯，打包，上線，重啟tomcat

• 約定好json介面後，Java和FE分開開發，FE可以用mock的介面自測，不再等待一起聯調

 

結論：

當業務越來越複雜，端上的產品越來越多，展現層的變化越來越快越來越多，站點層存在大量程式碼拷貝，資料獲取複雜性成為通用痛點的時候，就應該進行前後端分離分層抽象，簡化資料獲取過程，提高資料獲取效率，向上遊遮蔽底層的複雜性。

 

最後再強調兩點：

• 是否需要前後端分離，和業務複雜性，以及業務發展階段有關，不可一概而論

• 本文強調的前後端分離的思路，實際情況下有多種實現方式，文章並沒有透徹展開實現細節

 

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

思路比細節重要。

閱讀前序文章，“分層架構設計”的背景與來龍去脈更加清晰：

• 《網際網路分層架構的本質》

• 《分層架構設計，基礎資料服務分層》

• 《分層架構設計，通用業務服務分層》