Java web項目的解耦合

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

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

 

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

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

 

 

幾曾什麼時候，咱們的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.jsp上動態資源和靜態資源所有耦合在一塊兒，服務器壓力大，由於服務器會收到各類靜態資源的http請求，動態代碼的等等，除非你使用nginx。

萬一你的java代碼出現了bug，你的頁面是顯示不出來的，直接蹦到了5xx頁面，用戶體驗極差。

(如今javaWeb項目業界的標準是nginx+tomcat，動靜分離，請求先到nginx，全部的靜態資源請求所有交給nginx，動態資源所有給tomcat，此外nginx還能夠玩負載均衡。ps：即便你依然使用jsp，也能夠這麼玩的，nginx聽說單實例http併發高達5w，這個優點要用上，tomcat的各類參數優化完http併發能上2000？還有不要把tomcat暴露給外網，一旦被黑客破解了以後，你配置文件裏全部的信息，以及你的代碼都會玩完，class文件怎麼了？class文件能夠反編譯，把nginx暴露給外網，只開放80和443端口，nginx調用tomcat所有都是內網ip，及時被黑客破解，他能拿到的也是一些靜態資源，你是安全的。)

2.前端工程師作好html後，須要由後端的java工程師來將html修改爲jsp頁面，包括各類文件的路徑，出錯率較高（由於頁面中常常會出現大量的js代碼），

頁面中耦合了標籤，java表達式，js代碼，html代碼，特別亂，修改問題時須要雙方協同開發，效率低下。

 

3.jsp必需要在支持java的web服務器裏運行（例如tomcat/resin/jboss/weblogic等），性能提不上來。

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

5.每次請求jsp都是訪問servlet再用輸出流輸出的html頁面，效率沒有直接使用html高（記住是每次喲~~~內存喲，IO喲）。

6.若是在生產環境中，發現了前端的bug，讓前端工程師來調試bug，這個時候的頁面已經很混亂了，呵呵，他會遇到不少痛點。

 

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

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

 

 

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

之前後端java程序猿的權重很大，什麼UI，前端，都只是附屬，如今須要改變。

前端不只僅是css，js那麼簡單，前端在使用了一些框架和工具以後，是能夠變成前端項目的，在項目層面拆開，前端也須要有MVC框架，也須要編譯，打包，部署，是很複雜的，越是大型互聯網公司，前端項目越是工程化的項目，包括前端項目的版本管理，運維，水都是很深的。這就是我在開篇中說的，術業有專攻！

你要玩，就要玩到極致，要不就別玩！

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



之前老的方式是：

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

 

 

 

新的方式是：

1.瀏覽器發送請求
2.直接到達html頁面（路由規則由前端制定，整個項目開發的權重前移）
3.html頁面負責調用服務端接口產生數據（經過ajax等等，後臺返回json格式數據）
4.填充html，展示動態效果，在頁面上進行解析並操做DOM。

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

之前有人跟我提過，能夠將jsp作動態頁面靜態化，能夠呀，你的數據庫裏有1000w條數據，你靜態化1000w個html嗎？請問您這1000w個html放在哪裏？無論放在哪裏，都是問題。還有若是頁面變動了，怎麼辦？從新再生成1000w個html頁面嗎？？？

能夠考慮一個html頁面而後調用後端接口，熱點數據查詢的時候直接使用分佈式緩存，不走數據庫了。之後你的項目玩大了，都是基於雲的架構，這塊水太深了，我也正在學習中，數據庫是有性能瓶頸的，由於有事務，有鎖，有鏈接數等等。）

 

總結一下新的方式的請求步驟：

大量併發瀏覽器請求--->web服務器集羣(nginx)--->應用服務器集羣(tomcat)--->文件/數據庫/緩存/消息隊列服務器集羣

同時又能夠玩分模塊，還能夠按業務拆成一個個的小集羣，把核心的業務封裝成一個業務中心，玩遠程業務調用，玩rpc，玩soa，使用springboot+docker玩微服務，這樣纔是一個彈性的分佈式架構。

 

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

這樣作的好處是：

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

前端服務器放的是css，js，圖片等等一系列靜態資源（甚至你還能夠css，js，圖片等資源放到特定的文件服務器，例如阿里雲的oss，並使用cdn加速），前端服務器負責控制頁面引用，跳轉，調用後端的接口，後端服務器使用tomcat（把tomcat想象成一個數據提供者，這裏也叫應用服務器），加快總體響應速度。

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

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

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

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

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

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

（去參加阿里的技術峯會，聽他們說他們的web容器都是本身寫的，就算他單實例抗10萬http併發，2000臺是2億http併發，你沒有看錯，確實是併發http，而且他們還能夠根據大數據來預知洪峯來無限拓展，他們的大數據都是實時採集，實時分析以及使用的，正所謂由IT時代變爲DT時代，很恐怖，就一個首頁。。。）

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

 

8.若是頁面上有一些權限等等相關的校驗，那麼這些相關的數據也能夠經過ajax從接口裏拿。