1. 程式人生 > >轉《淺談架構之路:前後端分離模式》

轉《淺談架構之路:前後端分離模式》

原文連結:https://www.cnblogs.com/shanrengo/p/6397734.html

前言:分離模式

  對前後端分離研究了一段時間,恰逢公司有一個大專案決定嘗試使用前後端分離模式進行,便參與其中。該專案從2016年初立項至今,平平穩穩得度過,但也湧現出越來越多的問題,絕對不是說前後端分離模式不好,而是很多公司在嘗試前後端分離的時候沒有做好充分得準備。

  網上對前後端分離介紹的文章已經屢見不鮮,接下來本人用一點粗淺的言語也談談這塊,獻醜了。

為什麼要分離?

  如果只問“前後端分離的意義大麼?”這是廢話,因為從軟體架構的角度 Web 的前後端從一開始不就一直是分離的麼,而且 browser、server 可能將永遠分離下去。

  為了瞭解這個問題,我們有必要先了解一下 Web的研發模式演變,關於這個題材,下面這篇博文說得不錯,這邊就不做搬運工了。

  我們不能“為了分離而分離”,而應該“為了真正理解web開發、為了更好完成需求而分離”。

前後端分離的誤區?

  1、前端人員配備是否充足?

  由於所在公司以往專案採用傳統開發風格,即以後端MVC為主的開發模式,前端人員僅僅提供靜態html頁面,其餘工作皆由後端開發人員完成。採用前後端分離模式可以減臺負擔,加快研發效率,當然,前提是前端能做好的話。以往只需要提供靜態頁面的前端人員,在前後端分離模式中要負責專案的view+controller部分,即除了靜態頁面,還需要負責頁面的所有互動程式碼、以及nodejs與檢視層以及後端API的互動工作,無疑增加了前端人員的學習成本,在沒有足夠知識和人才儲備的情況下,只能讓前端人員加班加點。

結果是大量前端人員離職(PS:做這麼多事,工資總得加吧!)

  2、前後端職責分配?

  很多公司認為採用前後端分離之後,前後端只需要通過指定API進行互動即可,前端負責頁面渲染,Nodejs負責路由分配,後端提供API。忽視了大量關鍵工作,職責分配和細節處理沒有相應文件規定,快取機制、圖片上傳下載、資料校驗、語言國際化等等並沒有出具相應資訊。另外,大量忽視了nodejs層的作用,僅僅把nodejs當成一個路由中轉,這一方面也是對nodejs技術的不熟悉導致的,其實nodejs能負責很多事,除了複雜業務邏輯處理和資料操作由Java 負責,大量工作完全可以在nodejs層處理。(PS:還是基礎不夠導致的!)

  3、後端API是否Restful風格?

  很多公司採用了前後端分離模式後,後端API仍然採用以往的傳統風格,這是不合理的,Restful風格的API應該是前後端分離的最佳實踐。ResultFul推薦每個URL能操作具體的資源,而且能準確描述伺服器對資源的處理動作,通常伺服器對資源支援get/post/put/delete/等,用來實現資源的增刪改查。前後端分離的話,這些api-url是對接的橋樑,採用resultFul介面地址含義才更清晰、見名知意。(PS:用了Spring4.x 竟然還不用rest風格,說不過去啊)

  4、前後端協作模式?

  前後端分離後,無論是API介面的對接還是測試工作,都涉及到前後端人員的溝通,很多公司採用前後端分離後,前後端協作模式配合力度底,互相等待,開發效率低下,反而不如傳統的開發模式。例如:當後端 API 沒有編寫完成時,前端無法進行除錯,這就導致了前端會被後端阻塞的情況。其實像這種互相等待的模式需要改進, Mock Server 可能可以解決一些問題。

如何前後端分離?

  怎麼做前後端分離?大方向就是

  後端專注於:後端控制層(Restful API) & 服務層 & 資料訪問層;

  前端專注於:前端控制層(Nodejs) & 檢視層

  本人認為的前後端分離模式應該是這樣,當然這不一定正確:

  1、專案設計階段,前後端架構負責人將專案整體進行分析,討論並確定API風格、職責分配、開發協助模式,確定人員配備;設計確定後,前後端人員共同制定開發介面。

  2、專案開發階段,前後端分離是各自分工,協同敏捷開發,後端提供Restful API,並給出詳細文件說明,前端人員進行頁面渲染前臺的任務是傳送API請(GET,PUT,POST,DELETE等)獲取資料(json,xml)後渲染頁面。

  3、專案測試階段,API完成之前,前端人員會使用mock server進行模擬測試,後端人員採用junit進行API單元測試,不用互相等待;API完成之後,前後端再對接測試一下就可以了,當然並不是所有的介面都可以提前定義,有一些是在開發過程中進行調整的。

  4、專案部署階段,利用nginx 做反向代理,即Java + nodejs + nginx 方式進行。

編後語

  從經典的JSP+Servlet+JavaBean的MVC時代,到SSM(Spring + SpringMVC + Mybatis)和SSH(Spring + Struts + Hibernate)的Java 框架時代,再到前端框架(KnockoutJS、AngularJS、vueJS、ReactJS)為主的MV*時代,然後是Nodejs引領的全棧時代,技術和架構一直都在進步。雖然“基於NodeJS的全棧式開發”模式很讓人興奮,但是把基於Node的全棧開發變成一個穩定,讓大家都能接受的東西還有很多路要走。創新之路不會止步,無論是前後端分離模式還是其他模式,都是為了更方便得解決需求,但它們都只是一個“中轉站”。

  走過的“中轉站”可能越來越多,但是不要漸行漸遠才是。