十年老樹發新芽-前後端分離實踐
最早從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元件進行通訊，定製化程度較高。
- React意味著全域性替換，替換成本過高，成果成型慢
- Jsx、Ts對偏後臺同學而言，學習門檻較高
- 在國內Vue顯然更受歡迎，文件、社群也更活躍
- React許可協議的具有潛在的不可控性
實際開發遇到的問題
1.與jQuery元件通訊：龐大的現有元件，短時間內非常難Vue化改造。必須採用hack的方式完成jQuery元件和Vue業務的通訊。最終是選擇釋出訂閱模式，收集元件的變更。如果Vue需要知道jQuery元件的變更，jQuery元件需要顯式$emit通知到Vue。
2.狀態管理：狀態管理的加入，會增加開發門檻，使用不恰當也會導致亂用。但如果後續引入，又會增加回爐再造的成本。其次不引入狀態管理，全域性變數的處理也是問題。
3.樣式的規範管理：前端的樣式規範，也是需要改造的痛點。最終選用業界使用較成熟的BEM規範。
後端方案選型
這些年後端的發展與前端相比，就顯得小巫見大巫了。後端現有程式碼量更大，如果僅僅為了PHP的名稱空間、自動載入、依賴注入，就去更換框架就有些得不償失了。現有的框架效能、類的載入、路由、關係物件對映模型，已經有較好的方案來支撐。
前後端分離對後端而言，最大的改造點，在於接入層的處理，即資料的輸入輸出方式。對介面而言，效能對前後端分離的體驗至關重要，也是我們重點考慮的問題，我們加入了HTTP協議層的快取。在程式碼規範、log管理、安全校驗（引數過濾）、業務安全（越權）、頻率限制、簽名驗證、登陸驗證等問題，也在框架層面做了完善和加強。最後基於前後端分離流程的完善，我們使用Apidoc作為介面文件的管理工具。
後續的工作
前端
- 開發規範：Js程式碼規範、CSS規範、元件規範，自動檢測工具支撐。
- 程式碼結構：檔案結構劃分。
- 測試支撐：UI自動化測試、前端構建測試。
- 運維監控：前端日誌上報、前端錯誤監控、優化分析。
- 運營支撐：點選流、訪問轉化分析。
- 開發除錯：開發除錯工具的完善。
- 運維部署：灰度引入、前端釋出流程及工具完善。
後端
- 業務介面效能和安全：隨著業務改造，新介面的效能及伴隨的業務安全。
- 共用邏輯的拆分和複用：和現有模式的程式碼複用和拆分，服務層的完善。
一些觀點
- 沒有工具支撐的規範，抵不過人的惰性。
- 動態優化的方法論。改造之前想想兩年後你期望專案長什麼樣，反過來推導現在應該怎麼做。
- 理解業務是重點，任何框架都會被時代拋棄，選擇最適合業務的。
- 系統性思維，無論前端還是後端，都具等同性。
- 開發流程始終圍繞：程式碼管理、開發除錯、程式碼編譯、專案構建、模組管理、配置部署、測試支撐、效能檢測、安全掃描、規範約束、統計分析、運營支撐。
- 開發指標：可用性、可靠性、可維護性、安全性。