先後端分離項目實踐分析

時間 2019-11-10

標籤後端分離項目實踐分析简体版

原文原文鏈接

1、前言

對nodejs有了些準備，但願多瞭解些後端知識，恰逢公司項目調整，分析了先後端分離的優劣，也作了一個完整的demo演示，同事都以爲靠譜，用了兩個版本的時間，將公司主站項目用nodejs實現了先後端分離，在此和你們分享下，以求共同進步。案例參見 http://www.upopen.cn

2、爲什麼作分離

一、開發體系：架構體系決定了後端重於前端，前端作好靜態頁後，要轉爲php或vm等，開發要用eclipce等後端環境工做，一大堆讓前端迷糊的配置，一旦java人員更新了錯誤的文件，會致使全部人的環境啓動不了，一籌莫展，只能等待救援。javascript
二、難維護：頁面老是會有php\jsp等非前端代碼，相互干擾、沒法優化，時間越久問題越突出。php
三、先後端職責不清晰。css
有人會問，分離爲何不所有走ajax，頁面就不須要任何服務端語言了。但實際場景並不是如此，首先有些數據老是要生成頁面時就已經同步獲取的，且全異步對SEO不利、純html頁面沒有include功能等。
網上還有其它的理解，大體相同就不列舉了。html

3、如何作分離

一、產品設計肯定後，先後端人員共同制定開發接口，爲方便接口的制定、顯示、測試，使用nodejs+mongodb開發了接口平臺。參見http://www.upopen.cn:8090/interface/index
功能：制定接口時就直接在interface平臺上新增錄入ActionName、description、 method、 param 及默認值等並保存到mongodb，當後臺開發完成後，直接用在該頁面作接口測試，成功後方可交付，避免聯調過程當中的接口反覆。（本來想用interface.upopen.cn 來測試同域名下的項目，但因cookie在不一樣二級域名下沒法共享的問題，暫用了二級目錄，不過已有方案，後續優化）前端
二、從前端角度考慮系統架構圖以下：java
先後端分離架構圖node

訪問入口 NGINX 代理靜態資源到 STATIC 服務器，其它請求則到 NODEJS。mysql
頁面請求NODEJS直接render，數據相關NODEJS則作預處理，再發到後臺linux
前端據已定義的接口，經過nodejs+mysql模擬後臺完成數據存取，此處會增長些工做量，但只是爲了走通業務流程，模擬後臺數據表定義及邏輯無需嚴謹，只要能正常存取便可，如註冊用戶save to DB，登陸驗證read from DB，因此提供模式化的工具、寫法後，新增表、接口，並不會多耗時間，nginx – nodejs – 模擬後臺，便可按實際使用完成全部前端工做。nginx
QA單獨測前端時，修改hostIP指向到測試工具。
Java開發完成後接口，在 Interface平臺上驗證全部接口，確認無誤。QA也能夠經過Interface測試Java接口
nodejs修改config裏的hostIP配置到java，理想狀況下，修改此步配置即完成聯調
每一個模塊的簡略部署以下：

javascriptNginx.conf：
     Location ~ \.(jpg|png|css|js ){ //靜態資源代理
          Root /root/static/;
     }
     Location \{ //其它接口轉發
     Proxy_pass http://upopen.cn;
}
…
Upsteam upopen.cn{
     Server http://node.upopen.cn;
}

STATIC 結構以下：使用require.js作模塊化加載工具，有朋友問爲何不用seajs，還問這兩個優劣，其實前兩年的項目用的都是seajs，此處想試試amd vs cmd，因此就用了require.js ，以目前的使用來看，相互可替代

javascriptCore：[核心模塊，主要是引入第三方必用、穩定模塊]
     Base.js [自定義通用函數]
     Require.js
     Jquery.js
     Bootstrap.js
     Backgone.js
     Socket.io.js
     I18n.js
     …
Public: [業務級公共模塊]
     Validate.js [表單驗證模塊]
     All.js [全部頁面須要執行的業務js，如登陸驗證]
     Zhdoc.js [國際化文本定義]
     Reset.css [樣式初始化]
     common.css
     …
Widget: [自定義組件]
     Dialog: [彈框組件]
          Dialog.js
          Dislog.css
          Imgs: [彈框組件圖片]
     Calendar:[日誌組件]
          Calendar.js
          Calendar.css
          Imgs: [日曆組件圖片]
     …
Module: [業務模塊]
     Issue: [靜態模塊]
          Index: [首頁]
               Index.js
               Index.css
               Imgs:
          news: [新聞]
               news.js
               news.css
               imgs:
          …
     User: [用戶模塊]
          Register: [註冊]
               Register.js
               Register.css
               Imgs:
          findPwd: [找回密碼]
               findPwd.js
               findPwd.css
               imgs:
          …

Nodejs結構主要以下： express 框架

javascript
     App.js
     Package.json
     Node_modules:
     Routes:
          Index.js – 路由入口，接收全部請求作轉發，並作權限過濾、404等
          Issue.js – 接收來自index.js的靜態請求
          User.js - 接收來自index.js的用戶請求，頁面請求render，數據請求轉發
          …
     Views: [使用ejs框架，接收來自 routes 裏的頁面請求]
          Common: [公用模塊頁]
               Header.ejs
               Footer.ejs
               …
          Issue: [靜態模塊頁]
               Index.ejs
               News.ejs
               …
          User: [用戶模塊頁]
               Register.ejs
               findPwd.ejs
               …
          Controls: [業務邏輯模塊]
               Config.js –公共配置模塊，如hostIP、basePath等，切換環境修改此配置
               User.js - 接收來自 route/user.js的數據請求，向外轉發作邏輯準備
               Tool.js - 封裝經常使用函數如http.request/mailer/md5等
               Redis.js - redis封裝，對於單體封裝內容比較多的模塊，單獨成立一個文件
               …
          Log: [日誌，採用Log4js，日誌是必須的，頁面開發者常欠缺日誌理念]
         Assets: 結構、使用同 STATIC，不配置nginx時，調用此處資源，意義不大
         …
Nodejs + MySql: [模擬後臺模塊，相對上面的模塊，主要多了DB]
     Db: [數據處理模塊]
          Mysql.js – 封裝模式化數據存儲接口，提供最便捷的新增表、接口的方法

按此結構完成前端全部功能，因目前項目較小，部分模塊還有細分空間。

4、分離結果如何

一、開發效率更高，在聯調以前，互不干擾，前端開發完成後就是實際可用的代碼，不須要再轉換成後臺編譯環境，永遠不會被java / php 啓動不成功所困擾。
二、部分須要先後端共同開發的功能，如文件上傳，一般須要頁面端與接收端都進行相關的開發配置，以前較難定位是誰配置錯誤，如今所有由前端完成，開發、測試都容易定位，上傳成功後，只要向java發送文件保存的路徑便可。
三、徹底分清了先後端開發人員的職責，任一方開發完成後均可以提測，實現同步開發、測試。
四、聯調很是簡單，若雙方接口一致，正常狀況下只要修改要接口請求IP便可完成切換。
五、問題責任清晰，聯調、測試、預發、上線，每一個過程都不免會產生問題，前端、後端、運維三方責任邊界清晰，日誌中記錄nodejs的請求發出，nginx請求接收與轉發、java端請求接收與返回，三處任何一處斷點，都能立刻定位是哪方的問題。
六、前端人員有更高的權限，頁面端的展現幾乎全由前端實現，但以前一些配置卻受制於後臺，好比常見的模板功能，純html頁面雖能夠經過angularjs實現模板，但實際效果卻並不理想，網速差時常常會出現include部分顯示後置、甚至加載不成功的狀況，nodejs的ejs框架能夠很好的實現這個功能。
另外，據瀏覽器加載不一樣的css以便實現瀏覽器兼容，以前處理一般是頁面加載後，經過js判斷瀏覽器類型，再去加載不一樣的css文件，影響渲染效率，而且js判斷瀏覽器類型自己就存在兼容問題，用nodejs則能夠在render前就完成該判斷，直接用相應的瀏覽器樣式作渲染
七、代碼複用，驗證模塊，頁面端與nodejs端能夠直接複用

5、注意事項：

一、前端開發人員不只須要有紮實的nodejs知識，還要有必定的服務端、運維知識，對http通訊有更深層次的理解，nginx、redis、socket、buffer等技術也要掌握，多多益善。
二、開發之初對功能充分、寬裕的評估，使用初期不要用nodejs過多開發新功能。初次使用，不免會遇到不少意想不一樣的問題，前端開發人員自己對服務端知識有限，java人員又對nodejs語法不熟，若處理很差會致使項目延期。我本來認爲redis同memcached同樣就是connect + set + get，但實際開發時遇到一些考慮不周而產生的怪異問題，延長該部分開發時間，最終致使項目delay。
三、前端開發人員可嘗試用linux系統開發，初版用win7開發時，npm部分模塊的安裝會不順利，如node-canvas在win7上安裝須要6步，而本來在32上已配置成功了，在64位上的系統上又不成功，後來該接口暫由java實現。實際上即便配置成功了，該模塊在發佈服務器的linux系統上也沒法使用，須要從新安裝。第二版開發時，我使用了ubuntu，雖然有必定的學習成本，但對後期的效率提高十分有益，多學習一種系統操做，和運維調試時也更加主動。不過ubuntu下沒有找到作PSD切圖的工具，因此安裝雙系統更合適切換使用。