前後端分離專案實踐分析

一、前言

• 對nodejs有了些準備，希望多瞭解些後端知識，恰逢公司專案調整，分析了前後端分離的優劣，也做了一個完整的demo演示，同事都覺得靠譜，用了兩個版本的時間，將公司主站專案用nodejs實現了前後端分離，在此和大家分享下，以求共同進步。案例參見 http://www.upopen.cn

二、為何做分離

• 1、開發體系：架構體系決定了後端重於前端，前端做好靜態頁後，要轉為php或vm等，開發要用eclipce等後端環境工作，一大堆讓前端迷糊的配置，一旦java人員更新了錯誤的檔案，會導致所有人的環境啟動不了，束手無策，只能等待救援。
• 2、難維護：頁面總是會有php\jsp等非前端程式碼，相互干擾、無法優化，時間越久問題越突出。
• 3、前後端職責不清晰。
• 有人會問，分離為什麼不全部走ajax，頁面就不需要任何服務端語言了。但實際場景並非如此，首先有些資料總是要生成頁面時就已經同步獲取的，且全非同步對SEO不利、純html頁面沒有include功能等。
  網上還有其它的理解，大致相同就不列舉了。

三、如何做分離

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

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

• STATIC 結構如下：使用require.js做模組化載入工具，有朋友問為什麼不用seajs，還問這兩個優劣，其實前兩年的專案用的都是seajs，此處想試試amd vs cmd，所以就用了require.js ，以目前的使用來看，相互可替代

• 按此結構完成前端所有功能，因目前專案較小，部分模組還有細分空間。

四、分離結果如何

• 1、開發效率更高，在聯調之前，互不干擾，前端開發完成後就是實際可用的程式碼，不需要再轉換成後臺編譯環境，永遠不會被java / php 啟動不成功所困擾。
• 2、部分需要前後端共同開發的功能，如檔案上傳，通常需要頁面端與接收端都進行相關的開發配置，之前較難定位是誰配置錯誤，現在全部由前端完成，開發、測試都容易定位，上傳成功後，只要向java傳送檔案儲存的路徑即可。
• 3、完全分清了前後端開發人員的職責，任一方開發完成後都可以提測，實現同步開發、測試。
• 4、聯調非常簡單，若雙方介面一致，正常情況下只要修改要介面請求IP即可完成切換。
• 5、問題責任清晰，聯調、測試、預發、上線，每個過程都難免會產生問題，前端、後端、運維三方責任邊界清晰，日誌中記錄nodejs的請求發出，nginx請求接收與轉發、java端請求接收與返回，三處任何一處斷點，都能馬上定位是哪方的問題。
• 6、前端人員有更高的許可權，頁面端的展示幾乎全由前端實現，但之前一些配置卻受制於後臺，比如常見的模板功能，純html頁面雖可以通過angularjs實現模板，但實際效果卻並不理想，網速差時經常會出現include部分顯示後置、甚至載入不成功的情況，nodejs的ejs框架可以很好的實現這個功能。
• 另外，據瀏覽器載入不同的css以便實現瀏覽器相容，之前處理通常是頁面載入後，通過js判斷瀏覽器型別，再去載入不同的css檔案，影響渲染效率，並且js判斷瀏覽器型別本身就存在相容問題，用nodejs則可以在render前就完成該判斷，直接用相應的瀏覽器樣式做渲染
• 7、程式碼複用，驗證模組，頁面端與nodejs端可以直接複用

五、注意事項：

• 1、前端開發人員不僅需要有紮實的nodejs知識，還要有一定的服務端、運維知識，對http通訊有更深層次的理解，nginx、redis、socket、buffer等技術也要掌握，多多益善。
• 2、開發之初對功能充分、寬裕的評估，使用初期不要用nodejs過多開發新功能。初次使用，難免會遇到很多意想不同的問題，前端開發人員本身對服務端知識有限，java人員又對nodejs語法不熟，若處理不好會導致專案延期。我原本認為redis同memcached一樣就是connect + set + get，但實際開發時遇到一些考慮不周而產生的怪異問題，延長該部分開發時間，最終導致專案delay。
• 3、前端開發人員可嘗試用linux系統開發，第一版用win7開發時，npm部分模組的安裝會不順利，如node-canvas在win7上安裝需要6步，而原本在32上已配置成功了，在64位上的系統上又不成功，後來該介面暫由java實現。實際上即使配置成功了，該模組在釋出伺服器的linux系統上也無法使用，需要重新安裝。第二版開發時，我使用了ubuntu，雖然有一定的學習成本，但對後期的效率提升十分有益，多學習一種系統操作，和運維除錯時也更加主動。不過ubuntu下沒有找到做PSD切圖的工具，所以安裝雙系統更合適切換使用。

六、總結：

• 目前用分離方式做了兩版專案，開發效率提升、協作溝通便捷上有明顯優勢，作為前端也學習了很多新知識、擴大影響範圍，是共贏的。目前使用還較初級，要繼續學習、探索。在此貼出以便和同仁共進步之。