前言
之前的項目大多數都是 Java 程序猿又當爹又當媽，既搞前，又搞後端。css
隨着時代的發展，漸漸的許多大中小公司開始把先後端的界限分的愈來愈明確，前端工程師只負責前端的事情，後端工程師只管後端的事情。正所謂術業有專攻，一我的若是什麼都會，那麼每同樣都很難達到精通。html
大中型公司須要專業人才，小公司須要全才，可是對於我的職業發展來講，選定一個方向，堅持走下去，就對了。前端
例如你打算專一於 Java 後端，那麼把你的精力專一在 Java，JVM 原理，Spring 原理，MySQL 鎖，事務，多線程，大併發，分佈式架構，微服務，以及相關的項目管理等等，這樣你的核心競爭力纔會愈來愈高，正所謂你往生活中投入什麼，生活就會反饋給你什麼。java
曾幾什麼時候
咱們的 Java Web 項目都是使用了若干後臺框架進行開發，Spring、Spring MVC、MyBatis、Hibernate 等等。node
並且大多數項目在 Java 後端都是分了三層，控制層、業務層、持久層。控制層負責接收參數，調用相關業務層，封裝數據，以及路由到 JSP 頁面。而後 Jsp 頁面上使用各類標籤（jstl/el）表達式將後臺的數據展示出來。react
咱們先看上述這種狀況，需求定完了，代碼寫完了，測試測完了，而後發佈：webpack
你須要用 Maven 或者 Eclipse 等工具把你的代碼打成一個 war 包，而後把這個 war 包發佈到你的生產環境下的 Web 容器裏，發佈完了以後，你要啓動你的 Web 容器，開始提供服務，這時候你經過配置域名，dns 等等相關，你的網站就能夠訪問了。nginx
那咱們來看，你的先後端代碼是否是全都在那個 war 包裏？包括你的 js，css，圖片，各類第三方的庫，對吧？程序員
好，下面在瀏覽器中輸入你的網站域名：www.xxx.com，以後發生了什麼？web
瀏覽器在經過 ip 路由到你的服務，在 tcp3 次握手以後，經過 tcp 協議開始訪問你的 Web 服務器，你的 Web 服務器獲得請求後，開始提供服務，接收請求，以後經過 response 返回你的應答給瀏覽器。
咱們先假設你的首頁中有 100 張圖片，以及一個單表的查詢，此時，用戶的看似一次 http 請求，其實並非一次，用戶在第一次訪問的時候，瀏覽器中不會有緩存，你的 100 張圖片，瀏覽器要連着請求 100 次 http 請求（有人會跟我說 http 長鏈短鏈的問題，不在這裏討論），你的 Web 服務器接收這些請求，都須要耗費內存去建立 socket 來玩 tcp 傳輸。推薦閱讀：40 篇原創乾貨，帶你進入 Spring Boot 殿堂！
重點來了，這樣的話，你的 Web 服務器的壓力會很是大，由於頁面中的全部請求都是隻請求到你這臺服務器上，若是 1 我的還好，若是 10000 我的併發訪問呢（先不聊 web 服務器集羣，這裏就說是單實例 Web 服務器），那你的服務器能扛住多少個 tcp 連接？你的服務器的內存有多大？你能抗住多少 IO ？你給 web 服務器分的內存有多大？會不會宕機？
這就是爲何，越是大中型的 Web 應用，他們越是要解耦。
理論上你能夠把你的數據庫+應用服務+消息隊列+緩存+用戶上傳的文件+日誌+等等都扔在一臺主機上，可是這樣就好像是你把雞蛋都放在一個籃子裏，隱患很是大。
正常的分佈式架構，是都要拆開的，你的應用服務器集羣（前，後）+文件服務器集羣+數據庫服務器集羣+消息隊列集羣+緩存集羣等等。推薦閱讀：40 篇原創乾貨，帶你進入 Spring Boot 殿堂！
步入正題
下面步入正題，首先之後的 Java Web 項目都儘可能要避免使用 JSP，要搞先後端解耦，玩分佈式架構，這樣咱們的應用架構才更強。
使用 JSP 的痛點
動態資源和靜態資源所有耦合在一塊兒，沒法作到真正的動靜分離。服務器壓力大，由於服務器會收到各類 http 請求，例如 css 的 http 請求、 js 的、圖片的、動態代碼的等等。一旦服務器出現情況，先後臺一塊兒玩完，用戶體驗極差。
前端工程師作好 html 後，須要由 Java 工程師來將 html 修改爲 jsp 頁面，出錯率較高（由於頁面中常常會出現大量的 js 代碼），修改問題時須要雙方協同開發，效率低下。
JSP 必需要在支持 Servlet 的 Web 服務器裏運行（例如 tomcat 等），沒法使用 nginx 等（nginx 聽說單實例 http 併發高達 5w，這個優點要用上），性能提不上來。
第一次請請求 JSP，必需要在 Web 服務器中編譯成 Servlet，第一次運行會較慢。
每次請求 JSP 都是訪問 Servlet 再用輸出流輸出的 html 頁面，效率沒有直接使用 html 高。
JSP 內有較多標籤和表達式，前端工程師在修改頁面時會捉襟見肘，遇到不少痛點。
若是 JSP 中的內容不少，頁面響應會很慢，由於是同步加載。
基於上述的一些痛點，咱們應該把整個項目的開發權重往前移，實現先後端真正的解耦！
老的方式
客戶端請求
服務端的 Servlet 或 Controller 接收請求（路由規則由後端制定，整個項目開發的權重大部分在後端）
調用 Service,dao 代碼完成業務邏輯
返回 JSP
jsp 展示一些動態的代碼
新的方式
瀏覽器發送請求
直接到達 html 頁面（路由規則由前端制定，整個項目開發的權重前移）
html 頁面負責調用服務端接口產生數據（經過 ajax 等等）
填充 html，展示動態效果。
有興趣的童鞋能夠訪問一下阿里巴巴等大型網站，而後按一下 F12，監控一下你刷新一次頁面，他的 http 是怎麼玩的，大多數都是單獨請求後臺數據，使用 json 傳輸數據，而不是一個大而全的 http 請求把整個頁面包括動+靜所有返回過來。推薦閱讀：40 篇原創乾貨，帶你進入 Spring Boot 殿堂！
這樣作的好處
能夠實現真正的先後端解耦，前端服務器使用nginx。
前端服務器放的是 css，js，圖片等等一系列靜態資源。甚至你還能夠 css，js，圖片等資源放到特定的文件服務器，例如阿里雲的 oss，並使用 cdn 加速，前端服務器負責控制頁面引用，跳轉，調用後端的接口，後端服務器使用 tomcat 。
這裏須要使用一些前端工程化的框架好比 nodejs，react，router，react，redux，webpack。
發現 bug，能夠快速定位是誰的問題，不會出現互相踢皮球的現象。
頁面邏輯，跳轉錯誤，瀏覽器兼容性問題，腳本錯誤，頁面樣式等問題，所有由前端工程師來負責。
接口數據出錯，數據沒有提交成功，應答超時等問題，所有由後端工程師來解決。
雙方互不干擾，前端與後端是相親相愛的一家人。
在大併發狀況下，我能夠同時水平擴展先後端服務器，好比淘寶的一個首頁就須要 2000 臺前端服務器作集羣來抗住日均多少億+的日均 pv。
去參加阿里的技術峯會，聽他們說他們的 Web 容器都是本身寫的，就算他單實例抗 10 萬 http 併發，2000 臺是 2 億 http 併發，而且他們還能夠根據預知洪峯來無限拓展，很恐怖，就一個首頁。
減小後端服務器的併發壓力，除了接口之外的其餘全部 http 請求所有轉移到前端 nginx 上。
即便後端服務暫時超時或者宕機了，前端頁面也會正常訪問，只不過數據刷不出來而已。
也許你也須要有微信相關的輕應用，那樣你的接口徹底能夠共用，若是也有 app 相關的服務，那麼只要經過一些代碼重構，也能夠大量複用接口，提高效率。
頁面顯示的東西再多也不怕，由於是異步加載。
注意
在開需求會議的時候，先後端工程師必須所有參加，而且須要制定好接口文檔，後端工程師要寫好測試用例，不要讓前端工程師充當你的組專職測試，推薦使用 Chrome 的插件 Postman，Service 層的測試用例拿 junit 寫。
上述的接口並非 Java 裏的 interface，說白了調用接口就是調用你 Controler 裏的方法。
加劇了前端團隊的工做量，減輕了後端團隊的工做量，提升了性能和可擴展性。
咱們須要一些前端的框架來解決相似於頁面嵌套，分頁，頁面跳轉控制等功能。（上面提到的那些前端框架）。
若是你的項目很小，或者是一個單純的內網項目，那你大可放心，不用任何架構而言，可是若是你的項目是外網項目，呵呵噠。
之前還有人在使用相似於 velocity/freemarker 等模板框架來生成靜態頁面，如今這種作法也被淘汰掉了。
這篇文章主要的目的是說 JSP 在大型外網 Java Web 項目中被淘汰掉，可沒說 JSP 能夠徹底不學，對於一些學生朋友來講，Servlet 等相關的 Java Web 基礎仍是要掌握牢的，否則你覺得 Spring MVC 這種框架是基於什麼來寫的？
喜歡就點個"在看"唄^_^
本文分享自微信公衆號 - 江南一點雨（a_javaboy）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。