前後端分離搭建文件伺服器

A. 前後端分離架構下的跨域問題

在前後端分離架構下，難免會遇到跨域問題。但是對於跨域，很多人並沒有多麼深入的了解。這里我就詳細講一下這個問題。

同源策略與跨域

所謂跨域，英文叫做cross-domain，是網路安全領域的一個專有名詞。簡單點理解就是某些操作越過了域名的界限，訪問了別的域名。

如果腳本可以自由訪問其他域，就會產生很多安全問題。

比如，假設有一個網上銀行系統，你已經登錄過了，它支持一個ajax api可以進行轉賬；有一個論壇系統，人氣很高，但是其中有惡意腳本，這個腳本會調用這個ajax api，從當前登錄的用戶賬戶中，轉1000塊到攻擊者的賬戶。這樣，當你訪問這個論壇的時候，就會被轉走1000塊，而你一點都不知道！

除此之外，跨域請求還有很多危害。這不是一本關於安全的書，也就不展開講了，想深入了解的可以買一本餘弦編寫的《Web前端黑客技術揭秘》。

為了防範跨域攻擊，所有現代瀏覽器都遵循一套同源策略。根據MDN上的定義，「如果兩個頁面擁有相同的協議（protocol），埠（如果指定），和主機，那麼這兩個頁面就屬於同一個源（origin）」。對於違反同源策略的請求，除了img src等少數嵌入操作之外，都會被瀏覽器阻止。

這里需要注意的是：同源不僅僅要求相同的域名或ip，連協議和埠也必須相同。比如https://localhost和http://localhost或http://localhost:3000就不是同源的，而http://localhost/api和http://localhost/views是同源的。

我們平常所說的「跨域」其實就是指「發起不同源請求」，而這樣的跨域請求會被瀏覽器阻止。

同源策略對保障互聯網安全有著非常重要的作用，很多安全策略都是基於同源策略的。但是，這種同源策略會對前後端分離架構下的開發過程帶來很大困擾。比如，即使是本地伺服器，也沒法和前端開發伺服器運行在同一個埠上，這時候，跨域是必然的。而如果要讓後端程序同時提供web服務，則很難發揮前端工具鏈的輕量級優勢。那麼，如何解決跨域問題呢？

如何解決跨域問題？

JSONP方式

最初用來解決跨域問題的方式，叫做JSONP，它的基本原理是：跨域的「資源嵌入」是被瀏覽器允許的。所以，可以通過一個script標簽來嵌入一段來自其他伺服器的腳本。由於這個腳本完全運行在當前域，無法訪問第三方伺服器的cookie等敏感信息，所以是安全的。

JSONP的缺點是它只能支持GET操作，沒法支持POST等操作，但是由於兼容性好等優點，仍然有很多網站採用JSONP的方式公開自己的API供第三方調用。

在Angular中，$http內置了對JSONP的支持，它的調用介面也和其他方法沒什麼區別，使用起來非常簡單。

反向代理方式

要想解決跨域問題，最簡單徹底的方法當然是把他們拉到一個域下，而這就是該「反向代理」發揮作用的時候了。

所謂反向代理，就是在自己的域名下架設一個Web伺服器，這個伺服器會把請求轉發給第三方伺服器，然後把結果返回給客戶端。

這時候，在客戶端看來，自己就是在和這台反向代理伺服器打交道，而不知道第三方伺服器的存在。

所以，如果有一個Web服務程序，它同時提供了反向代理功能和靜態文件服務功能，靜態文件服務負責渲染前端頁面，反向代理則提供對第三方伺服器的透明訪問。那麼前端和後端就變成了同源的，不再受同源策略的約束。

那麼，有這樣的Web服務程序嗎？有，而且不止一個。事實上，幾乎所有的主流Web伺服器都提供了反向代理功能。這里僅以nginx為例來示範反向代理的配置方式，其他Web伺服器請搜相應的文檔自行研究。

server {

listen 80;

server_name your.domain.name;

location / {

proxy_pass http://localhost:5000/; # 把根路徑下的請求轉發給前端工具鏈（如gulp）打開的開發伺服器，如果是產品環境，則使用root等指令配置為靜態文件伺服器

}

location /api/ {

proxy_pass http://localhost:8080/service/; # 吧 /api 路徑下的請求轉發給真正的後端伺服器

proxy_set_header Host $http_host;  # 把host頭傳過去，後端服務程序將收到your.domain.name，否則收到的是localhost:8080

proxy_cookie_path /api /service;   # 把cookie中的path部分從/api替換成/service

proxy_cookie_domain localhost:8080 your.domain.name; # 把cookie的path部分從localhost:8080替換成your.domain.name

}

}

注意最後這兩句話，由於cookie中存在一個path機制，可以對同一個域下的不同子域進行區分。所以，如果後端所使用的路徑是/service，而前端使用的路徑是/api，那麼前端將不能訪問後端的cookie，這就導致登錄等操作所寫入的cookie無法正常傳入傳出，其表現則是登錄始終沒有效果。cookie的domain機制也是類似的原理。

現實中的後端伺服器，使用path機制的很多，所以這項設置非常實用。

CORS方式

這是W3C提供的另一種跨域方式。作為一項標準的跨域規范，CORS本應該是最值得採用的。 問題在於，老式瀏覽器不支持CORS，而我們顯然還沒到可以無視老式瀏覽器的時候。 所以，只要有可能，就應該優先採用反向代理的方式。

CORS的原理是基於服務方授權的模式，也就是說提供服務的程序要主動通過CORS回應頭來聲明自己信任哪些源（協議+域名+埠）。 由於得到了服務方的授權，瀏覽器就可以放行來自這些域的請求了。

參考：http://www.cnblogs.com/mashch/articles/4261448.html

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

http://www.tuicool.com/articles/3q2iaqb

前後台分離，nodeJS轉發請求實現跨域訪問 ：http://blog.csdn.net/u011783224/article/details/52214949

B. 前後端分離的前端是怎麼部署到生產環境中的，直接通過 nginx 嗎

front-end-separate(前後端分離腳手架)

front-end-separate
一個前後端分離的腳手架工具（自主研發）
為什麼選擇grunt而不是gulp
如果你也和我一樣喜歡grunt這種配置的方式，那麼我相信這個腳手架覺對十分適合你
所有靜態資源都md5全並壓縮打包,css,js,img,html
已在生產環境驗證
基於express和grunt的前後端分離框架
模板引擎使用的是nunjucks，好處是可以實現模版繼承，又不像jade一樣把html標簽都簡化了
express提供路由服務
項目中app為原代碼文件（開發用），dist為打包後的文件（用於線上）
開發使用app，線上使用dist，支持一鍵cdn部署，加速你的項目
項目啟動時，修改任何express代碼，可以實現自動重啟–基於nodemon
支持sass圖片精靈（自動打包精靈圖片，再也不用手動去拼湊了）
基於grunt md5 打包合並
線上輸出的html已經壓縮成一行（讓你的代碼更有Geeker范）

C. web 前後端分離 伺服器該如何選擇

前端 和後端 分離 最好 再加一台資料庫 總共3台伺服器 再同一個內網。

前端和後端和資料庫 都分離開。 然後資料庫只對前端和後端 通信

D. 如何使用webpack，proxy實現前後端分離，並且方便後期前後端聯調

分離的痛點是分離後，介面提供不及時，文檔不完善，模擬數據不方便等。說一下我們的解決辦法：
1）webpack設置proxy，這個通過webpack文檔或GOOGLE一下可以解決。
2）第二步就是需要在後端提供介面及數據和介面文檔，而因為前後端很可能是並行開發的，所以在真實介面出來之前需要前端模擬介面及數據，及數據文檔然後在真實介面出來後，切換到真實介面調試，我們之前也遇到過此問題，所以抽時間自己做了個mocksever 系統，功能包括:
支持可視化編輯JSON介面數據及介面文檔

支持GET、POST、PUT、DELETE請求類型

支持指定返回狀態碼，默認200

支持延時返回數據

支持mockjs

支持單個介面代理到真實伺服器(開發過程中某個介面使用模擬數據,當此介面已開發完成後,可將指定介面,通過此服務指向到真實介面上)

E. 前後端分離架構到底怎麼該搭建

tokenbasedauthentication後端還是要有session的，只不過是可能需要自己實現，如果通過token進行身份標識的話；用cookie也可以；

F. ASP.NET開發如何做到前後端分離

如果使用webform這種形式的開發，必須使用伺服器控制項，控制項都是runat=server。這樣的形式就是前後台不分離的
使用htm + ajax +jquery 前端和js框架，後台使用一般處理程序或者mvc的形式就可以做到，前端的處理和後台的處理無太大的關系

G. 前後端分離方案以及技術選型

作者：關開發

一.什麼是前後端分離？

理解前後端分離大概可以從3個方面理解：

1. 交互形式

2. 代碼組織形式

3. 開發模式與流程

1.1 交互形式

前後端不分離

後端將數據和頁面組裝、渲染好了之後，向瀏覽器輸出最終的html；瀏覽器接收到後會解析html，解析引入的css、執行js腳本，完成最終的頁面展示。

前後端分離

後端只需要和前端約定好接收以及返回的數據格式（一般用JSON格式），向前端提供API介面。前端就可以通過HTTP請求調用API的方式進行交互。前端獲取到數據後，進行頁面組裝、渲染，最終在瀏覽器呈現。

1.2 代碼組織形式

前後端不分離

在web應用早期的時候，前端頁面以及後台業務數據處理的代碼都放在一個工程下，甚至放在同一目錄下，前端頁面夾雜著後端代碼。前、後端開發工程師都需要把整套代碼導入開發工具才能開發。此階段下前後端代碼以及工作耦合度太高，前端不能獨立開發和測試，後端人員也要依賴前端完成頁面後才能完成開發。最糟糕的情況是前端工程師需要會後端模板技術（jsp），後端工程師還要會點前端技術，需要口頭說明頁面數據介面，才能配合完成開發。否則前端只能當一個「切圖仔」，只輸出HTML、CSS、以及很少量與業務邏輯無關的js；然後由後端轉化為後端jsp，並且還要寫業務的js代碼。

前後端分離

前後端代碼放在不同的工程下，前端代碼可以獨立開發，通過mock/easy-mock技術模擬後端API服務可以獨立運行、測試；後端代碼也可以獨立開發，運行、測試，通過swagger技術能自動生成API文檔供前端閱讀，還可以進行自動化介面測試，保證API的可用性，降低集成風險。

1.3 開發模式與流程

前後端不分離

在項目開發階段，前端根據原型和UI設計稿，編寫HTML、CSS以及少量與業務無關的js（純效果那些），完成後交給後台人員，後台人員將HTML轉為jsp，並通過JSP的模板語法進行數據綁定以及一些邏輯操作。後台完成後，將全部代碼打包，包含前端代碼、後端代碼打成一個war，然後部署到同一台伺服器運行。頂多做一下動靜分離，也就是把圖片、css、js分開部署到nginx。

具體開發流程如下：圖略

前後端分離

實現前後端分離之後，前端根據原型和UI設計稿編寫HTML、CSS以及少量與業務無關的js（純效果那些），後端也同時根據原型進行API設計，並與前端協定API數據規范。等到後台API完成，或僅僅是API數據規范設定完成之後。前端即可通過HTTP調用API，或通過mock數據完成數據組裝以及業務邏輯編寫。前後端可以並行，或者前端先行於後端開發了。

具體開發流程如下：圖略

二、前後端分離的好處與壞處。

從上面3個方面對比了之後，前後端分離架構和傳統的web架構相比，有很大的變化，看起來好處多多。到底是分還是不分，我們還是要理性分析是否值得才去做。

從目前應用軟體開發的發展趨勢來看，主要有兩方面需要注意：

· 越來越注重用戶體驗，隨著互聯網的發展，開始多終端化。

· 大型應用架構模式正在向雲化、微服務化發展。

我們主要通過前後端分離架構，為我們帶來以下四個方面的提升：

· 為優質產品打造精益團隊

通過將開發團隊前後端分離化，讓前後端工程師只需要專注於前端或後端的開發工作，是的前後端工程師實現自治，培養其獨特的技術特性，然後構建出一個全棧式的精益開發團隊。

· 提升開發效率

前後端分離以後，可以實現前後端代碼的解耦，只要前後端溝通約定好應用所需介面以及介面參數，便可以開始並行開發，無需等待對方的開發工作結束。與此同時，即使需求發生變更，只要介面與數據格式不變，後端開發人員就不需要修改代碼，只要前端進行變動即可。如此一來整個應用的開發效率必然會有質的提升。

· 完美應對復雜多變的前端需求

如果開發團隊能完成前後端分離的轉型，打造優秀的前後端團隊，開發獨立化，讓開發人員做到專注專精，開發能力必然會有所提升，能夠完美應對各種復雜多變的前端需求。

· 增強代碼可維護性

前後端分離後，應用的代碼不再是前後端混合，只有在運行期才會有調用依賴關系。應用代碼將會變得整潔清晰，不論是代碼閱讀還是代碼維護都會比以前輕松。

那麼前後端分離有什麼不好的地方嗎？我目前是沒有想到，除非你說會增加前端團隊的配備，後端工程師會變的不全能。。。

二、前後端分離架構方案。

實現前後端分離，主要是前端的技術架構變化較大，後端主要變為restfull 風格API，然後加上Swagger技術自動生成在線介面文檔就差不多了。

對於目前用於前後端分離方案的前端技術架構主要有兩種：

· 傳統SPA

· 服務端渲染SSR

2.1 傳統SPA

傳統SPA指的是單頁面應用，也就是整個網站只有一個頁面，所有功能都通過這一個頁面來呈現。因為一個人的肉眼，某一個時間點看一個頁面，既然如此何必要不同功能做多個頁面呢？只保留一個頁面作為模板，然後通過路由跳轉來更新這個模板頁面的內容不就可以了嗎？確實如此，現在通過reac全家桶、tvue全家桶，模塊化、路由、wabpack等技術輕而易舉就能實現一個單頁面應用。

單頁面應用的運行流程

1.用戶通過瀏覽器訪問網站url

2.單頁面的html文件（index.html）被下載到瀏覽器，接著下載html裡面引用的css，js。

3.css，js下載到瀏覽器完成之後，瀏覽器開始解析執行js向後端服務非同步請求數據。

4.請求數據完成後，進行數據綁定、渲染，最終在用戶瀏覽器呈現完整的頁面。

2.2 服務端渲染

服務端渲染的方案指的是數據綁定，渲染等工作都放在服務端完成，服務端向瀏覽器輸出最終的html。大家看完這個是不是有個疑問，這不是又回到了前後端不分離的時代了嗎？答案是否定的，因為這里的服務端是用來執行前端數據綁定、渲染的，也就是把瀏覽器的一部分工作分擔到了服務端。而目前具備這只種能力的服務端是NodeJs服務端。

它的原理其實就是在瀏覽器與前端代碼中間插入了一個NodeJs服務端。瀏覽器請求前端頁面時，會先經過NodeJS服務端，由NodeJs去讀取前端頁面，並執行非同步後端API，獲取到數據後進行頁面數據綁定，渲染等工作，完成一個最終的html然後返回瀏覽器，最後瀏覽器進行展示。

服務端渲染應用的運行流程：

1.用戶通過瀏覽器訪問網站url

2.NodeJS服務端接收到請求，讀取到對應的前端html，css，js。

3.NodeJS解析執行js向後端API非同步請求數據。

4.NodeJs請求數據完成之後，進行數據綁定、渲染，得到一個最終的html。

5.NodeJs向瀏覽器輸出html，瀏覽器進行展示。

PS：其實本質就是把前端編寫成一個nodeJs的服務端web應用。實施服務端渲染後，我們最終運行的是一個Nodejs服務端應用。而單頁面應用是把靜態頁面部署到靜態資源伺服器進行運行。

看到這里，你是否又有疑問，為什麼要這么麻煩搞服務端渲染呢？

2.3 SPA與服務端渲染方案對比

SPA的優點是開發簡單，部署簡單；缺點是首次載入較慢，需要較好的網路，不友好的SEO。

so，以下就是使用服務端渲染的理由了（摘取vue官方說法）：

與傳統 SPA (單頁應用程序 (Single-Page Application)) 相比，伺服器端渲染 (SSR) 的優勢主要在於：

· 更好的 SEO，由於搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁面。

請注意，截至目前，Google 和 Bing 可以很好對同步 javaScript 應用程序進行索引。在這里，同步是關鍵。如果你的應用程序初始展示 loading 菊花圖，然後通過 Ajax 獲取內容，抓取工具並不會等待非同步完成後再行抓取頁面內容。也就是說，如果 SEO 對你的站點至關重要，而你的頁面又是非同步獲取內容，則你可能需要伺服器端渲染(SSR)解決此問題。

· 更快的內容到達時間 (time-to-content)，特別是對於緩慢的網路情況或運行緩慢的設備。

無需等待所有的 JavaScript 都完成下載並執行，才顯示伺服器渲染的標記，所以你的用戶將會更快速地看到完整渲染的頁面。通常可以產生更好的用戶體驗，並且對於那些「內容到達時間(time-to-content) 與轉化率直接相關」的應用程序而言，伺服器端渲染 (SSR) 至關重要。

使用伺服器端渲染 (SSR) 時還需要有一些權衡之處：

· 開發條件所限。瀏覽器特定的代碼，只能在某些生命周期鉤子函數 (lifecycle hook) 中使用；一些外部擴展庫 (external library) 可能需要特殊處理，才能在伺服器渲染應用程序中運行。

· 涉及構建設置和部署的更多要求。與可以部署在任何靜態文件伺服器上的完全靜態單頁面應用程序 (SPA) 不同，伺服器渲染應用程序，需要處於 Node.js server 運行環境。

· 更多的伺服器端負載。在 Node.js 中渲染完整的應用程序，顯然會比僅僅提供靜態文件的 server 更加大量佔用 CPU 資源 (CPU-intensive - CPU 密集)，因此如果你預料在高流量環境 (high traffic) 下使用，請准備相應的伺服器負載，並明智地採用緩存策略。

以vue為例，實施服務端渲染可以查看官方指南： https://ssr.vuejs.org ，或選擇Nuxt.js

2.4 預渲染技術

如果你調研伺服器端渲染 (SSR) 只是用來改善少數營銷頁面（例如 /, /about, /contact 等）的 SEO，那麼你可能需要預渲染。無需使用 web 伺服器實時動態編譯 HTML，而是使用預渲染方式，在構建時 (build time) 簡單地生成針對特定路由的靜態 HTML 文件。優點是設置預渲染更簡單，並可以將你的前端作為一個完全靜態的站點。

如果你使用 webpack，你可以使用 prerender-spa-plugin 輕松地添加預渲染。它已經被 Vue 應用程序廣泛測試 - 事實上，作者是 Vue 核心團隊的成員。

prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin

三、前後端分離技術選型

- artTemplate + bootstrap（不推薦， 不算完全前後端分離）

- vue全家桶（推薦）

- react全家桶 （推薦，生態全）

H. 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，多線程，分布式架構（bbo，bbox，spring cloud），彈性計算架構，微服務架構（springboot+zookeeper+docker+jenkins），java性能優化，以及相關的項目管理等等。

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

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

補充兩點

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

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

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

在開發中大型的JavaEE項目時，前後端分離的框架逐漸成為業界的主流，傳統的單機部署前後端在同一個項目中的工程項目越來越少。這類JavaWeb項目的後端通常都採用微服務的架構，後端會被分解為諸多個小項目，然後使用bbo+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 http://tomcat_pool; 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:Workspacesesop-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中運行即可。

J. VB.Net 前後端分離怎麼實現的

1.一般來說，要實現前後端分離，前端就需要開啟一個本地的伺服器來運行自己的前端代碼，以此來模擬真實的線上環境，並且，也是為了更好的開發。因為你在實際開發中，你不可能要求每一個前端都去搭建一個java(php)環境，並且在java環境下開發，這對於前端來說，學習成本太高了。
?2.但如果本地沒有開啟伺服器的話，不僅無法模擬線上的環境，而且還面臨到了跨域的問題，因為你如果寫靜態的html頁面，直接在文件目錄下打開的話，你是無法發出ajax請求的(瀏覽器跨域的限制),因此，你需要在本地運行一個伺服器，可是又不想搭建陌生而龐大的java環境，怎麼辦法呢？nodejs正好解決了這個問題。在我們項目中，我們利用nodejs的express框架來開啟一個本地的伺服器，然後利用nodejs的一個http-proxy-middleware插件將客戶端發往nodejs的請求轉發給真正的伺服器，讓nodejs作為一個中間層。這樣，前端就可以無憂無慮的開發了
?3.由於前後端分離後，前端和後台同時開發時，就可能遇到前端已經開發好一個頁面了，可是卻等待後台API介面的情況。比如說A是負責前端，B是負責後台，A可能用了一周做好了基本的結構，並且需要API介面聯調後，才能繼續開發，
?4.而此時B卻還沒有實現好所需要的介面，這種情況，怎麼辦呢？在我們這個項目里，我們是通過了mock來提供一些假數據，我們先規定好了API介面，設計出了一套API文檔，然後我們就可以通過API文檔，利用mock來返回一些假數據，這樣就可以模擬發送API到接受響應的整一個過程，
?5.因此前端也不需要依賴於後端開發了，可以獨立開發，等到後台的API全部設計完之後，就可以比較快速的聯調。