整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
源 | 愚公要移山（ID:fdd_sxu_nwpu）
jsp技術作為曾經一度火爆的技術，在最近幾年確實使用率越來越低了，這篇文章帶你一塊探究一下jsp的從生到死。
jsp技術的誕生
在很久很久以前，那時候我們的開發都是通過servlet來完成的，這個servlet是什么呢？我們先來認識一下：
servlet用Java語言編寫的服務器端程序。主要功能是和瀏覽器進行交互，生成頁面展示。
長下面這個樣子：
public class HelloWorld extends HttpServlet {public void doGet(HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException {response.setContentType("text/html");PrintWriter out=response.getWriter;out.println("<html>");out.println("<head>");out.println("<title>Hello World</title>");out.println("</head>");out.println("<body>");out.println("<h1>Hello World!</h1>");out.println("</body>");out.println("</html>");}}
我們可以看到前端所展示的頁面，需要我們servlet去一個標簽一個標簽去生成，如果一個頁面超級復雜，動不動幾千行代碼，那這個servlet效率也就太低了。而且整個servlet代碼也會十分臃腫而且可讀性非常差。
這時候怎么辦呢？sun公司很早就意識到了這個問題，于是便倡導很多公司一塊來創建了一種能夠動態生成html的新技術，不久之后jsp便誕生了。有效率的解決了上面servlet所出現的問題。
jsp的發展
既然jsp技術能夠解決剛剛servlet代碼里面所出現的技術，我們來看一下是如何解決的：在這里我們舉一個小例子，就是前端jsp向服務器servlet發送請求圖書頁面的功能。
首先我們看一下servlet：
public class List_book extends HttpServlet {public void doGet(HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException {//聲明一個ArrayList.用來存放Book類中的數據ArrayList<Book> list=new ArrayList<Book>;for(int i=0;i<10;i++){Book book=new Book;book.setName(res.getString("name"+i));book.setAuthor(res.getString("author"+i));list.add(book);}//將list數據發送到.jap文件中request.getRequestDispatcher("ListBook.jsp").forward(request, response);}}
我們會發現，現在的servlet沒有一點html代碼了。我們只需要把數據交給jsp。此時我們的頁面展示就交給jsp來做了。現在我們來看一下jsp長什么樣子：
<%@ page language="java" import="java.util.*" pageEncoding="utf-8"%><%String path=request.getContextPath;%><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta http-equiv="pragma" content="no-cache"><meta http-equiv="description" content="This is my page"><script></script></head><body><% ArrayList list=(ArrayList) request.getAttribute("list"); %><h2 align="center">圖書列表</h2><table border=1px align="center"><tr><th>圖書名稱</th><th>圖書作者</th></tr><!-- 繼續使用jsp語句 循環放入存放于list中的Book實體類中的數據 --><%for(int i=0;i<list.size;i++){Book book=(Book)list.get(i);%><tr><th><%=book.getName %></th><th><%=book.getAuthor%></th><tr>}%></table></body></html>
這就是jsp，我們可以在html頁面中寫一些java代碼。對于我們程序員來說，在開發當中靜態的頁面我們只需要用html和css寫一些標簽來展示即可，對于那些動態的部分我們就可以使用java代碼。
那么jsp和servlet是不是就是這種協作的關系，本質上有什么區別呢？
其實jsp只是servlet的一種特殊形式，每一個jsp頁面就是一個servlet實例，通俗一點的話來說：jsp就是servlet，只不過servlet把一些業務功能剝離開來交給了或者是形成了jsp。明白了吧。在我們的項目編譯的時候就是把jsp編譯成了servlet。
你們會發現，這樣做其實挺好的，市場也驗證了一切，很快jsp技術流行開來，可是隨著時間的流逝，業務越來越復雜，jsp也開始跟不上時代了。
jsp的危機
我們先看一個對話場景：
java程序員：終于寫完了功能，是時候在界面上展示了。
前端程序員：你功能寫完了，我沒有數據，在頁面什么沒法展示呀
java程序員：數據我寫好了，你在jsp中調用XX方法就能獲取了，
前端程序員：我已經在jsp中寫好了這個方法，你為什么自己寫了？
于是乎，無窮無盡的爭吵還在繼續當中。
這就是jsp的弊端，為什么呢？我們可以來總結一下：
（1）動態和靜態資源放在一起，一旦服務器出現狀況，前后臺一起玩完，用戶體驗極差。
（2）一旦jsp出現了問題，就需要前端后端發開人員一塊來分析解決，效率低。
（3）jsp無法使用nginx等。
（4）jsp頁面復雜，難以修改。
（5）第一次加載jsp需要編譯成servlet，時間久，而且業務量大的時候，jsp負擔太大。
（6）jsp對于開發人員簡直就是一個揮之不去的痛，太難了！！！
鑒于以上缺點，于是另外一套機制橫空出世了，這就是前后端分離。什么是前后端分離呢？
前后端分離其實就是后端工程師只關注于后端頁面的開發，不再處理前端問題。前端工程師只關注于自己的頁面開發。需要數據交互的時候，兩者會有一份接口文檔。
就這樣這種思想架構很快的流行開來，這也就是為什么jsp落寞的真正原因。從此java從jsp轉向了restful結構，springMCV也開始流行開來，并逐漸占領了市場。前后端分離有什么優點呢？我們來總結一下：
（1）動態和靜態資源分開存儲。
（2）出現bug能很快定位是前端還是后端。
（3）支持nginx。在高并發狀態下極其優秀。
（4）直接請求頁面，不用編譯，速度效率都提上來了。
（5）從此前端和后端是相親相愛的一家人了！！！！
jsp的落幕
又隨著時間的推移，jsp的時代基本上一去不復返了，因為我們又走入了移動互聯時代，這時候的客戶端可不是前端頁面了，還包括手機、汽車、電視等等各種設備，這種情況下，前后端必須要分離了。jsp基本上徹底告別了它的舞臺。
SP的工作模式是請求/響應模式，客戶端首先發出HTTP請求，JSP程序收到請求后將進行處理并返回處理結果。在一個JSP文件第一次被請求的時候，JSP引擎(容器)把該JSP文件轉換成一個Servlet，而這個引擎本身也是一個Servlet。JSP的運行原理如圖11-4所示。
圖11-4 JSP的運行原理
JSP的運行過程具體如下。
(1)客戶端發出請求，請求訪問JSP文件。
(2)JSP容器先將JSP文件轉換成一個Java源文件(Java Servlet源程序)，在轉換過程中，如果發現JSP文件中存在任何語法錯誤，則中斷轉換過程，并向服務端和客戶端返回出錯信息。
(3)如果轉換成功，則JSP容器會將生成的Java源文件編譯成相應的字節碼文件*.class。該class文件就是一個Servlet，Servlet容器會像處理其他Servlet一樣處理它。
(4)由Servlet容器加載轉換后的Servlet類(class文件)創建一個該Servlet(JSP頁面的轉換結果)的實例，并執行Servlet的jspInit()方法。jsInit()方法在Servlet的整個生命周期中只會執行一次。
(5)執行jspService()方法處理客戶端的請求。對于每一個請求，JSP容器都會創建一個新的線程處理它。如果多個客戶端同時請求該JSP文件，則JSP容器會創建多個線程，使每一個客戶端請求都對應一個線程。
(6)如果JSP文件被修改了，則服務器將根據設置決定是否對該文件重新進行編譯，如果需要重新編譯，則使用重新編譯后的結果取代內存中的Servlet，并繼續上述處理過程。需要注意的是，雖然JSP效率很高，但在第一次調用時往往由于需要轉換和編譯，所以會產生一些輕微的延遲。
(7)如果系統出現資源不足等問題，JSP容器可能會以某種不確定的方式將Servlet從內存中移除，發生這種情況的時候，首先會調用jspDestroy()方法，然后Servlet實例會被作為“垃圾”進行處理。
(8)當請求處理完成后，響應對象由JSP容器接收，并將HTML格式的響應信息發送回客戶端。
者 | 水車
鏈接 | www.cnblogs.com/xuange306
前言
以前的項目大多數都是Java程序猿又當爹又當媽，既搞前，又搞后端。
隨著時代的發展，漸漸的許多大中小公司開始把前后端的界限分的越來越明確，前端工程師只負責前端的事情，后端工程師只管后端的事情。正所謂術業有專攻，一個人如果什么都會，那么每一樣都很難達到精通。
大中型公司需要專業人才，小公司需要全才，但是對于個人職業發展來說，我建議是分開。你要是這輩子就吃 Java 這碗飯，就不要去研究什么 css，js 等等。
把你的精力專注在 Java，JVM 原理，Spring原理，mysql鎖，事務，多線程，大并發，分布式架構，微服務，以及相關的項目管理等等，這樣你的核心競爭力才會越來越高，正所謂你往生活中投入什么，生活就會反饋給你什么。
曾幾何時
我們的Java Web項目都是使用了若干后臺框架進行開發，Spring、Spring MVC、MyBatis、Hibernate等等。
而且大多數項目在Java后端都是分了三層，控制層、業務層、持久層。控制層負責接收參數，調用相關業務層，封裝數據，以及路由到JSP頁面。然后Jsp頁面上使用各種標簽（jstl/el）表達式將后臺的數據展現出來。
我們先看上述這種情況，需求定完了，代碼寫完了，測試測完了，然后發布：
你需要用maven或者eclipse等工具把你的代碼打成一個war包，然后把這個war包發布到你的生產環境下的Web容器里，發布完了之后，你要啟動你的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 必須要在支持Sava的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可以完全不學，對于一些學生朋友來說，servlet等相關的Java web基礎還是要掌握牢的，不然你以為Spring MVC這種框架是基于什么來寫的？
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
