java前後端分離,java前後端分離怎麼實現原理

本文目錄一覽：

• 1、如何在開發時部署和運行前後端分離的JavaWe
• 2、Web項目開發為何要走前後端分離模式？
• 3、怎麼理解前後端分離
• 4、jsp與前後端分離誰更快

如何在開發時部署和運行前後端分離的JavaWe

在開發中大型的JavaEE項目時，前後端分離的框架逐漸成為業界的主流，傳統的單機部署前後端在同一個項目中的工程項目越來越少。這類JavaWeb項目的後端通常都採用微服務的架構，後端會被分解為諸多個小項目，然後使用dubbo+zookeeper或者springCloud來構建微服務，前端則會是一個單獨的項目，前台的請求通過微服務來調用。但是，不同與傳統的web項目，這類前後端分離的項目如何在開發中部署和運行呢？

當前後端分離時，後端項目一定會被載入到tomcat的webapp目錄下面，但是前端的資源院該如何被訪問到呢？這裡以tomcat這個中間件為例，探討在開發這類項目的時候，如何讓前後端分離的項目部署並且運行起來，即後端項目部署在tomcat之後如何在運行時訪問靜態資源（非上線部署）。

主要有兩種方案：1.在本地通過Nginx來處理這些靜態資源。2、將靜態資源統一放入一個javaweb應用中，並將自動生成的war包隨後端項目一期丟入tomcat。下面詳細介紹

一、使用Nginx來訪問靜態資源。

在本地安裝nginx並且修改nginx.conf，修改相關配置，將web訪問的埠的資源進行更改，配置如下：

server {        listen       80;        server_name  localhost;        charset utf-8;        #access_log  logs/host.access.log  main;

location / {              proxy_pass ;              proxy_redirect off;

proxy_set_header HOST $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

client_max_body_size 10m;

client_body_buffer_size 128k;

proxy_connect_timeout 90;

proxy_send_timeout 90;

proxy_read_timeout 90;

proxy_buffer_size 4k;

proxy_buffers 4 32k;

proxy_busy_buffers_size 64k;

proxy_temp_file_write_size 64k;

}

location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css|woff|woff2|ttf|eot|map)$  {

root D:\Workspaces\esop-html;             index index.html;

}

listen對象改為你本地的tomcat訪問埠，最下面location中的root改為你前端項目中靜態資源的位置，這樣就可以實現只部署後端的項目就能訪問前端的頁面了。

二、將前端項目轉換為動態的web項目，隨後端項目一起丟入tomcat

這個方案省去了在本地安裝和配置nginx，但是也只適用於開發階段項目的部署運行和調試，真正在生產環境通常前後端項目會部署在不同的伺服器。

如果是Intellij Idea,在導入前端項目之後，右鍵項目 add framework support — web application，這時將會把前端項目轉換為一個javaweb項目，然後將靜態資源放在生成的web目錄下即可。

如果是eclipse，可以新建一個javaweb項目然後將靜態資源放入web或者webcontent目錄下，或者直接先導入前端項目，然後通過 project facts 將項目轉換為dynamic web項目並勾選 js等相關配置。

然後，運行項目時把後端的war包和前端的war包一同添加到 deployment中運行即可。

Web項目開發為何要走前後端分離模式？

把前端與後端獨立起來去開發，放在兩個不同的伺服器，需要獨立部署，兩個不同的工程，兩個不同的代碼庫，不同的開發人員，前後端工程師需要約定交互介面，實現同步開發，開發結束後需要進行獨立部署，前端通過介面來調用調用後端的API，前端只需要關注頁面的樣式與動態數據的解析和渲染，而後端專註於具體業務邏輯。具體好處有以下幾點：

1.徹底解放前端

前端不再需要向後台提供模板或是後台在前端html中嵌入後台代

2.提高工作效率，分工更加明確

前後端分離的工作流程可以使前端只關注前端的事，後台只關心後台的活，兩者開發可以同時進行，在後台還沒有時間提供介面的時候，前端可以先將數據寫死或者調用本地的json文件即可，頁面的增加和路由的修改也不必再去麻煩後台，開發更加靈活。

3.局部性能提升

通過前端路由的配置，我們可以實現頁面的按需載入，無需一開始載入首頁便載入網站的所有的資源，伺服器也不再需要解析前端頁面，在頁面交互及用戶體驗上有所提升。

4.降低維護成本

通過目前主流的前端MVC框架，我們可以非常快速的定位及發現問題的所在，客戶端的問題不再需要後台人員參與及調試，代碼重構及可維護性增強。

5.實現高內聚低耦合，減少後端（應用）伺服器的並發/負載壓力。

6.即使後端服務暫時超時或者宕機了，前端頁面也會正常訪問，但無法提供數據。

7.可以使後台能更好的追求高並發，高可用，高性能；使前端能更好的追求頁面表現、速度流暢、兼容性、用戶體驗等。

我理解的前後端分離，前端是需要起伺服器的，減少學習成本，可以用node，前端也要有域名的

如果是半分離， 那麼前端提供js文件（css等）這個我也做過，前後端都用node就不說了，如果是兩種語言，

如果一個工程文件下開發，webpack下直接打包進後台語言的靜態目錄下。

如果是兩個工程，那麼前端只提供生成的js（css）文件，git pull後台項目，扔進靜態目錄，這樣又涉及到版本控制的問題，一般我會生成一個配置文件，直接讀取的，內容是xxx.hash.js這種文件名，然後document.wirte動態寫入js/css

前端起伺服器就不需要動態引入了，直接html插件生成文件，更好的控制版本

半分離 還有一個問題，例如首頁同構，如果更改xxx.blade.php文件，這就又動了php文件，甚至包括nginx反向代理啊，ssl這種緩存啊，都比較麻煩，你要是改了點啥，自己的ok了，後台的崩了，那就挺操蛋了，大公司有專門的運維還好，小公司真的是一團糟

後台我們採取全分離，nginx前端管理，至於升級nginx版本，http2，反向代理，https證書，都是前端自己弄，畢竟小公司，每個人水平都不一致，自己負責自己的比較好

但是這個跨域又要稍微處理一下，至今我這邊後台還是*，我也沒法說什麼

阿里雲這麼便宜，如果把成本浪費在人力上，會變得很貴

一個人的精力有限，前後端分離有助於我們更專註我們所要注重的技術點，俗話說：「術業有專攻」。

比如我們後端，前後端分離有助於我們把注意力放在java基礎，設計模式，jvm原理，spring+springmvc原理及源碼，linux，mysql事務隔離與鎖機制，mongodb，http/tcp，多線程，分散式架構（dubbo，dubbox，spring cloud），彈性計算架構，微服務架構（springboot+zookeeper+docker+jenkins），java性能優化，以及相關的項目管理等等。

而前端也可以集中精力在前端的展示上。

總的來說，前後端分離利大於弊。這也是越來越少用jsp的原因。

補充兩點

1.每次請求的數據量變小，也意味著更少的響應時間。

2.也不是每個應用用前後端分離都是最合適的，要根據應用規模，工期綜合判斷。

怎麼理解前後端分離

對於前後端分離，認識上有個誤區，那就是很多人自稱：我們老早就分離了，全AJAX，使用Angular或者什麼什麼就可以了。

這個說法是不合適的，打個比方，別人問的是逗如何解決家禽把蛋生在水草邊的問題看地，但實際上人家養的是鴨子，答題的卻是養雞的，所以回答逗不讓去水邊就行了地，這顯然不在點子上。

這

兩年業界說的前後端分離，是限於偏展示類的系統（用A代替），而不是應用、管控類Web項目（用B代替），在B類項目里，前後端是天然分離的，對此，除了

少部分後端開發人員，基本所有人的認識都是一致的。上一段中這樣回答的人一般都是只做B類項目，在B類項目里，前後端分離是共識，不需要討論。

那麼，剩下的問題就是討論A類項目的前後端分離了。這個問題的核心在什麼地方呢，在於模板的與數據結合的位置，以及，模板的控制權在誰手裡。經過這兩年的討論，基本上我們可以達成的共識就是：模板應當由前端人員去控制，主要原因有兩方面：

– 性能優化（尤其是外部資源的管理與發布，請求合併等等）

– 協作的順暢性（已形成模板的界面片段的返工等問題）

那麼，模板到底應該在什麼地方跟數據結合看

這個問題就比較折騰了，有部分人嘗試像B類項目那樣，使用js模板，然後在瀏覽器端執行，這是存在一些問題的，比如說seo不友好，首屏性能不夠，尤其對於首頁DOM量很大的電商類網站，差距很明顯。

所

以我們還是得把主要的模板放在服務端來執行。在這個過程中，阿里作了一些嘗試，那就是引入Node層，在這一層把模板與數據進行合成，然後瀏覽器拿到的就

是生成好的HTML了，但也不是所有HTML都是這麼生成好的，還是會有一些內容等到了瀏覽器之後，再用js去載入和生成。

所以這一定會是一個混合方案，同一個系統中存在兩種模板，一種在服務端執行，一種在瀏覽器中執行，互為補充。

至

於說這個方案中，是否中間層一定要是node，我覺得無所謂，只要是能正常做web項目的東西都可以，這個還是要看所在企業的技術積累方向，當然node

做這塊是有一些優勢的，比如對前端人員的語言友好性，前後端模板的通用性等等，但這些都是細節，重點還是整體方案和流程。

這時候回頭看你問題中的這句：

前後端分離的意思是，前後端只通過 JSON 來交流，組件化、工程化不需要依賴後端去實現。

我相信你這裡對前後端的限定是以瀏覽器為準的，但事實上，A類項目中，前後端的分界一定要延伸到伺服器端的模板層，也就是在這一層里，把各種來源的數據整合到模板中，這個數據未必是JSON格式的，會存在有JSON，XML，特定的二進位等等。

組

件化這個話題就更複雜了，在剛才組織形式中，很難說出究竟什麼才是組件。是某個商品的模板嗎看是數據嗎看是數據和模板的結合體嗎看沒法回答。在此，我說一

句自己的看法：像電商這種項目的前端部分，基本不存在組件的概念，甚至不存在組件化的價值，因為這裡面可復用的東西太少了，也不易提取，大多數東西都是不

帶邏輯的界面模板。

最近因為ReactJS的流行，帶來了一個Isomorphic的概念，這是一種很有意義的探索，但是否能解決這類問

題，尚不得而知，根據我的理解，它對B類項目是較好的補充方案，但對A類項目暫時還缺乏可用性，因為A類項目中，運行期的DOM變更並不多，多是整片的改

變，用這個方案去解決的話，有些牛刀殺雞的感覺。

關於B類項目的組件化，我之前那個沒寫完的系列是關於它的，但經過最近一年多的思考，我又覺得需要再重新寫一篇東西了。感謝你的問題提醒了我，這就寫。

jsp與前後端分離誰更快

前後端分離更快

前後分離的優勢：

1.可以實現真正的前後端解耦，前端伺服器使用nginx。

前端/WEB伺服器放的是css，js，圖片等等一系列靜態資源（甚至你還可以css，js，圖片等資源放到特定的文件伺服器，例如阿里雲的oss，並使用cdn加速），前端伺服器負責控制頁面引用跳轉路由，前端頁面非同步調用後端的介面，後端/應用伺服器使用tomcat（把tomcat想像成一個數據提供者），加快整體響應速度。這裡需要使用一些前端工程化的框架比如（nodejs，react，router，react，redux，webpack）

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

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

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

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

3.在大並發情況下，可以同時水平擴展前後端伺服器，比如淘寶的一個首頁就需要2000+台前端伺服器做集群來抗住日均多少億+的日均pv。

4.減少後端伺服器的並發/負載壓力

除了介面以外的其他所有http請求全部轉移到前端nginx上，介面的請求調用tomcat，參考nginx反向代理tomcat。

且除了第一次頁面請求外，瀏覽器會大量調用本地緩存。

5.即使後端服務暫時超時或者宕機了，前端頁面也會正常訪問，只不過數據刷不出來而已。

6.也許你也需要有微信相關的輕應用，那樣你的介面完全可以共用，如果也有app相關的服務，

那麼只要通過一些代碼重構，也可以大量復用介面，提升效率。（多端應用）7.頁面顯示的東西再多也不怕，因為是非同步載入。

8.nginx支持頁面熱部署，不用重啟伺服器，前端升級更無縫。

9.增加代碼的維護性易讀性（前後端耦在一起的代碼讀起來相當費勁）。

10.提升開發效率，因為可以前後端並行開發，而不是像以前的強依賴。

11.在nginx中部署證書，外網使用https訪問，並且只開放443和80埠，其他埠一律關閉（防止黑客埠掃描），內網使用http，性能和安全都有保障。

12.前端大量的組件代碼得以復用，組件化，提升開發效率，抽出來！