老樹發新芽-前後端分離實踐

最早從Web2.0 Ajax技術開始興起,就有提前後端分離了。從Gmail的單頁應用,到現在的單頁應用層出不窮。瀏覽器渲染引擎也一直在突破,越來越多的交互、計算放在了瀏覽器這一層。傳統後端MVC架構,變成了前後端的MVC。後臺的接口變成了模型層,邏輯處理層從CGI變成了JavaScript,展示層則還是標記語言HTML和CSS。

爲什麼要做前後端分離

當前項目從立項到2018年,已經有10餘年的歷史了。前端的技術棧是jQuery。後臺是基於10年前的PHP框架,中間也經歷過多次重構。但總體架構還是LNMP,PHP渲染的,存在的問題比較多。

  • 從維護側看:1)業務邏輯複雜,充斥着很多明眼不可見的業務。導致更改bug很容易引發其他的bug。2)代碼巨長無比,可讀性差。3)代碼結構性差、分層模糊,邏輯層的代碼充斥在View層中。找代碼的時間佔據解決bug的大部分時間。4)前端尚處在刀耕火種的年代,前端規範差、壓縮混淆不徹底,難以適應新的瀏覽器渲染技術。

  • 從性能側看:單一請求,往往讀取比頁面所需要多得多的數據。頻繁的拉取數據,不僅對後端資源是一種浪費,也會導致單一請求耗時過長。

  • 從用戶側看:因爲多頁應用的頻繁刷新,新的URL都需要頁面重載。單一頁面會觸發多個HTTP請求(靜態資源、Ajax)。這兩個因素導致用戶等待時間過久。

  • 從開發人員側看:1)開發者往往熱衷於新技術。學習新技術不僅有利於團隊技術成長,也有利於發揮成員的積極性。2)團隊成員本身具有全棧開發的能力,轉換成前後端分離的模式成本較低。

  • 從業務本身來看:產品天生適合採用單頁應用,無需SEO。

前端方案選型

基於上述原因,促成團隊下定決心進行正式的改造。新的項目,由於沒有歷史包袱,採用開源框架是水到渠成的。但對於已有項目而言,採用新框架意味着要對現有代碼進行徹底重構。結合自身業務來講,自研框架可以完美的兼容現有的前端組件庫。其次,自研對框架細節的把握程度也會更強。

但是從長期來看,自研意味着需要專業人員長期維護。採用自研,對團隊而言是摸着石頭過河。我們需要改造業務,需要兼容現有組件,需要考慮長期的維護性,需要考慮安全和性能,需要考慮前端開發流程,還有新成員的上手程度。最重要的還有改造進度和成本。

在前端方案的落地中,團隊花費了很長時間進行框架的預研,最終選擇了Vue。對業務而言,框架需要提供雙向數據綁定、模版引擎、組件化、前端路由,還有能與jQuery組件進行通信,定製化程度較高。

  1. React意味着全局替換,替換成本過高,成果成型慢
  2. JSX、TS對偏後臺同學而言,學習門檻較高
  3. 在國內Vue顯然更受歡迎,文檔、社區也更活躍
  4. React許可協議的具有潛在的不可控性
  5. 前端同學對Vue理解更深刻

實際開發遇到的問題

1.與jQuery組件通信:龐大的現有組件,短時間內非常難Vue化改造。必須採用hack的方式完成jQuery組件和Vue業務的通信。最終是選擇發佈訂閱模式,收集組件的變更。如果Vue需要知道jQuery組件的變更,jQuery組件需要顯式$emit通知到Vue。

2.狀態管理:狀態管理的加入,會增加開發門檻,使用不恰當也會導致亂用。但如果後續引入,又會增加回爐再造的成本。其次不引入狀態管理,全局變量的處理也是問題。

3.樣式的規範管理:前端的樣式規範,也是需要改造的痛點。最終選用業界使用較成熟的BEM規範。

後端方案選型

這些年後端的發展與前端相比,就顯得小巫見大巫了。後端現有代碼量更大,如果僅僅爲了PHP的命名空間、自動加載、依賴注入,就去更換框架就有些得不償失了。現有的框架性能、類的加載、路由、關係對象映射模型,已經有較好的方案來支撐。

前後端分離對後端而言,最大的改造點,在於接入層的處理,即數據的輸入輸出方式。對接口而言,性能對前後端分離的體驗至關重要,也是我們重點考慮的問題,我們加入了HTTP協議層的緩存。在代碼規範、log管理、安全校驗(參數過濾)、業務安全(越權)、頻率限制、簽名驗證、登陸驗證等問題,也在框架層面做了完善和加強。最後基於前後端分離流程的完善,我們使用Apidoc作爲接口文檔的管理工具。

後續的工作

前端

  1. 開發規範:Js代碼規範、CSS規範、組件規範,自動檢測工具支撐。
  2. 代碼結構:文件結構劃分。
  3. 測試支撐:UI自動化測試、前端構建測試。
  4. 運維監控:前端日誌上報、前端錯誤監控、優化分析。
  5. 運營支撐:點擊流、訪問轉化分析。
  6. 開發調試:開發調試工具的完善。
  7. 運維部署:灰度引入、前端發佈流程及工具完善。

後端

  1. 業務接口性能和安全:隨着業務改造,新接口的性能及伴隨的業務安全。
  2. 共用邏輯的拆分和複用:和現有模式的代碼複用和拆分,服務層的完善。

一些觀點

  1. 沒有工具支撐的規範,抵不過人的惰性。
  2. 動態優化的方法論。改造之前想想兩年後你期望項目長什麼樣,反過來推導現在應該怎麼做。
  3. 理解業務是重點,任何框架都會被時代拋棄,選擇最適合業務的。
  4. 系統性思維,無論前端還是後端,都具等同性。
    • 開發流程:代碼管理、開發調試、代碼編譯、項目構建、模塊管理、配置部署、測試支撐、性能檢測、安全掃描、規範約束、統計分析、運營支撐。
    • 開發指標:可用性、可靠性、可維護性、安全性。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章