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從接口裏拿。

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