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

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

• 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的接口自測，再也不等待一塊兒聯調

結論：

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

最後再強調兩點：

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

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

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

思路比細節重要。