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

• 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版本大部分業務邏輯都一樣，唯一的區別是屏幕比較?。?/p>

• 信息展現的條數會比較少，即調用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/H***PP的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的接口自測，不再等待一起聯調

結論：

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

***再強調兩點：

• 是否需要前后端分離，和業務復雜性，以及業務發展階段有關，不可一概而論
• 本文強調的前后端分離的思路，實際情況下有多種實現方式，文章并沒有透徹展開實現細節

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

思路比細節重要。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

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