前端不能讀配置文件嗎

nginx如何配置靜態頁面

首先nginx安裝好之後的預設配置文件：nginx/conf/nginx.conf

這里定義的root地址是相對於nginx的根路徑的；那麼當用戶通過瀏覽器訪問根地址:;hostname:port時，nginx試圖返回的頁面就是：nginx/html/index.html。

當然這里root也可以寫全路徑，例如/home/username/tools/nginx/html，效果是一樣的。

這里我們要討論如何把一個靜態頁面配置到nginx裡面。

假設靜態頁面內容放在文件夾/app/testapp/www下面(同時假設/app/testapp/www/index.html也存在)，我們如何配置nginx使得;hostname:port/做握亂testapp能夠訪問到這些靜態頁面內容呢。

結果：404NotFound

查看nginx日誌(nginx/logs/error.log)：

原來nginx試圖訪問的文件路徑是：/app/testapp/www/testapp，這個路徑是」root「的內容再拼上location的值組成的；那我們給修改location和root的值：純檔

然後通過地址;hostname:port/www就可以訪問了；但是這里location必須用」www「不能用」皮喊testapp「，這就非常不可接受了，解決的辦法可以是修改靜態頁面的地址，再加一層testapp路徑，例如："/app/testapp/www/testapp"，然後再配置：

這樣是可以的。另一個方法是採用alias取代root。

保留今天頁面的地址"/app/testapp/www"，配置nginx的配置文件：

關於alias和root的區別，請查閱nginx文檔或者自行google，這里不再重復貼了。

nginx現在幾乎是眾多大型網站的必用技術，大多數情況下，我們不需要親自去配置它，但是了解它在應用程序中所擔任的角色，以及如何解決這些問題是非常必要的。

下面我將從nginx在企業中的真實應用來解釋nginx在應用程序中起到的作用。

為了便於理解，首先先來了解一下一些基礎知識，nginx是一個高性能的反向代理伺服器那麼什麼是反向代理呢？

代理是在伺服器和客戶端之間假設的一層伺服器，代理將接收客戶端的請求並將它轉發給伺服器，然後將服務端的響應轉發給客戶端。

不管是正向代理還是反向代理，實現的都是上面的功能。

正向代理是為我們服務的，即為客戶端拆逗雀服務的，客戶端可以根據正向代理訪問到它本身無法訪問到的伺服器資源。

正向代理對我們是透明的，對服務端是非透明的，即旅早服務端並不知道自己收到的是來自代理的訪問還是來自真實客戶端的訪問。

反向代理是為服務端服務的，反向代理可以幫助伺服器接收來自客戶端的請求，幫助伺服器做請求轉發，負載均衡等。

反向代理對服務端是透明的，對我們是非透明的，即我們並不知道自己訪問的是代理伺服器，而伺服器知道反向代理在為他服務。

下面是一個nginx配置文件的基本結構：

下面是nginx一些配置中常用的內置全局變數，你可以在配置的任何位置使用它們。

|變數名|功能||------|------||$host|請求信息中的Host，如果請求中沒有Host行，則等於設置的伺服器名||$request_method|客戶端請求類型，如GET、POST|$remote_addr|客戶端的IP地址||$args|請求中的參數||$content_length|請求頭中的Content-length欄位||$http_user_agent|客戶端agent信息||$http_cookie|客戶端cookie信息||$remote_addr|客戶端的IP地址||$remote_port|客戶端的埠||$server_protocol|請求使用的協議，如HTTP/1.0、·HTTP/1.1||server_name|伺服器名稱||$server_port`|伺服器的埠號|

先追本溯源以下，跨域究竟是怎麼回事。

同源策略限制了從同一個源載入的文檔或腳本如何與來自另一個源的資源進行交互。這是一個用於隔離潛在惡意文件的重要安全機制。通常不允許不同源間的讀操作。

如果兩個頁面的協議，埠（如果有指定）和域名都相同，則兩個頁面具有相同的源。

例如：

現在我在fe.server.com對dev.server.com發起請求一定會出現跨域。

現在我們只需要啟動一個nginx伺服器，將server_name設置為fe.server.com,然後設置相應的location以攔截前端需要跨域的請求，最後將請求代理回dev.server.com。如下面的配置：

這樣可以完美繞過瀏覽器的同源策略：fe.server.com訪問nginx的fe.server.com屬於同源訪問，而nginx對服務端轉發的請求不會觸發瀏覽器的同源策略。

根據狀態碼過濾

根據URL名稱過濾，精準匹配URL，不匹配的URL全部重定向到主頁。

根據請求類型過濾。

GZIP是規定的三種標指廳准HTTP壓縮格式之一。目前絕大多數的網站都在使用GZIP傳輸HTML、CSS、JavaScript等資源文件。

對於文本文件，GZip的效果非常明顯，開啟後傳輸所需流量大約會降至1/4~1/3。

並不是每個瀏覽器都支持gzip的，如何知道客戶端是否支持gzip呢，請求頭中的Accept-Encoding來標識對壓縮的支持。

啟用gzip同時需要客戶端和服務端的支持，如果客戶端支持gzip的解析，那麼只要服務端能夠返回gzip的文件就可以啟用gzip了,我們可以通過nginx的配置來讓服務端支持gzip。下面的respone中content-encoding:gzip，指服務端開啟了gzip的壓縮方式。

這里為什麼默認版本不是1.0呢？

HTTP運行在TCP連接之上，自然也有著跟TCP一樣的三次握手、慢啟動等特性。

啟用持久連接情況下，伺服器發出響應後讓TCP連接繼續打開著。同一對客戶/伺服器之間的後續請求和響應可以通過這個連接發送。

為了盡可能的提高HTTP性能，使用持久連接就顯得尤為重要了。

HTTP/1.1默認支持TCP持久連接，HTTP/1.0也可以通過顯式指定Connection:keep-alive來啟用持久連接。對於TCP持久連接上的HTTP報文，客戶端需要一種機制來准確判斷結束位置，而在HTTP/1.0中，這種機制只有Content-Length。而在HTTP/1.1中新增的Transfer-Encoding:chunked所對應的分塊傳輸機制可以完美解決這類問題。

nginx同樣有著配置chunked的屬性chunked_transfer_encoding，這個屬性是默認開啟的。

Nginx在啟用了GZip的情況下，不會等文件GZip完成再返回響應，而是邊壓縮邊響應，這樣可以顯著提高TTFB(TimeToFirstByte，首位元組時間，WEB性能優化重要指標)。這樣唯一的問題是，Nginx開始返回響應時，它無法知道將要傳輸的文件最終有多大，也就是無法給出Content-Length這個響應頭部。

所以，在HTTP1.0中如果利用Nginx啟用了GZip，是無法獲得Content-Length的，這導致HTTP1.0中開啟持久鏈接和使用GZip只能二選一，所以在這里gzip_http_version默認設置為1.1。

如上面的圖，前面是眾多的服務窗口，下面有很多用戶需要服務，我們需要一個工具或策略來幫助我們將如此多的用戶分配到每個窗口，來達到資源的充分利用以及更少的排隊時間。

把前面的服務窗口想像成我們的後端伺服器，而後面終端的人則是無數個客戶端正在發起請求。負載均衡就是用來幫助我們將眾多的客戶端請求合理的分配到各個伺服器，以達到服務端資源的充分利用和更少的請求時間。

Upstream指定後端伺服器地址列表

在server中攔截響應請求，並將請求轉發到Upstream中配置的伺服器列表。

上面的配置只是指定了nginx需要轉發的服務端列表，並沒有指定分配策略。

輪詢策略

默認情況下採用的策略，將所有客戶端請求輪詢分配給服務端。這種策略是可以正常工作的，但是如果其中某一台伺服器壓力太大，出現延遲，會影響所有分配在這台伺服器下的用戶。

最小連接數策略

將請求優先分配給壓力較小的伺服器，它可以平衡每個隊列的長度，並避免向壓力大的伺服器添加更多的請求。

最快響應時間策略

依賴於NGINXPlus，優先分配給響應時間最短的伺服器。

客戶端ip綁定

來自同一個ip的請求永遠只分配一台伺服器，有效解決了動態網頁存在的session共享問題。

匹配以png|gif|jpg|jpeg為結尾的請求，並將請求轉發到本地路徑，root中指定的路徑即nginx本地路徑。同時也可以進行一些緩存的設置。

nginx的功能非常強大，還有很多需要探索，上面的一些配置都是公司配置的真實應用（精簡過了），如果您有什麼意見或者建議，歡迎在下方留言...

B. 原來前端部署這么簡單

前端部署並不簡單，但遵循一定步驟可以完成。以下是從零開始部署前端項目的全過程：

1. 環境搭建：

   • 伺服器：可以通過遠程工具連接到已有的伺服器，或者通過VMWare軟體搭建虛擬機作為伺服器。
   • 虛擬機設置：在VMWare中新建虛擬機，並按照提示設置用戶名和密碼。注意，如果啟動過程中出現Intel VTx禁用的提示，需要進入BIOS設置開啟對應選項。

2. 網路配置：

   • 打開虛擬機的虛擬網路編輯器，查詢並配置IP，確保子網IP和網關IP的網段與本地電腦一致。
   • 選擇設置了Nat模式的網卡，通過命令行查看虛擬機的IP地址。

3. 遠程連接：

   • 使用遠程工具通過IP地址、用戶名和密碼連接到虛擬機。

4. 資源部署：

   • 將打包好的前端資源上傳到伺服器的指定路徑。

5. nginx配置：

   • 安裝nginx並啟動。
   • 修改nginx的配置文件，主要配置location路徑，將其映射到前端資源路徑。
   • 修改完成後重啟nginx。

6. 訪問驗證：

   • 通過瀏覽器訪問虛擬機的IP地址，驗證前端項目是否成功部署。

重點內容： 環境搭建是部署前端項目的基礎，包括伺服器和虛擬機的設置。 網路配置需要確保虛擬機與本地電腦的網路環境一致，以便進行遠程連接和資源訪問。 nginx配置是實現前端資源映射的關鍵步驟，需要正確配置location路徑。

遵循以上步驟，可以完成前端項目的部署。但需要注意的是，每個步驟都可能遇到各種問題，需要具備一定的技術能力和耐心去解決。因此，前端部署並不簡單，需要認真對待。

C. 《若依ruoyi》第五章：Ruoyi系統spring boot啟動配置文件說明

《若依ruoyi》第五章：Ruoyi系統spring boot啟動配置文件說明

• 配置文件概述：

  • 默認配置文件：構建完Spring Boot項目後，默認會在resources目錄下提供application.properties文件，該文件通常為空，因為Spring Boot底層已自動配置所有設置。
  • 文件名與格式：文件名可以固定為application.properties，亦可改為application.yml。兩者在本質上相同，僅語法略有差異。application.yml文件採用YAML語言編寫，更適合作為配置文件。

• 啟動類與自動裝配：

  • 啟動類位置：啟動類RuoYiApplication位於com.ruoyi包中。
  • 自動掃描與裝配：Spring Boot啟動時會自動掃描com.ruoyi及其子包中的註解，實現自動裝配。

• 配置文件讀取與web設置：

  • 配置文件讀取：Spring Boot啟動後，首先讀取配置文件application.yml。
  • web監聽埠：配置文件中包含設置啟動的web監聽埠的片段。
  • web容器配置：配置使用web容器，並指定使用tomcat作為容器啟動。

• 環境配置分離：

  • profiles:active參數：配置文件中包含profiles:active參數，用於生產環境和測試環境的配置分離。
  • 附加配置文件讀取：Spring Boot除了讀取application.yml文件，還會根據profiles:active值讀取對應的附加配置文件，如applicationdruid.yml。

• redis配置：

  • redis用途：若依系統使用redis作為登錄會話緩存。
  • redis部署與指向：需部署redis，並在配置文件中指向部署的redis伺服器。

• token配置：

  • token用途：涉及前端與後端通信過程中的用戶登錄信息唯一標識。
  • token業務流程：包括用戶前端登錄、介面服務驗證賬號密碼、token寫入redis並返回、前端存儲token等步驟。
  • token存儲與有效期：token存儲在header的Authorization欄位內，有效期為30分鍾，過期需重新登錄。

• MyBatis配置：

  • typeAliasesPackage：允許通過全類名指定mapper.xml文件中的resultType或paramterType返回的自定義實體。通過typealiasespackage指定實體掃描包，MyBatis會自動掃描自定義實體。
  • mapperLocations：用於配置MyBatis掃描的目錄，掃描該目錄下的所有xml文件。

• 數據源配置：

  • 數據源配置文件：位於applicationdruid.yml。
  • 資料庫賬號與密碼：需根據實際需求修改資料庫賬號和密碼。