java web項目爲何咱們要放棄jsp？

轉載自：https://www.cnblogs.com/xuange306/p/6823479.html

前戲：

 

之前的項目大多數都是java程序猿又當爹又當媽，又搞前端（ajax/jquery/js/html/css等等），又搞後端（java/mysql/Oracle等等）。

隨着時代的發展，漸漸的許多大中小公司開始把先後端的界限分的愈來愈明確，前端工程師只管前端的事情，後端工程師只管後端的事情，正所謂術業有專攻，一我的若是什麼都會，那麼他畢竟什麼都不精。

 

大中型公司須要專業人才，小公司須要全才，可是對於我的職業發展來講，我建議是分開。你要是這輩子就吃java這碗飯，就不要去研究什麼css，js等等。

把你的精力專一在java，jvm原理，spring原理，mysql鎖，事務，多線程，大併發，分佈式架構，微服務，以及相關的項目管理等等，這樣你的核心競爭力纔會愈來愈高，正所謂你往生活中投入什麼，生活就會反饋給你什麼。

 

（

滿滿的正能量：

一旦你成爲了一個行業裏的精英，相信我，到時候，車，房，女人，錢，機會就都來找你了，不用着急，真的。

幹java程序猿這行，真的很簡單的，你懂得知識越多，你的錢就越多，固然了還須要有必定的情商。。。

你的能力越強，你就比別人創造的價值更多，你爲公司創造了價值，公司給你各類福利，共贏！

）

 

幾曾什麼時候，咱們的java web項目都是使用了若干後臺框架，springmvc/struts + spring + spring jdbc/hibernate/mybatis 等等

大多數項目在java後端都是分了三層，控制層（controller/action），業務層（service/manage），持久層（dao）。

控制層負責接收參數，調用相關業務層，封裝數據，以及路由到jsp頁面。而後jsp頁面上使用各類標籤（jstl/el）或者手寫java（<%=%>）將後臺的數據展示出來。

 

對吧？

咱們先看這種狀況，需求定完了，代碼寫完了，測試測完了，而後呢？要發佈了吧？

你須要用maven或者eclipse等工具把你的代碼打成一個war包，而後把這個war包發佈到你的生產環境下的web容器（tomcat/jboss/weblogic/websphere/jetty/resin）裏，對吧？

 

發佈完了以後，你要啓動你的web容器，開始提供服務，這時候你經過配置域名，dns等等相關，你的網站就能夠訪問了（假設你是個網站）。

那咱們來看，你的先後端代碼是否是全都在那個war包裏？包括你的js，css，圖片，各類第三方的庫，對吧？

 

好，下面在瀏覽器中輸入你的網站域名（www.xxx.com），以後發生了什麼？（這個問題也是不少公司的面試題）

我撿乾的說了啊，基礎很差的童鞋請本身去搜。

 

瀏覽器在經過ip路由到你的服務，在tcp3次握手以後，經過tcp協議開始訪問你的web服務器，你的web服務器獲得請求後，開始提供服務，接收請求，以後經過response返回你的應答給瀏覽器。

 

那麼咱們來看，咱們先假設你的首頁中有100張圖片，以及一個單表的查詢，此時，用戶的看似一次http請求，其實並非一次，用戶在第一次訪問的時候，瀏覽器中不會有緩存，你的100張圖片，瀏覽器要連着請求100次http請求（有人會跟我說http長鏈短鏈的問題，不在這裏討論），你的web服務器接收這些請求，都須要耗費內存去建立socket來玩tcp傳輸。

 

重點來了，這樣的話，你的web服務器的壓力會很是大，由於頁面中的全部請求都是隻請求到你這臺服務器上，若是1我的還好，若是10000我的併發訪問呢（先不聊web服務器集羣，這裏就說是單實例web服務器），那你的服務器能扛住多少個tcp連接？你的服務器的內存有多大？你能抗住多少IO？你給web服務器分的內存有多大？會不會宕機？

 

這就是爲何，越是大中型的web應用，他們越是要解耦。

理論上你能夠把你的數據庫+應用服務+消息隊列+緩存+用戶上傳的文件+日誌+等等都扔在一臺主機上，可是這樣就好像是你把雞蛋都放在一個籃子裏，隱患很是大。

 

正常的分佈式架構，是都要拆開的，你的應用服務器集羣（前，後）+文件服務器集羣+數據庫服務器集羣+消息隊列集羣+緩存集羣等等。

 

前戲太長了。

下面步入正題，首先之後的java web項目都儘可能要避免使用jsp，要搞先後臺解耦，玩分佈式架構，這樣咱們的應用架構才更強。

 

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

 

使用jsp的痛點：

1.動態資源和靜態資源所有耦合在一塊兒，沒法作到真正的動靜分離。服務器壓力大，由於服務器會收到各類http請求，例如css的http請求，js的，圖片的，動態代碼的等等。一旦服務器出現情況，先後臺一塊兒玩完，用戶體驗極差。

2.前端工程師作好html後，須要由java工程師來將html修改爲jsp頁面，出錯率較高（由於頁面中常常會出現大量的js代碼），修改問題時須要雙方協同開發，效率低下。

 

3.jsp必需要在支持java的web服務器裏運行（例如tomcat等），沒法使用nginx等（nginx聽說單實例http併發高達5w，這個優點要用上），性能提不上來。

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

5.每次請求jsp都是訪問servlet再用輸出流輸出的html頁面，效率沒有直接使用html高。

6.jsp內有較多標籤和表達式，前端工程師在修改頁面時會捉襟見肘，遇到不少痛點。

 

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

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

 

 

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

 

 

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

之前老的方式是：

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

 

 

 

新的方式是：

1.瀏覽器發送請求 2.直接到達html頁面（路由規則由前端制定，整個項目開發的權重前移） 3.html頁面負責調用服務端接口產生數據（經過ajax等等） 4.填充html，展示動態效果。

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

 

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

這樣作的好處是：

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

前端服務器放的是css，js，圖片等等一系列靜態資源（甚至你還能夠css，js，圖片等資源放到特定的文件服務器，例如阿里雲的oss，並使用cdn加速），前端服務器負責控制頁面引用，跳轉，調用後端的接口，後端服務器使用tomcat。

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

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

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

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

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

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

（去參加阿里的技術峯會，聽他們說他們的web容器都是本身寫的，就算他單實例抗10萬http併發，2000臺是2億http併發，而且他們還能夠根據預知洪峯來無限拓展，很恐怖，就一個首頁。。。）

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這種框架是基於什麼來寫的？