'為什麼要放棄 JSP?'

""為什麼要放棄 JSP?

作者 | 水車

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

"

相關推薦

推薦中...