整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
源 | 愚公要移山（ID:fdd_sxu_nwpu）
jsp技術(shù)作為曾經(jīng)一度火爆的技術(shù)，在最近幾年確實(shí)使用率越來越低了，這篇文章帶你一塊探究一下jsp的從生到死。
jsp技術(shù)的誕生
在很久很久以前，那時(shí)候我們的開發(fā)都是通過servlet來完成的，這個(gè)servlet是什么呢？我們先來認(rèn)識一下：
servlet用Java語言編寫的服務(wù)器端程序。主要功能是和瀏覽器進(jìn)行交互，生成頁面展示。
長下面這個(gè)樣子：
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去一個(gè)標(biāo)簽一個(gè)標(biāo)簽去生成，如果一個(gè)頁面超級復(fù)雜，動不動幾千行代碼，那這個(gè)servlet效率也就太低了。而且整個(gè)servlet代碼也會十分臃腫而且可讀性非常差。
這時(shí)候怎么辦呢？sun公司很早就意識到了這個(gè)問題，于是便倡導(dǎo)很多公司一塊來創(chuàng)建了一種能夠動態(tài)生成html的新技術(shù)，不久之后jsp便誕生了。有效率的解決了上面servlet所出現(xiàn)的問題。
jsp的發(fā)展
既然jsp技術(shù)能夠解決剛剛servlet代碼里面所出現(xiàn)的技術(shù)，我們來看一下是如何解決的：在這里我們舉一個(gè)小例子，就是前端jsp向服務(wù)器servlet發(fā)送請求圖書頁面的功能。
首先我們看一下servlet：
public class List_book extends HttpServlet {public void doGet(HttpServletRequest request, HttpServletResponse response)throws ServletException, IOException {//聲明一個(gè)ArrayList.用來存放Book類中的數(shù)據(jù)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數(shù)據(jù)發(fā)送到.jap文件中request.getRequestDispatcher("ListBook.jsp").forward(request, response);}}
我們會發(fā)現(xiàn)，現(xiàn)在的servlet沒有一點(diǎn)html代碼了。我們只需要把數(shù)據(jù)交給jsp。此時(shí)我們的頁面展示就交給jsp來做了。現(xiàn)在我們來看一下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><!-- 繼續(xù)使用jsp語句 循環(huán)放入存放于list中的Book實(shí)體類中的數(shù)據(jù) --><%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代碼。對于我們程序員來說，在開發(fā)當(dāng)中靜態(tài)的頁面我們只需要用html和css寫一些標(biāo)簽來展示即可，對于那些動態(tài)的部分我們就可以使用java代碼。
那么jsp和servlet是不是就是這種協(xié)作的關(guān)系，本質(zhì)上有什么區(qū)別呢？
其實(shí)jsp只是servlet的一種特殊形式，每一個(gè)jsp頁面就是一個(gè)servlet實(shí)例，通俗一點(diǎn)的話來說：jsp就是servlet，只不過servlet把一些業(yè)務(wù)功能剝離開來交給了或者是形成了jsp。明白了吧。在我們的項(xiàng)目編譯的時(shí)候就是把jsp編譯成了servlet。
你們會發(fā)現(xiàn)，這樣做其實(shí)挺好的，市場也驗(yàn)證了一切，很快jsp技術(shù)流行開來，可是隨著時(shí)間的流逝，業(yè)務(wù)越來越復(fù)雜，jsp也開始跟不上時(shí)代了。
jsp的危機(jī)
我們先看一個(gè)對話場景：
java程序員：終于寫完了功能，是時(shí)候在界面上展示了。
前端程序員：你功能寫完了，我沒有數(shù)據(jù)，在頁面什么沒法展示呀
java程序員：數(shù)據(jù)我寫好了，你在jsp中調(diào)用XX方法就能獲取了，
前端程序員：我已經(jīng)在jsp中寫好了這個(gè)方法，你為什么自己寫了？
于是乎，無窮無盡的爭吵還在繼續(xù)當(dāng)中。
這就是jsp的弊端，為什么呢？我們可以來總結(jié)一下：
（1）動態(tài)和靜態(tài)資源放在一起，一旦服務(wù)器出現(xiàn)狀況，前后臺一起玩完，用戶體驗(yàn)極差。
（2）一旦jsp出現(xiàn)了問題，就需要前端后端發(fā)開人員一塊來分析解決，效率低。
（3）jsp無法使用nginx等。
（4）jsp頁面復(fù)雜，難以修改。
（5）第一次加載jsp需要編譯成servlet，時(shí)間久，而且業(yè)務(wù)量大的時(shí)候，jsp負(fù)擔(dān)太大。
（6）jsp對于開發(fā)人員簡直就是一個(gè)揮之不去的痛，太難了！！！
鑒于以上缺點(diǎn)，于是另外一套機(jī)制橫空出世了，這就是前后端分離。什么是前后端分離呢？
前后端分離其實(shí)就是后端工程師只關(guān)注于后端頁面的開發(fā)，不再處理前端問題。前端工程師只關(guān)注于自己的頁面開發(fā)。需要數(shù)據(jù)交互的時(shí)候，兩者會有一份接口文檔。
就這樣這種思想架構(gòu)很快的流行開來，這也就是為什么jsp落寞的真正原因。從此java從jsp轉(zhuǎn)向了restful結(jié)構(gòu)，springMCV也開始流行開來，并逐漸占領(lǐng)了市場。前后端分離有什么優(yōu)點(diǎn)呢？我們來總結(jié)一下：
（1）動態(tài)和靜態(tài)資源分開存儲。
（2）出現(xiàn)bug能很快定位是前端還是后端。
（3）支持nginx。在高并發(fā)狀態(tài)下極其優(yōu)秀。
（4）直接請求頁面，不用編譯，速度效率都提上來了。
（5）從此前端和后端是相親相愛的一家人了！！！！
jsp的落幕
又隨著時(shí)間的推移，jsp的時(shí)代基本上一去不復(fù)返了，因?yàn)槲覀冇肿呷肓艘苿踊ヂ?lián)時(shí)代，這時(shí)候的客戶端可不是前端頁面了，還包括手機(jī)、汽車、電視等等各種設(shè)備，這種情況下，前后端必須要分離了。jsp基本上徹底告別了它的舞臺。
SP的工作模式是請求/響應(yīng)模式，客戶端首先發(fā)出HTTP請求，JSP程序收到請求后將進(jìn)行處理并返回處理結(jié)果。在一個(gè)JSP文件第一次被請求的時(shí)候，JSP引擎(容器)把該JSP文件轉(zhuǎn)換成一個(gè)Servlet，而這個(gè)引擎本身也是一個(gè)Servlet。JSP的運(yùn)行原理如圖11-4所示。
圖11-4 JSP的運(yùn)行原理
JSP的運(yùn)行過程具體如下。
(1)客戶端發(fā)出請求，請求訪問JSP文件。
(2)JSP容器先將JSP文件轉(zhuǎn)換成一個(gè)Java源文件(Java Servlet源程序)，在轉(zhuǎn)換過程中，如果發(fā)現(xiàn)JSP文件中存在任何語法錯誤，則中斷轉(zhuǎn)換過程，并向服務(wù)端和客戶端返回出錯信息。
(3)如果轉(zhuǎn)換成功，則JSP容器會將生成的Java源文件編譯成相應(yīng)的字節(jié)碼文件*.class。該class文件就是一個(gè)Servlet，Servlet容器會像處理其他Servlet一樣處理它。
(4)由Servlet容器加載轉(zhuǎn)換后的Servlet類(class文件)創(chuàng)建一個(gè)該Servlet(JSP頁面的轉(zhuǎn)換結(jié)果)的實(shí)例，并執(zhí)行Servlet的jspInit()方法。jsInit()方法在Servlet的整個(gè)生命周期中只會執(zhí)行一次。
(5)執(zhí)行jspService()方法處理客戶端的請求。對于每一個(gè)請求，JSP容器都會創(chuàng)建一個(gè)新的線程處理它。如果多個(gè)客戶端同時(shí)請求該JSP文件，則JSP容器會創(chuàng)建多個(gè)線程，使每一個(gè)客戶端請求都對應(yīng)一個(gè)線程。
(6)如果JSP文件被修改了，則服務(wù)器將根據(jù)設(shè)置決定是否對該文件重新進(jìn)行編譯，如果需要重新編譯，則使用重新編譯后的結(jié)果取代內(nèi)存中的Servlet，并繼續(xù)上述處理過程。需要注意的是，雖然JSP效率很高，但在第一次調(diào)用時(shí)往往由于需要轉(zhuǎn)換和編譯，所以會產(chǎn)生一些輕微的延遲。
(7)如果系統(tǒng)出現(xiàn)資源不足等問題，JSP容器可能會以某種不確定的方式將Servlet從內(nèi)存中移除，發(fā)生這種情況的時(shí)候，首先會調(diào)用jspDestroy()方法，然后Servlet實(shí)例會被作為“垃圾”進(jìn)行處理。
(8)當(dāng)請求處理完成后，響應(yīng)對象由JSP容器接收，并將HTML格式的響應(yīng)信息發(fā)送回客戶端。
者 | 水車
鏈接 | www.cnblogs.com/xuange306
前言
以前的項(xiàng)目大多數(shù)都是Java程序猿又當(dāng)?shù)之?dāng)媽，既搞前，又搞后端。
隨著時(shí)代的發(fā)展，漸漸的許多大中小公司開始把前后端的界限分的越來越明確，前端工程師只負(fù)責(zé)前端的事情，后端工程師只管后端的事情。正所謂術(shù)業(yè)有專攻，一個(gè)人如果什么都會，那么每一樣都很難達(dá)到精通。
大中型公司需要專業(yè)人才，小公司需要全才，但是對于個(gè)人職業(yè)發(fā)展來說，我建議是分開。你要是這輩子就吃 Java 這碗飯，就不要去研究什么 css，js 等等。
把你的精力專注在 Java，JVM 原理，Spring原理，mysql鎖，事務(wù)，多線程，大并發(fā)，分布式架構(gòu)，微服務(wù)，以及相關(guān)的項(xiàng)目管理等等，這樣你的核心競爭力才會越來越高，正所謂你往生活中投入什么，生活就會反饋給你什么。
曾幾何時(shí)
我們的Java Web項(xiàng)目都是使用了若干后臺框架進(jìn)行開發(fā)，Spring、Spring MVC、MyBatis、Hibernate等等。
而且大多數(shù)項(xiàng)目在Java后端都是分了三層，控制層、業(yè)務(wù)層、持久層。控制層負(fù)責(zé)接收參數(shù)，調(diào)用相關(guān)業(yè)務(wù)層，封裝數(shù)據(jù)，以及路由到JSP頁面。然后Jsp頁面上使用各種標(biāo)簽（jstl/el）表達(dá)式將后臺的數(shù)據(jù)展現(xiàn)出來。
我們先看上述這種情況，需求定完了，代碼寫完了，測試測完了，然后發(fā)布：
你需要用maven或者eclipse等工具把你的代碼打成一個(gè)war包，然后把這個(gè)war包發(fā)布到你的生產(chǎn)環(huán)境下的Web容器里，發(fā)布完了之后，你要啟動你的Web容器，開始提供服務(wù)，這時(shí)候你通過配置域名，dns等等相關(guān)，你的網(wǎng)站就可以訪問了。
那我們來看，你的前后端代碼是不是全都在那個(gè)war包里？包括你的js，css，圖片，各種第三方的庫，對吧？
好，下面在瀏覽器中輸入你的網(wǎng)站域名：www.xxx.com，之后發(fā)生了什么？
瀏覽器在通過ip路由到你的服務(wù)，在tcp3次握手之后，通過tcp協(xié)議開始訪問你的Web服務(wù)器，你的Web服務(wù)器得到請求后，開始提供服務(wù)，接收請求，之后通過response返回你的應(yīng)答給瀏覽器。
我們先假設(shè)你的首頁中有100張圖片，以及一個(gè)單表的查詢，此時(shí)，用戶的看似一次http請求，其實(shí)并不是一次，用戶在第一次訪問的時(shí)候，瀏覽器中不會有緩存，你的100張圖片，瀏覽器要連著請求100次http請求（有人會跟我說http長鏈短鏈的問題，不在這里討論），你的Web服務(wù)器接收這些請求，都需要耗費(fèi)內(nèi)存去創(chuàng)建socket來玩tcp傳輸。
重點(diǎn)來了，這樣的話，你的Web服務(wù)器的壓力會非常大，因?yàn)轫撁嬷械乃姓埱蠖际侵徽埱蟮侥氵@臺服務(wù)器上，如果1個(gè)人還好，如果10000個(gè)人并發(fā)訪問呢（先不聊web服務(wù)器集群，這里就說是單實(shí)例Web服務(wù)器），那你的服務(wù)器能扛住多少個(gè)tcp鏈接？你的服務(wù)器的內(nèi)存有多大？你能抗住多少IO？你給web服務(wù)器分的內(nèi)存有多大？會不會宕機(jī)？
這就是為什么，越是大中型的Web應(yīng)用，他們越是要解耦。
理論上你可以把你的數(shù)據(jù)庫+應(yīng)用服務(wù)+消息隊(duì)列+緩存+用戶上傳的文件+日志+等等都扔在一臺主機(jī)上，但是這樣就好像是你把雞蛋都放在一個(gè)籃子里，隱患非常大。
正常的分布式架構(gòu)，是都要拆開的，你的應(yīng)用服務(wù)器集群（前，后）+文件服務(wù)器集群+數(shù)據(jù)庫服務(wù)器集群+消息隊(duì)列集群+緩存集群等等。
步入正題
下面步入正題，首先以后的 Java web項(xiàng)目都盡量要避免使用JSP，要搞前后臺解耦，玩分布式架構(gòu)，這樣我們的應(yīng)用架構(gòu)才更強(qiáng)。
使用 JSP 的痛點(diǎn)：
1. 動態(tài)資源和靜態(tài)資源全部耦合在一起，無法做到真正的動靜分離。服務(wù)器壓力大，因?yàn)榉?wù)器會收到各種http請求，例如css的http請求、js的、圖片的、動態(tài)代碼的等等。一旦服務(wù)器出現(xiàn)狀況，前后臺一起玩完，用戶體驗(yàn)極差。
2. 前端工程師做好html后，需要由Java工程師來將html修改成jsp頁面，出錯率較高（因?yàn)轫撁嬷薪?jīng)常會出現(xiàn)大量的js代碼），修改問題時(shí)需要雙方協(xié)同開發(fā)，效率低下。
3. JSP 必須要在支持Sava的Web服務(wù)器里運(yùn)行（例如tomcat等），無法使用nginx等（nginx據(jù)說單實(shí)例http并發(fā)高達(dá)5w，這個(gè)優(yōu)勢要用上），性能提不上來。
4. 第一次請JSP，必須要在web服務(wù)器中編譯成servlet，第一次運(yùn)行會較慢。
5. 每次請求JSP都是訪問Servlet再用輸出流輸出的html頁面，效率沒有直接使用html高。
6. JSP 內(nèi)有較多標(biāo)簽和表達(dá)式，前端工程師在修改頁面時(shí)會捉襟見肘，遇到很多痛點(diǎn)。
7. 如果JSP中的內(nèi)容很多，頁面響應(yīng)會很慢，因?yàn)槭峭郊虞d。
基于上述的一些痛點(diǎn)，我們應(yīng)該把整個(gè)項(xiàng)目的開發(fā)權(quán)重往前移，實(shí)現(xiàn)前后端真正的解耦！
老的方式：
1. 客戶端請求
2. 服務(wù)端的servlet或controller接收請求（路由規(guī)則由后端制定，整個(gè)項(xiàng)目開發(fā)的權(quán)重大部分在后端）
3. 調(diào)用service,dao代碼完成業(yè)務(wù)邏輯
4. 返回JSP
5. jsp展現(xiàn)一些動態(tài)的代碼
新的方式：
1. 瀏覽器發(fā)送請求
2. 直接到達(dá)html頁面（路由規(guī)則由前端制定，整個(gè)項(xiàng)目開發(fā)的權(quán)重前移）
3. html頁面負(fù)責(zé)調(diào)用服務(wù)端接口產(chǎn)生數(shù)據(jù)（通過ajax等等）
4. 填充html，展現(xiàn)動態(tài)效果。
有興趣的童鞋可以訪問一下阿里巴巴等大型網(wǎng)站，然后按一下F12，監(jiān)控一下你刷新一次頁面，他的http是怎么玩的，大多數(shù)都是單獨(dú)請求后臺數(shù)據(jù)，使用 json傳輸數(shù)據(jù)，而不是一個(gè)大而全的http請求把整個(gè)頁面包括動+靜全部返回過來
這樣做的好處是：
1. 可以實(shí)現(xiàn)真正的前后端解耦，前端服務(wù)器使用nginx。
前端服務(wù)器放的是css，js，圖片等等一系列靜態(tài)資源。甚至你還可以css，js，圖片等資源放到特定的文件服務(wù)器，例如阿里云的oss，并使用cdn加速，前端服務(wù)器負(fù)責(zé)控制頁面引用，跳轉(zhuǎn)，調(diào)用后端的接口，后端服務(wù)器使用tomcat。
這里需要使用一些前端工程化的框架比如nodejs，react，router，react，redux，webpack
2. 發(fā)現(xiàn)bug，可以快速定位是誰的問題，不會出現(xiàn)互相踢皮球的現(xiàn)象。
頁面邏輯，跳轉(zhuǎn)錯誤，瀏覽器兼容性問題，腳本錯誤，頁面樣式等問題，全部由前端工程師來負(fù)責(zé)。
接口數(shù)據(jù)出錯，數(shù)據(jù)沒有提交成功，應(yīng)答超時(shí)等問題，全部由后端工程師來解決。
雙方互不干擾，前端與后端是相親相愛的一家人。
3. 在大并發(fā)情況下，我可以同時(shí)水平擴(kuò)展前后端服務(wù)器，比如淘寶的一個(gè)首頁就需要2000臺前端服務(wù)器做集群來抗住日均多少億+的日均pv。
去參加阿里的技術(shù)峰會，聽他們說他們的web容器都是自己寫的，就算他單實(shí)例抗10萬http并發(fā)，2000臺是2億http并發(fā)，并且他們還可以根據(jù)預(yù)知洪峰來無限拓展，很恐怖，就一個(gè)首頁。
4. 減少后端服務(wù)器的并發(fā)壓力，除了接口以外的其他所有http請求全部轉(zhuǎn)移到前端nginx上。
5. 即使后端服務(wù)暫時(shí)超時(shí)或者宕機(jī)了，前端頁面也會正常訪問，只不過數(shù)據(jù)刷不出來而已。
6. 也許你也需要有微信相關(guān)的輕應(yīng)用，那樣你的接口完全可以共用，如果也有app相關(guān)的服務(wù)，那么只要通過一些代碼重構(gòu)，也可以大量復(fù)用接口，提升效率。
7. 頁面顯示的東西再多也不怕，因?yàn)槭钱惒郊虞d。
注意：
1. 在開需求會議的時(shí)候，前后端工程師必須全部參加，并且需要制定好接口文檔，后端工程師要寫好測試用例，不要讓前端工程師充當(dāng)你的組專職測試，推薦使用
chrome的插件postman，service層的測試用例拿junit寫。
2. 上述的接口并不是java里的interface，說白了調(diào)用接口就是調(diào)用你controler里的方法。
3. 加重了前端團(tuán)隊(duì)的工作量，減輕了后端團(tuán)隊(duì)的工作量，提高了性能和可擴(kuò)展性。
4. 我們需要一些前端的框架來解決類似于頁面嵌套，分頁，頁面跳轉(zhuǎn)控制等功能。（上面提到的那些前端框架）。
5. 如果你的項(xiàng)目很小，或者是一個(gè)單純的內(nèi)網(wǎng)項(xiàng)目，那你大可放心，不用任何架構(gòu)而言，但是如果你的項(xiàng)目是外網(wǎng)項(xiàng)目，呵呵噠。
6. 以前還有人在使用類似于velocity/freemarker等模板框架來生成靜態(tài)頁面，現(xiàn)在這種做法也被淘汰掉了。
7. 這篇文章主要的目的是說JSP在大型外網(wǎng)Java web項(xiàng)目中被淘汰掉，可沒說JSP可以完全不學(xué)，對于一些學(xué)生朋友來說，servlet等相關(guān)的Java web基礎(chǔ)還是要掌握牢的，不然你以為Spring MVC這種框架是基于什么來寫的？
*請認(rèn)真填寫需求信息，我們會在24小時(shí)內(nèi)與您取得聯(lián)系。
