1. 程式人生 > >網際網路分層架構系列之四:前後端為什麼要分離

網際網路分層架構系列之四:前後端為什麼要分離


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

  • 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的介面自測,不再等待一起聯調

結論

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

最後再強調兩點:

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

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

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

思路比細節重要

From: https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651960501&idx=1&sn=a452bab31c0457063241df237f955332&chksm=bd2d01698a5a887f9dfa5c6966d9e71bf492a040ab2dbe4e469ef38dd8ee5ab00b7c562a88e8&scene=21#wechat_redirect