通用業務服務化之後，系統的典型後端結構如上：
- 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的接口自測，不再等待一起聯調
結論：
當業務越來越複雜，端上的產品越來越多，展現層的變化越來越快越來越多，站點層存在大量代碼拷貝，數據獲取複雜性成為通用痛點的時候，就應該進行前後端分離分層抽象，簡化數據獲取過程，提高數據獲取效率，向上遊屏蔽底層的複雜性。
最後再強調兩點：
- 是否需要前後端分離，和業務複雜性，以及業務發展階段有關，不可一概而論
- 本文強調的前後端分離的思路，實際情況下有多種實現方式，文章並沒有透徹展開實現細節
任何脫離業務的架構設計，都是耍流氓。
思路比細節重要。
-----------------------------------------------------------------------------
閱讀更多 程序員界的彭于晏 的文章
