Javaweb項目開發的先後端解耦的必要性

JavaWeb項目爲什麼咱們要放棄jsp？爲什麼要先後端解耦？爲什麼要動靜分離？

 

使用jsp的痛點：

1.jsp上動態資源和靜態資源所有耦合在一塊兒，服務器壓力大，由於服務器會收到各類靜態資源的http請求，動態代碼的等等，除非你使用nginx。

萬一你的java代碼出現了bug，你的頁面是顯示不出來的，直接蹦到了5xx頁面，用戶體驗極差。

(如今javaWeb項目業界的標準是nginx+tomcat，動靜分離，請求先到nginx，全部的靜態資源請求所有交給nginx，動態資源所有給tomcat，此外nginx還能夠玩負載均衡。ps：即便你依然使用jsp，也能夠這麼玩的，nginx聽說單實例http併發高達5w，這個優點要用上，tomcat的各類參數優化完http併發能上2000？還有不要把tomcat暴露給外網，一旦被黑客破解了以後，你配置文件裏全部的信息，以及你的代碼都會玩完，class文件怎麼了？class文件能夠反編譯，把nginx暴露給外網，只開放80和443端口，nginx調用tomcat所有都是內網ip，及時被黑客破解，他能拿到的也是一些靜態資源，你是安全的。)

2.前端工程師作好html後，須要由後端的java工程師來將html修改爲jsp頁面，包括各類文件的路徑，出錯率較高（由於頁面中常常會出現大量的js代碼），

頁面中耦合了標籤，java表達式，js代碼，html代碼，特別亂，修改問題時須要雙方協同開發，效率低下。

3.jsp必需要在支持java的web服務器裏運行（例如tomcat/resin/jboss/weblogic等），性能提不上來。

4.第一次請求jsp，必需要在web服務器中編譯成servlet，第一次運行會較慢。

5.每次請求jsp都是訪問servlet再用輸出流輸出的html頁面，效率沒有直接使用html高（記住是每次喲~~~內存喲，IO喲）。

6.若是在生產環境中，發現了前端的bug，讓前端工程師來調試bug，這個時候的頁面已經很混亂了，呵呵，他會遇到不少痛點。

7.若是jsp中的內容不少，頁面響應會很慢，由於是同步加載。

---------------------------------------------------

基於上述的一些痛點，咱們應該把整個項目的開發權重往前移，實現先後端真正的解耦！

之前後端java程序猿的權重很大，什麼UI，前端，都只是附屬，如今須要改變。

前端不只僅是css，js那麼簡單，前端在使用了一些框架和工具以後，是能夠變成前端項目的，在項目層面拆開，前端也須要有MVC框架，也須要編譯，打包，部署，是很複雜的，越是大型互聯網公司，前端項目越是工程化的項目，包括前端項目的版本管理，運維，水都是很深的。這就是我在開篇中說的，術業有專攻！

你要玩，就要玩到極致，要不就別玩！

---------------------------------------------------



之前老的方式是：

1.客戶端請求
2.服務端的servlet或controller接收請求（路由規則由後端制定，整個項目開發的權重大部分在後端）
3.調用service,dao代碼完成業務邏輯
4.返回jsp
5.jsp展示一些動態的代碼

新的方式是：

1.瀏覽器發送請求
2.直接到達html頁面（路由規則由前端制定，整個項目開發的權重前移）
3.html頁面負責調用服務端接口產生數據（經過ajax等等，後臺返回json格式數據）
4.填充html，展示動態效果，在頁面上進行解析並操做DOM。

（有興趣的童鞋能夠訪問一下阿里巴巴等大型網站，而後按一下F12，監控一下你刷新一次頁面，他的http是怎麼玩的，若是是像首頁這種頁面就是純的html，若是是其餘的動態頁面，大多數是單獨請求後臺數據，使用json傳輸數據，而不是一個大而全的http請求把整個頁面包括動+靜所有返回過來。

之前有人跟我提過，能夠將jsp作動態頁面靜態化，能夠呀，你的數據庫裏有1000w條數據，你靜態化1000w個html嗎？請問您這1000w個html放在哪裏？無論放在哪裏，都是問題。還有若是頁面變動了，怎麼辦？從新再生成1000w個html頁面嗎？？？

能夠考慮一個html頁面而後調用後端接口，熱點數據查詢的時候直接使用分佈式緩存，不走數據庫了。之後你的項目玩大了，都是基於雲的架構，這塊水太深了，我也正在學習中，數據庫是有性能瓶頸的，由於有事務，有鎖，有鏈接數等等。）

總結一下新的方式的請求步驟：

大量併發瀏覽器請求--->web服務器集羣(nginx)--->應用服務器集羣(tomcat)--->文件/數據庫/緩存/消息隊列服務器集羣

同時又能夠玩分模塊，還能夠按業務拆成一個個的小集羣，把核心的業務封裝成一個業務中心，玩遠程業務調用，玩rpc，玩soa，使用springboot+docker玩微服務，這樣纔是一個彈性的分佈式架構。

---------------------------------------------------

這樣作的好處是：

1.能夠實現真正的先後端解耦，前端服務器使用nginx。

前端服務器放的是css，js，圖片等等一系列靜態資源（甚至你還能夠css，js，圖片等資源放到特定的文件服務器，例如阿里雲的oss，並使用cdn加速），前端服務器負責控制頁面引用，跳轉，調用後端的接口，後端服務器使用tomcat（把tomcat想象成一個數據提供者，這裏也叫應用服務器），加快總體響應速度。

（這裏須要使用一些前端工程化的框架好比nodejs，react，router，react，redux，webpack）

2.發現bug，能夠快速定位是誰的問題，不會出現互相踢皮球的現象。

頁面邏輯，跳轉錯誤，瀏覽器兼容性問題，腳本錯誤，頁面樣式等問題，所有由前端工程師來負責。

接口數據出錯，數據沒有提交成功，應答超時等問題，所有由後端工程師來解決。

雙方互不干擾，前端與後端是相親相愛的一家人。

3.在大併發狀況下，我能夠同時水平擴展先後端服務器，好比淘寶的一個首頁就須要2000+臺前端服務器作集羣來抗住日均多少億+的日均pv。

（去參加阿里的技術峯會，聽他們說他們的web容器都是本身寫的，就算他單實例抗10萬http併發，2000臺是2億http併發，你沒有看錯，確實是併發http，而且他們還能夠根據大數據來預知洪峯來無限拓展，他們的大數據都是實時採集，實時分析以及使用的，正所謂由IT時代變爲DT時代，很恐怖，就一個首頁。。。）

4.減小後端服務器的併發壓力，除了接口之外的其餘全部http請求所有轉移到前端nginx上。

5.即便後端服務暫時超時或者宕機了，前端頁面也會正常訪問，只不過數據刷不出來而已。

6.也許你也須要有微信相關的輕應用，那樣你的接口徹底能夠共用，若是也有app相關的服務，那麼只要經過一些代碼重構，也能夠大量複用接口，提高效率。

7.頁面顯示的東西再多也不怕，由於是異步加載。

---------------------------------------------------

注意：

1.在開需求會議的時候，先後端工程師必須所有參加，而且須要制定好接口文檔，後端工程師要寫好測試用例，不要讓前端工程師充當你的組專職測試，推薦使用

chrome的插件postman，service層的測試用例拿junit寫。

2.上述的接口並非java裏的interface，說白了調用接口就是調用你controler裏的方法。

3.加劇了前端團隊的工做量，減輕了後端團隊的工做量，提升了性能和可擴展性，可維護性。

4.咱們須要一些前端的框架來解決相似於頁面嵌套，分頁，頁面跳轉控制等功能。（上面提到的那些前端框架）。

5.若是你的項目很小，或者是一個單純的內網項目，那你大可放心，不用任何架構而言，可是若是你的項目是外網項目，呵呵噠。

6.之前還有人在使用相似於velocity/freemarker等模板框架來生成靜態頁面，如今這種作法也被淘汰掉了。

7.這篇文章主要的目的是說jsp在大型外網java web項目中被淘汰掉，可沒說jsp能夠徹底不學，對於一些學生朋友來講，jsp/servlet等相關的java web基礎仍是要掌握牢的，否則你覺得springmvc這種框架是基於什麼來寫的？

8.若是頁面上有一些權限等等相關的校驗，那麼這些相關的數據也能夠經過ajax從接口裏拿。