(三)Nginx一網打盡:動靜分離、壓縮、快取、黑白名單、跨域、高可用、效能優化...想要的這都有!

語言: CN / TW / HK

引言

   在上文《HTTP/HTTPS》中曾談到了代理伺服器的概念,其主要作用之一就是用於負載均衡與請求分發,那麼先來看看為何需要做請求負載。

   早期的業務都是基於單體節點部署,由於前期訪問流量不大,因此單體結構也可滿足需求,但隨著業務增長,流量也越來越大,那麼最終單臺伺服器受到的訪問壓力也會逐步增高。時間一長,單臺伺服器效能無法跟上業務增長,就會造成線上頻繁宕機的現象發生,最終導致系統癱瘓無法繼續處理使用者的請求。

從上面的描述中,主要存在兩個問題:
①單體結構的部署方式無法承載日益增長的業務流量。
②當後端節點宕機後,整個系統會陷入癱瘓,導致整個專案不可用。

因此在這種背景下,引入負載均衡技術可帶來的收益:
- 系統的高可用:當某個節點宕機後可以迅速將流量轉移至其他節點。 - 系統的高效能:多臺伺服器共同對外提供服務,為整個系統提供了更高規模的吞吐。 - 系統的拓展性:當業務再次出現增長或萎靡時,可再加入/減少節點,靈活伸縮。

   OK~,既然引入負載均衡技術可給我們帶來如此巨大的好處,那麼又有那些方案可供選擇呢?主要有兩種負載方案,硬體層面與軟體層面,比較常用的硬體負載器有A10、F5等,但這些機器動輒大幾萬乃至幾十萬的成本,因此一般大型企業會採用該方案,如銀行、國企、央企等。
   而成本有限,但依舊想做負載均衡的專案,那麼可在軟體層面實現,如典型的Nginx等,軟體層的負載也是本文的重點,畢竟Boss們的準則之一就是:能靠技術實現的就儘量不花錢。

當然,如果你認為本文對你而言有幫助,記得點贊、收藏、關注三連噢!

一、效能怪獸-Nginx概念深入淺出

   Nginx是目前負載均衡技術中的主流方案,幾乎絕大部分專案都會使用它,Nginx是一個輕量級的高效能HTTP反向代理伺服器,同時它也是一個通用型別的代理伺服器,支援絕大部分協議,如TCP、UDP、SMTP、HTTPS等。
Nginx-LOGO
   Nginx與之前談及的《Redis》相同,都是基於多路複用模型構建出的產物,因此它與Redis同樣具備資源佔用少、併發支援高的特點,在理論上單節點的Nginx同時支援5W併發連線,而實際生產環境中,硬體基礎到位再結合簡單調優後確實能達到該數值。

先來看看Nginx引入前後,客戶端請求處理流程的對比:
Nginx前後區別
   原本客戶端是直接請求目標伺服器,由目標伺服器直接完成請求處理工作,但加入Nginx後,所有的請求會先經過Nginx,再由其進行分發到具體的伺服器處理,處理完成後再返回Nginx,最後由Nginx將最終的響應結果返回給客戶端。

瞭解了Nginx的基本概念後,再來快速搭建一下環境,以及瞭解一些Nginx的高階特性,如動靜分離、資源壓縮、快取配置、IP黑名單、高可用保障等。

二、Nginx環境搭建

❶首先建立Nginx的目錄並進入: shell [[email protected]]# mkdir /soft && mkdir /soft/nginx/ [[email protected]]# cd /soft/nginx/

❷下載Nginx的安裝包,可以通過FTP工具上傳離線環境包,也可通過wget命令線上獲取安裝包:
shell [[email protected]]# wget https://nginx.org/download/nginx-1.21.6.tar.gz 沒有wget命令的可通過yum命令安裝:
shell [[email protected]]# yum -y install wget

❸解壓Nginx的壓縮包: shell [[email protected]]# tar -xvzf nginx-1.21.6.tar.gz

❹下載並安裝Nginx所需的依賴庫和包:
shell [[email protected]]# yum install --downloadonly --downloaddir=/soft/nginx/ gcc-c++ [[email protected]]# yum install --downloadonly --downloaddir=/soft/nginx/ pcre pcre-devel4 [[email protected]]# yum install --downloadonly --downloaddir=/soft/nginx/ zlib zlib-devel [[email protected]]# yum install --downloadonly --downloaddir=/soft/nginx/ openssl openssl-devel 也可以通過yum命令一鍵下載(推薦上面哪種方式):
shell [[email protected]]# yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel 執行完成後,然後ls檢視目錄檔案,會看一大堆依賴:
Nginx-依賴包
緊接著通過rpm命令依次將依賴包一個個構建,或者通過如下指令一鍵安裝所有依賴包:
shell [[email protected]]# rpm -ivh --nodeps *.rpm

❺進入解壓後的nginx目錄,然後執行Nginx的配置指令碼,為後續的安裝提前配置好環境,預設位於/usr/local/nginx/目錄下(可自定義目錄):
shell [[email protected]]# cd nginx-1.21.6 [[email protected]]# ./configure --prefix=/soft/nginx/

❻編譯並安裝Nginxshell [[email protected]]# make && make install

❼最後回到前面的/soft/nginx/目錄,輸入ls即可看見安裝nginx完成後生成的檔案。

❽修改安裝後生成的conf目錄下的nginx.conf配置檔案:
shell [[email protected]]# vi conf/nginx.conf 修改埠號:listen 80; 修改IP地址:server_name 你當前機器的本地IP(線上配置域名);

❾制定配置檔案並啟動Nginx
shell [[email protected]]# sbin/nginx -c conf/nginx.conf [[email protected]]# ps aux | grep nginx Nginx其他操作命令: shell sbin/nginx -t -c conf/nginx.conf # 檢測配置檔案是否正常 sbin/nginx -s reload -c conf/nginx.conf # 修改配置後平滑重啟 sbin/nginx -s quit # 優雅關閉Nginx,會在執行完當前的任務後再退出 sbin/nginx -s stop # 強制終止Nginx,不管當前是否有任務在執行

❿開放80埠,並更新防火牆: shell [[email protected]]# firewall-cmd --zone=public --add-port=80/tcp --permanent [[email protected]]# firewall-cmd --reload [[email protected]]# firewall-cmd --zone=public --list-ports

⓫在Windows/Mac的瀏覽器中,直接輸入剛剛配置的IP地址訪問Nginx
歡迎介面
最終看到如上的Nginx歡迎介面,代表Nginx安裝完成。

三、Nginx反向代理-負載均衡

   首先通過SpringBoot+Freemarker快速搭建一個WEB專案:springboot-web-nginx,然後在該專案中,建立一個IndexNginxController.java檔案,邏輯如下:
```java @Controller public class IndexNginxController { @Value("${server.port}") private String port;

@RequestMapping("/")
public ModelAndView index(){
    ModelAndView model = new ModelAndView();
    model.addObject("port", port);
    model.setViewName("index");
    return model;
}

} `` 在該Controller類中,存在一個成員變數:port,它的值即是從application.properties配置檔案中獲取server.port值。當出現訪問/資源的請求時,跳轉前端index`頁面,並將該值攜帶返回。

前端的index.ftl檔案程式碼如下:
html <html> <head> <title>Nginx演示頁面</title> <link href="nginx_style.css" rel="stylesheet" type="text/css"/> </head> <body> <div style="border: 2px solid red;margin: auto;width: 800px;text-align: center"> <div id="nginx_title"> <h1>歡迎來到熊貓高階會所,我是竹子${port}號!</h1> </div> </div> </body> </html> 從上可以看出其邏輯並不複雜,僅是從響應中獲取了port輸出。

OK~,前提工作準備就緒後,再簡單修改一下nginx.conf的配置即可: ```shell upstream nginx_boot{ # 30s內檢查心跳傳送兩次包,未回覆就代表該機器宕機,請求分發權重比為1:2 server 192.168.0.000:8080 weight=100 max_fails=2 fail_timeout=30s; server 192.168.0.000:8090 weight=200 max_fails=2 fail_timeout=30s; # 這裡的IP請配置成你WEB服務所在的機器IP }

server { location / { root html; # 配置一下index的地址,最後加上index.ftl。 index index.html index.htm index.jsp index.ftl; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 請求交給名為nginx_boot的upstream上 proxy_pass http://nginx_boot; } } ```

至此,所有的前提工作準備就緒,緊接著再啟動Nginx,然後再啟動兩個web服務,第一個WEB服務啟動時,在application.properties配置檔案中,將埠號改為8080,第二個WEB服務啟動時,將其埠號改為8090

最終來看看效果:
負載均衡效果-動圖演示
因為配置了請求分發的權重,8080、8090的權重比為2:1,因此請求會根據權重比均攤到每臺機器,也就是8080一次、8090兩次、8080一次......

Nginx請求分發原理

   客戶端發出的請求192.168.12.129最終會轉變為:http://192.168.12.129:80/,然後再向目標IP發起請求,流程如下:
請求分發原理
- 由於Nginx監聽了192.168.12.12980埠,所以最終該請求會找到Nginx程序; - Nginx首先會根據配置的location規則進行匹配,根據客戶端的請求路徑/,會定位到location /{}規則; - 然後根據該location中配置的proxy_pass會再找到名為nginx_bootupstream; - 最後根據upstream中的配置資訊,將請求轉發到執行WEB服務的機器處理,由於配置了多個WEB服務,且配置了權重值,因此Nginx會依次根據權重比分發請求。

四、Nginx動靜分離

   動靜分離應該是聽的次數較多的效能優化方案,那先思考一個問題:為什麼需要做動靜分離呢?它帶來的好處是什麼? 其實這個問題也並不難回答,當你搞懂了網站的本質後,自然就理解了動靜分離的重要性。先來以淘寶為例分析看看:
淘寶首頁
當瀏覽器輸入www.taobao.com訪問淘寶首頁時,開啟開發者除錯工具可以很明顯的看到,首頁載入會出現100+的請求數,而正常專案開發時,靜態資源一般會放入到resources/static/目錄下:
IDEA工程結構
在專案上線部署時,這些靜態資源會一起打成包,那此時思考一個問題:假設淘寶也是這樣乾的,那麼首頁載入時的請求最終會去到哪兒被處理? 答案毋庸置疑,首頁100+的所有請求都會來到部署WEB服務的機器處理,那則代表著一個客戶端請求淘寶首頁,就會對後端伺服器造成100+的併發請求。毫無疑問,這對於後端伺服器的壓力是尤為巨大的。

但此時不妨分析看看,首頁100+的請求中,是不是至少有60+是屬於*.js、*.css、*.html、*.jpg.....這類靜態資源的請求呢?答案是Yes

既然有這麼多請求屬於靜態的,這些資源大概率情況下,長時間也不會出現變動,那為何還要讓這些請求到後端再處理呢?能不能在此之前就提前處理掉?當然OK,因此經過分析之後能夠明確一點:做了動靜分離之後,至少能夠讓後端服務減少一半以上的併發量。 到此時大家應該明白了動靜分離能夠帶來的效能收益究竟有多大。


OK~,搞清楚動靜分離的必要性之後,如何實現動靜分離呢?其實非常簡單,實戰看看。

①先在部署Nginx的機器,Nginx目錄下建立一個目錄static_resources

mkdir static_resources

②將專案中所有的靜態資源全部拷貝到該目錄下,而後將專案中的靜態資源移除重新打包。

③稍微修改一下nginx.conf的配置,增加一條location匹配規則:
shell location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css){ root /soft/nginx/static_resources; expires 7d; } 然後照常啟動nginx和移除了靜態資源的WEB服務,你會發現原本的樣式、js效果、圖片等依舊有效,如下:
移除靜態資源
其中static目錄下的nginx_style.css檔案已被移除,但效果依舊存在(綠色字型+藍色大邊框):
移除後效果動圖

最後解讀一下那條location規則:
location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)
~代表匹配時區分大小寫
.*代表任意字元都可以出現零次或多次,即資源名不限制
\.代表匹配字尾分隔符.
(html|...|css)代表匹配括號裡所有靜態資源型別
綜上所述,簡單一句話概述:該配置表示匹配以.html~.css為字尾的所有資源請求。

最後提一嘴,也可以將靜態資源上傳到檔案伺服器中,然後location中配置一個新的upstream指向。

五、Nginx資源壓縮

   建立在動靜分離的基礎之上,如果一個靜態資源的Size越小,那麼自然傳輸速度會更快,同時也會更節省頻寬,因此我們在部署專案時,也可以通過Nginx對於靜態資源實現壓縮傳輸,一方面可以節省頻寬資源,第二方面也可以加快響應速度並提升系統整體吞吐。

Nginx也提供了三個支援資源壓縮的模組ngx_http_gzip_module、ngx_http_gzip_static_module、ngx_http_gunzip_module,其中ngx_http_gzip_module屬於內建模組,代表著可以直接使用該模組下的一些壓縮指令,後續的資源壓縮操作都基於該模組,先來看看壓縮配置的一些引數/指令:

引數項 | 釋義 | 引數值 :-:|:-:|:-: gzip | 開啟或關閉壓縮機制 | on/off; gzip_types | 根據檔案型別選擇性開啟壓縮機制 | image/png、text/css... gzip_comp_level | 用於設定壓縮級別,級別越高越耗時 | 1~9(越高壓縮效果越好) gzip_vary | 設定是否攜帶Vary:Accept-Encoding頭域的響應頭部 | on/off; gzip_buffers | 設定處理壓縮請求的緩衝區數量和大小 | 數量 大小,如16 8k; gzip_disable | 針對不同客戶端的請求來設定是否開啟壓縮 | 如 .*Chrome.*; gzip_http_version | 指定壓縮響應所需要的最低HTTP請求版本 | 如1.1; gzip_min_length | 設定觸發壓縮的檔案最低大小 | 如512k; gzip_proxied | 對於後端伺服器的響應結果是否開啟壓縮 | off、expired、no-cache...

瞭解了Nginx中的基本壓縮配置後,接下來可以在Nginx中簡單配置一下:
shell http{ # 開啟壓縮機制 gzip on; # 指定會被壓縮的檔案型別(也可自己配置其他型別) gzip_types text/plain application/javascript text/css application/xml text/javascript image/jpeg image/gif image/png; # 設定壓縮級別,越高資源消耗越大,但壓縮效果越好 gzip_comp_level 5; # 在頭部中新增Vary: Accept-Encoding(建議開啟) gzip_vary on; # 處理壓縮請求的緩衝區數量和大小 gzip_buffers 16 8k; # 對於不支援壓縮功能的客戶端請求不開啟壓縮機制 gzip_disable "MSIE [1-6]\."; # 低版本的IE瀏覽器不支援壓縮 # 設定壓縮響應所支援的HTTP最低版本 gzip_http_version 1.1; # 設定觸發壓縮的最小閾值 gzip_min_length 2k; # 關閉對後端伺服器的響應結果進行壓縮 gzip_proxied off; } 在上述的壓縮配置中,最後一個gzip_proxied選項,可以根據系統的實際情況決定,總共存在多種選項: - off:關閉Nginx對後臺伺服器的響應結果進行壓縮。 - expired:如果響應頭中包含Expires資訊,則開啟壓縮。 - no-cache:如果響應頭中包含Cache-Control:no-cache資訊,則開啟壓縮。 - no-store:如果響應頭中包含Cache-Control:no-store資訊,則開啟壓縮。 - private:如果響應頭中包含Cache-Control:private資訊,則開啟壓縮。 - no_last_modified:如果響應頭中不包含Last-Modified資訊,則開啟壓縮。 - no_etag:如果響應頭中不包含ETag資訊,則開啟壓縮。 - auth:如果響應頭中包含Authorization資訊,則開啟壓縮。 - any:無條件對後端的響應結果開啟壓縮機制。

OK~,簡單修改好了Nginx的壓縮配置後,可以在原本的index頁面中引入一個jquery-3.6.0.js檔案: ```html

`` 分別來對比下壓縮前後的區別: ![Nginx壓縮前後區別](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2116205a44c941efb06b8fc95c737a54~tplv-k3u1fbpfcp-watermark.image?) 從圖中可以很明顯看出,未開啟壓縮機制前訪問時,js檔案的原始大小為230K,當配置好壓縮後再重啟Nginx,會發現檔案大小從230KB→69KB`,效果立竿見影!

注意點:
①對於圖片、影片型別的資料,會預設開啟壓縮機制,因此一般無需再次開啟壓縮。
②對於.js檔案而言,需要指定壓縮型別為application/javascript,而並非text/javascript、application/x-javascript

六、Nginx緩衝區

   先來思考一個問題,接入Nginx的專案一般請求流程為:“客戶端→Nginx→服務端”,在這個過程中存在兩個連線:“客戶端→NginxNginx→服務端”,那麼兩個不同的連線速度不一致,就會影響使用者的體驗(比如瀏覽器的載入速度跟不上服務端的響應速度)。
其實也就類似電腦的記憶體跟不上CPU速度,所以對於使用者造成的體驗感極差,因此在CPU設計時都會加入三級高速緩衝區,用於緩解CPU和記憶體速率不一致的矛盾。在Nginx也同樣存在緩衝區的機制,主要目的就在於:用來解決兩個連線之間速度不匹配造成的問題,有了緩衝後,Nginx代理可暫存後端的響應,然後按需供給資料給客戶端。先來看看一些關於緩衝區的配置項:
- proxy_buffering:是否啟用緩衝機制,預設為on關閉狀態。 - client_body_buffer_size:設定緩衝客戶端請求資料的記憶體大小。 - proxy_buffers:為每個請求/連線設定緩衝區的數量和大小,預設4 4k/8k。 - proxy_buffer_size:設定用於儲存響應頭的緩衝區大小。 - proxy_busy_buffers_size:在後端資料沒有完全接收完成時,Nginx可以將busy狀態的緩衝返回給客戶端,該引數用來設定busy狀態的buffer具體有多大,預設為proxy_buffer_size*2。 - proxy_temp_path:當記憶體緩衝區存滿時,可以將資料臨時存放到磁碟,該引數是設定儲存緩衝資料的目錄。 - 語法:proxy_temp_path path; - path是臨時目錄的路徑。 - proxy_temp_file_write_size:設定每次寫資料到臨時檔案的大小限制。 - proxy_max_temp_file_size:設定臨時的緩衝目錄中允許儲存的最大容量。 - 非緩衝引數項: - proxy_connect_timeout:設定與後端伺服器建立連線時的超時時間。 - proxy_read_timeout:設定從後端伺服器讀取響應資料的超時時間。 - proxy_send_timeout:設定向後端伺服器傳輸請求資料的超時時間。

具體的nginx.conf配置如下: shell http{ proxy_connect_timeout 10; proxy_read_timeout 120; proxy_send_timeout 10; proxy_buffering on; client_body_buffer_size 512k; proxy_buffers 4 64k; proxy_buffer_size 16k; proxy_busy_buffers_size 128k; proxy_temp_file_write_size 128k; proxy_temp_path /soft/nginx/temp_buffer; } 上述的緩衝區引數,是基於每個請求分配的空間,而並不是所有請求的共享空間。當然,具體的引數值還需要根據業務去決定,要綜合考慮機器的記憶體以及每個請求的平均資料大小。

最後提一嘴:使用緩衝也可以減少即時傳輸帶來的頻寬消耗。

七、Nginx快取機制

   對於效能優化而言,快取是一種能夠大幅度提升效能的方案,因此幾乎可以在各處都能看見快取,如客戶端快取、代理快取、伺服器快取等等,Nginx的快取則屬於代理快取的一種。對於整個系統而言,加入快取帶來的優勢額外明顯:
- 減少了再次向後端或檔案伺服器請求資源的頻寬消耗。 - 降低了下游伺服器的訪問壓力,提升系統整體吞吐。 - 縮短了響應時間,提升了載入速度,開啟頁面的速度更快。

那麼在Nginx中,又該如何配置代理快取呢?先來看看快取相關的配置項:
- proxy_cache_path:代理快取的路徑。 - 語法:proxy_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size] [manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=time] [loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time]; - 是的,你沒有看錯,就是這麼長....,解釋一下每個引數項的含義: - path:快取的路徑地址。 - levels:快取儲存的層次結構,最多允許三層目錄。 - use_temp_path:是否使用臨時目錄。 - keys_zone:指定一個共享記憶體空間來儲存熱點Key(1M可儲存8000Key)。 - inactive:設定快取多長時間未被訪問後刪除(預設是十分鐘)。 - max_size:允許快取的最大儲存空間,超出後會基於LRU演算法移除快取,Nginx會建立一個Cache manager的程序移除資料,也可以通過purge方式。 - manager_filesmanager程序每次移除快取檔案數量的上限。 - manager_sleepmanager程序每次移除快取檔案的時間上限。 - manager_thresholdmanager程序每次移除快取後的間隔時間。 - loader_files:重啟Nginx載入快取時,每次載入的個數,預設100。 - loader_sleep:每次載入時,允許的最大時間上限,預設200ms。 - loader_threshold:一次載入後,停頓的時間間隔,預設50ms。 - purger:是否開啟purge方式移除資料。 - purger_files:每次移除快取檔案時的數量。 - purger_sleep:每次移除時,允許消耗的最大時間。 - purger_threshold:每次移除完成後,停頓的間隔時間。 - proxy_cache:開啟或關閉代理快取,開啟時需要指定一個共享記憶體區域。 - 語法:proxy_cache zone | off; - zone為記憶體區域的名稱,即上面中keys_zone設定的名稱。 - proxy_cache_key:定義如何生成快取的鍵。 - 語法:proxy_cache_key string; - string為生成Key的規則,如$scheme$proxy_host$request_uri。 - proxy_cache_valid:快取生效的狀態碼與過期時間。 - 語法:proxy_cache_valid [code ...] time; - code為狀態碼,time為有效時間,可以根據狀態碼設定不同的快取時間。 - 例如:proxy_cache_valid 200 302 30m; - proxy_cache_min_uses:設定資源被請求多少次後被快取。 - 語法:proxy_cache_min_uses number; - number為次數,預設為1。 - proxy_cache_use_stale:當後端出現異常時,是否允許Nginx返回快取作為響應。 - 語法:proxy_cache_use_stale error; - error為錯誤型別,可配置timeout|invalid_header|updating|http_500...。 - proxy_cache_lock:對於相同的請求,是否開啟鎖機制,只允許一個請求發往後端。 - 語法:proxy_cache_lock on | off; - proxy_cache_lock_timeout:配置鎖超時機制,超出規定時間後會釋放請求。 - proxy_cache_lock_timeout time; - proxy_cache_methods:設定對於那些HTTP方法開啟快取。 - 語法:proxy_cache_methods method; - method為請求方法型別,如GET、HEAD等。 - proxy_no_cache:定義不儲存快取的條件,符合時不會儲存。 - 語法:proxy_no_cache string...; - string為條件,例如$cookie_nocache $arg_nocache $arg_comment; - proxy_cache_bypass:定義不讀取快取的條件,符合時不會從快取中讀取。 - 語法:proxy_cache_bypass string...; - 和上面proxy_no_cache的配置方法類似。 - add_header:往響應頭中新增欄位資訊。 - 語法:add_header fieldName fieldValue; - $upstream_cache_status:記錄了快取是否命中的資訊,存在多種情況: - MISS:請求未命中快取。 - HIT:請求命中快取。 - EXPIRED:請求命中快取但快取已過期。 - STALE:請求命中了陳舊快取。 - REVALIDDATEDNginx驗證陳舊快取依然有效。 - UPDATING:命中的快取內容陳舊,但正在更新快取。 - BYPASS:響應結果是從原始伺服器獲取的。 - PS:這個和之前的不同,之前的都是引數項,這個是一個Nginx內建變數。

OK~,對於Nginx中的快取配置項大概瞭解後,接著來配置一下Nginx代理快取: ```shell http{ # 設定快取的目錄,並且記憶體中快取區名為hot_cache,大小為128m, # 三天未被訪問過的快取自動清楚,磁碟中快取的最大容量為2GB。 proxy_cache_path /soft/nginx/cache levels=1:2 keys_zone=hot_cache:128m inactive=3d max_size=2g;

server{
    location / {
        # 使用名為nginx_cache的快取空間
        proxy_cache hot_cache;
        # 對於200、206、304、301、302狀態碼的資料快取1天
        proxy_cache_valid 200 206 304 301 302 1d;
        # 對於其他狀態的資料快取30分鐘
        proxy_cache_valid any 30m;
        # 定義生成快取鍵的規則(請求的url+引數作為key)
        proxy_cache_key $host$uri$is_args$args;
        # 資源至少被重複訪問三次後再加入快取
        proxy_cache_min_uses 3;
        # 出現重複請求時,只讓一個去後端讀資料,其他的從快取中讀取
        proxy_cache_lock on;
        # 上面的鎖超時時間為3s,超過3s未獲取資料,其他請求直接去後端
        proxy_cache_lock_timeout 3s;
        # 對於請求引數或cookie中聲明瞭不快取的資料,不再加入快取
        proxy_no_cache $cookie_nocache $arg_nocache $arg_comment;
        # 在響應頭中新增一個快取是否命中的狀態(便於除錯)
        add_header Cache-status $upstream_cache_status;
    }
}

} ``` 接著來看一下效果,如下:
代理快取
第一次訪問時,因為還沒有請求過資源,所以快取中沒有資料,因此沒有命中快取。第二、三次,依舊沒有命中快取,直至第四次時才顯示命中,這是為什麼呢?因為在前面的快取配置中,我們配置了加入快取的最低條件為:資源至少要被請求三次以上才會加入快取。 這樣可以避免很多無效快取佔用空間。

快取清理

   當快取過多時,如果不及時清理會導致磁碟空間被“吃光”,因此我們需要一套完善的快取清理機制去刪除快取,在之前的proxy_cache_path引數中有purger相關的選項,開啟後可以幫我們自動清理快取,但遺憾的是:purger系列引數只有商業版的NginxPlus才能使用,因此需要付費才可使用。

不過天無絕人之路,我們可以通過強大的第三方模組ngx_cache_purge來替代,先來安裝一下該外掛:
①首先去到Nginx的安裝目錄下,建立一個cache_purge目錄:
shell [[email protected]]# mkdir cache_purge && cd cache_purge

②通過wget指令從github上拉取安裝包的壓縮檔案並解壓: shell [[email protected]]# wget https://github.com/FRiCKLE/ngx_cache_purge/archive/2.3.tar.gz [[email protected]]# tar -xvzf 2.3.tar.gz

③再次去到之前Nginx的解壓目錄下: shell [root[email protected]]# cd /soft/nginx/nginx1.21.6

④重新構建一次Nginx,通過--add-module的指令新增剛剛的第三方模組: shell [[email protected]]# ./configure --prefix=/soft/nginx/ --add-module=/soft/nginx/cache_purge/ngx_cache_purge-2.3/

⑤重新根據剛剛構建的Nginx,再次編譯一下,但切記不要make installshell [[email protected]]# make

⑥刪除之前Nginx的啟動檔案,不放心的也可以移動到其他位置: shell [[email protected]]# rm -rf /soft/nginx/sbin/nginx

⑦從生成的objs目錄中,重新複製一個Nginx的啟動檔案到原來的位置: shell [[email protected]]# cp objs/nginx /soft/nginx/sbin/nginx

至此,第三方快取清除模組ngx_cache_purge就安裝完成了,接下來稍微修改一下nginx.conf配置,再新增一條location規則:
shell location ~ /purge(/.*) { # 配置可以執行清除操作的IP(線上可以配置成內網機器) # allow 127.0.0.1; # 代表本機 allow all; # 代表允許任意IP清除快取 proxy_cache_purge $host$1$is_args$args; } 然後再重啟Nginx,接下來即可通過http://xxx/purge/xx的方式清除快取。

八、Nginx實現IP黑白名單

   有時候往往有些需求,可能某些介面只能開放給對應的合作商,或者購買/接入API的合作伙伴,那麼此時就需要實現類似於IP白名單的功能。而有時候有些惡意攻擊者或爬蟲程式,被識別後需要禁止其再次訪問網站,因此也需要實現IP黑名單。那麼這些功能無需交由後端實現,可直接在Nginx中處理。

Nginx做黑白名單機制,主要是通過allow、deny配置項來實現: allow xxx.xxx.xxx.xxx; # 允許指定的IP訪問,可以用於實現白名單。 deny xxx.xxx.xxx.xxx; # 禁止指定的IP訪問,可以用於實現黑名單。

要同時遮蔽/開放多個IP訪問時,如果所有IP全部寫在nginx.conf檔案中定然是不顯示的,這種方式比較冗餘,那麼可以新建兩個檔案BlocksIP.conf、WhiteIP.conf: ```shell

--------黑名單:BlocksIP.conf---------

deny 192.177.12.222; # 遮蔽192.177.12.222訪問 deny 192.177.44.201; # 遮蔽192.177.44.201訪問 deny 127.0.0.0/8; # 遮蔽127.0.0.1到127.255.255.254網段中的所有IP訪問

--------白名單:WhiteIP.conf---------

allow 192.177.12.222; # 允許192.177.12.222訪問 allow 192.177.44.201; # 允許192.177.44.201訪問 allow 127.45.0.0/16; # 允許127.45.0.1到127.45.255.254網段中的所有IP訪問 deny all; # 除開上述IP外,其他IP全部禁止訪問 分別將要禁止/開放的`IP`新增到對應的檔案後,可以再將這兩個檔案在`nginx.conf`中匯入:shell http{ # 遮蔽該檔案中的所有IP include /soft/nginx/IP/BlocksIP.conf; server{ location xxx { # 某一系列介面只開放給白名單中的IP include /soft/nginx/IP/blockip.conf; } } } `` 對於檔案具體在哪兒匯入,這個也並非隨意的,如果要整站遮蔽/開放就在http中匯入,如果只需要一個域名下遮蔽/開放就在sever中匯入,如果只需要針對於某一系列介面遮蔽/開放IP,那麼就在location`中匯入。

當然,上述只是最簡單的IP黑/白名單實現方式,同時也可以通過ngx_http_geo_module、ngx_http_geo_module第三方庫去實現(這種方式可以按地區、國家進行遮蔽,並且提供了IP庫)。

九、Nginx跨域配置

   跨域問題在之前的單體架構開發中,其實是比較少見的問題,除非是需要接入第三方SDK時,才需要處理此問題。但隨著現在前後端分離、分散式架構的流行,跨域問題也成為了每個Java開發必須要懂得解決的一個問題。

跨域問題產生的原因

   產生跨域問題的主要原因就在於同源策略,為了保證使用者資訊保安,防止惡意網站竊取資料,同源策略是必須的,否則cookie可以共享。由於http無狀態協議通常會藉助cookie來實現有狀態的資訊記錄,例如使用者的身份/密碼等,因此一旦cookie被共享,那麼會導致使用者的身份資訊被盜取。
   同源策略主要是指三點相同,協議+域名+埠 相同的兩個請求,則可以被看做是同源的,但如果其中任意一點存在不同,則代表是兩個不同源的請求,同源策略會限制了不同源之間的資源互動。

Nginx解決跨域問題

   弄明白了跨域問題的產生原因,接下來看看Nginx中又該如何解決跨域呢?其實比較簡單,在nginx.conf中稍微新增一點配置即可:
shell location / { # 允許跨域的請求,可以自定義變數$http_origin,*表示所有 add_header 'Access-Control-Allow-Origin' *; # 允許攜帶cookie請求 add_header 'Access-Control-Allow-Credentials' 'true'; # 允許跨域請求的方法:GET,POST,OPTIONS,PUT add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT'; # 允許請求時攜帶的頭部資訊,*表示所有 add_header 'Access-Control-Allow-Headers' *; # 允許傳送按段獲取資源的請求 add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range'; # 一定要有!!!否則Post請求無法進行跨域! # 在傳送Post跨域請求前,會以Options方式傳送預檢請求,伺服器接受時才會正式請求 if ($request_method = 'OPTIONS') { add_header 'Access-Control-Max-Age' 1728000; add_header 'Content-Type' 'text/plain; charset=utf-8'; add_header 'Content-Length' 0; # 對於Options方式的請求返回204,表示接受跨域請求 return 204; } }nginx.conf檔案加上如上配置後,跨域請求即可生效了。

但如果後端是採用分散式架構開發的,有時候RPC呼叫也需要解決跨域問題,不然也同樣會出現無法跨域請求的異常,因此可以在你的後端專案中,通過繼承HandlerInterceptorAdapter類、實現WebMvcConfigurer介面、新增@CrossOrgin註解的方式實現介面之間的跨域配置。

十、Nginx防盜鏈設計

   首先了解一下何謂盜鏈:盜鏈即是指外部網站引入當前網站的資源對外展示,來舉個簡單的例子理解:

好比桌布網站X站、Y站,X站是一點點去購買版權、簽約作者的方式,從而積累了海量的桌布素材,但Y站由於資金等各方面的原因,就直接通過<img src="X站/xxx.jpg" />這種方式照搬了X站的所有桌布資源,繼而提供給使用者下載。

那麼如果我們自己是這個X站的Boss,心中必然不爽,那麼此時又該如何遮蔽這類問題呢?那麼接下來要敘說的防盜鏈 登場了!

Nginx的防盜鏈機制實現,跟上篇文章《HTTP/HTTPS》中分析到的一個頭部欄位:Referer有關,該欄位主要描述了當前請求是從哪兒發出的,那麼在Nginx中就可獲取該值,然後判斷是否為本站的資源引用請求,如果不是則不允許訪問。Nginx中存在一個配置項為valid_referers,正好可以滿足前面的需求,語法如下:
- valid_referers none | blocked | server_names | string ...; - none:表示接受沒有Referer欄位的HTTP請求訪問。 - blocked:表示允許http://https//以外的請求訪問。 - server_names:資源的白名單,這裡可以指定允許訪問的域名。 - string:可自定義字串,支配萬用字元、正則表示式寫法。

簡單瞭解語法後,接下來的實現如下:
```shell

在動靜分離的location中開啟防盜鏈機制

location ~ .*.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css){ # 最後面的值在上線前可配置為允許的域名地址 valid_referers blocked 192.168.12.129; if ($invalid_referer) { # 可以配置成返回一張禁止盜取的圖片 # rewrite ^/ http://xx.xx.com/NO.jpg; # 也可直接返回403 return 403; }

root   /soft/nginx/static_resources;
expires 7d;

} `` 根據上述中的內容配置後,就已經通過Nginx實現了最基本的防盜鏈機制,最後只需要額外重啟一下就好啦!當然,對於防盜鏈機制實現這塊,也有專門的第三方模組ngx_http_accesskey_module`實現了更為完善的設計,感興趣的小夥伴可以自行去看看。

PS:防盜鏈機制也無法解決爬蟲偽造referers資訊的這種方式抓取資料。

十一、Nginx大檔案傳輸配置

   在某些業務場景中需要傳輸一些大檔案,但大檔案傳輸時往往都會會出現一些Bug,比如檔案超出限制、檔案傳輸過程中請求超時等,那麼此時就可以在Nginx稍微做一些配置,先來了解一些關於大檔案傳輸時可能會用的配置項:
配置項 | 釋義 :-:|:-: client_max_body_size | 設定請求體允許的最大體積 client_header_timeout | 等待客戶端傳送一個請求頭的超時時間 client_body_timeout | 設定讀取請求體的超時時間 proxy_read_timeout | 設定請求被後端伺服器讀取時,Nginx等待的最長時間 proxy_send_timeout | 設定後端向Nginx返回響應時的超時時間

在傳輸大檔案時,client_max_body_size、client_header_timeout、proxy_read_timeout、proxy_send_timeout這四個引數值都可以根據自己專案的實際情況來配置。

上述配置僅是作為代理層需要配置的,因為最終客戶端傳輸檔案還是直接與後端進行互動,這裡只是把作為閘道器層的Nginx配置調高一點,調到能夠“容納大檔案”傳輸的程度。
當然,Nginx中也可以作為檔案伺服器使用,但需要用到一個專門的第三方模組nginx-upload-module,如果專案中檔案上傳的作用處不多,那麼建議可以通過Nginx搭建,畢竟可以節省一臺檔案伺服器資源。但如若檔案上傳/下載較為頻繁,那麼還是建議額外搭建檔案伺服器,並將上傳/下載功能交由後端處理。

十二、Nginx配置SLL證書

   隨著越來越多的網站接入HTTPS,因此Nginx中僅配置HTTP還不夠,往往還需要監聽443埠的請求,但在上篇《HTTP/HTTPS》中談到過,HTTPS為了確保通訊安全,所以服務端需配置對應的數字證書,當專案使用Nginx作為閘道器時,那麼證書在Nginx中也需要配置,接下來簡單聊一下關於SSL證書配置過程: - ①先去CA機構或從雲控制檯中申請對應的SSL證書,稽核通過後下載Nginx版本的證書。 - ②下載數字證書後,完整的檔案總共有三個:.crt、.key、.pem: - .crt:數字證書檔案,.crt.pem的拓展檔案,因此有些人下載後可能沒有。 - .key:伺服器的私鑰檔案,及非對稱加密的私鑰,用於解密公鑰傳輸的資料。 - .pemBase64-encoded編碼格式的源證書文字檔案,可自行根需求修改拓展名。 - ③在Nginx目錄下新建certificate目錄,並將下載好的證書/私鑰等檔案上傳至該目錄。 - ④最後修改一下nginx.conf檔案即可,如下:

```shell

----------HTTPS配置-----------

server { # 監聽HTTPS預設的443埠 listen 443; # 配置自己專案的域名 server_name www.xxx.com; # 開啟SSL加密傳輸 ssl on; # 輸入域名後,首頁檔案所在的目錄 root html; # 配置首頁的檔名 index index.html index.htm index.jsp index.ftl; # 配置自己下載的數字證書 ssl_certificate certificate/xxx.pem; # 配置自己下載的伺服器私鑰 ssl_certificate_key certificate/xxx.key; # 停止通訊時,加密會話的有效期,在該時間段內不需要重新交換金鑰 ssl_session_timeout 5m; # TLS握手時,伺服器採用的密碼套件 ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; # 伺服器支援的TLS版本 ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # 開啟由伺服器決定採用的密碼套件 ssl_prefer_server_ciphers on; ​ location / { .... } }

---------HTTP請求轉HTTPS-------------

server { # 監聽HTTP預設的80埠 listen 80; # 如果80端口出現訪問該域名的請求 server_name www.xxx.com; # 將請求改寫為HTTPS(這裡寫你配置了HTTPS的域名) rewrite ^(.*)$ https://www.xxx.com; } `` OK~,根據如上配置了Nginx後,你的網站即可通過https://的方式訪問,並且當客戶端使用http://的方式訪問時,會自動將其改寫為HTTPS`請求。

十三、Nginx的高可用

   線上如果採用單個節點的方式部署Nginx,難免會出現天災人禍,比如系統異常、程式宕機、伺服器斷電、機房爆炸、地球毀滅....哈哈哈,誇張了。但實際生產環境中確實存在隱患問題,由於Nginx作為整個系統的閘道器層接入外部流量,所以一旦Nginx宕機,最終就會導致整個系統不可用,這無疑對於使用者的體驗感是極差的,因此也得保障Nginx高可用的特性。

接下來則會通過keepalivedVIP機制,實現Nginx的高可用。
VIP並不是只會員的意思,而是指Virtual IP,即虛擬IP

keepalived在之前單體架構開發時,是一個用的較為頻繁的高可用技術,比如MySQL、Redis、MQ、Proxy、Tomcat等各處都會通過keepalived提供的VIP機制,實現單節點應用的高可用。

Keepalived+重啟指令碼+雙機熱備搭建

①首先建立一個對應的目錄並下載keepalived安裝包(提取碼:s6aq)Linux中並解壓: shell [[email protected]]# mkdir /soft/keepalived && cd /soft/keepalived [[email protected]]# wget https://www.keepalived.org/software/keepalived-2.2.4.tar.gz [[email protected]]# tar -zxvf keepalived-2.2.4.tar.gz

②進入解壓後的keepalived目錄並構建安裝環境,然後編譯並安裝: shell [[email protected]]# cd keepalived-2.2.4 [[email protected]]# ./configure --prefix=/soft/keepalived/ [[email protected]]# make && make install

③進入安裝目錄的/soft/keepalived/etc/keepalived/並編輯配置檔案: shell [[email protected]]# cd /soft/keepalived/etc/keepalived/ [[email protected]]# vi keepalived.conf

④編輯主機的keepalived.conf核心配置檔案,如下: ```shell global_defs { # 自帶的郵件提醒服務,建議用獨立的監控或第三方SMTP,也可選擇配置郵件傳送。 notification_email { [email protected] } notification_email_from [email protected] smtp_server localhost smtp_connect_timeout 30 # 高可用叢集主機身份標識(叢集中主機身份標識名稱不能重複,建議配置成本機IP) router_id 192.168.12.129 }

定時執行的指令碼檔案配置

vrrp_script check_nginx_pid_restart { # 之前編寫的nginx重啟指令碼的所在位置 script "/soft/scripts/keepalived/check_nginx_pid_restart.sh" # 每間隔3秒執行一次 interval 3 # 如果指令碼中的條件成立,重啟一次則權重-20 weight -20 }

定義虛擬路由,VI_1為虛擬路由的標示符(可自定義名稱)

vrrp_instance VI_1 { # 當前節點的身份標識:用來決定主從(MASTER為主機,BACKUP為從機) state MASTER # 繫結虛擬IP的網路介面,根據自己的機器的網絡卡配置 interface ens33 # 虛擬路由的ID號,主從兩個節點設定必須一樣 virtual_router_id 121 # 填寫本機IP mcast_src_ip 192.168.12.129 # 節點權重優先順序,主節點要比從節點優先順序高 priority 100 # 優先順序高的設定nopreempt,解決異常恢復後再次搶佔造成的腦裂問題 nopreempt # 組播資訊傳送間隔,兩個節點設定必須一樣,預設1s(類似於心跳檢測) advert_int 1 authentication { auth_type PASS auth_pass 1111 } # 將track_script塊加入instance配置塊 track_script { # 執行Nginx監控的指令碼 check_nginx_pid_restart }

virtual_ipaddress {
    # 虛擬IP(VIP),也可擴充套件,可配置多個。
    192.168.12.111
}

} ```

⑤克隆一臺之前的虛擬機器作為從(備)機,編輯從機的keepalived.conf檔案,如下: ```shell global_defs { # 自帶的郵件提醒服務,建議用獨立的監控或第三方SMTP,也可選擇配置郵件傳送。 notification_email { [email protected] } notification_email_from [email protected] smtp_server localhost smtp_connect_timeout 30 # 高可用叢集主機身份標識(叢集中主機身份標識名稱不能重複,建議配置成本機IP) router_id 192.168.12.130 }

定時執行的指令碼檔案配置

vrrp_script check_nginx_pid_restart { # 之前編寫的nginx重啟指令碼的所在位置 script "/soft/scripts/keepalived/check_nginx_pid_restart.sh" # 每間隔3秒執行一次 interval 3 # 如果指令碼中的條件成立,重啟一次則權重-20 weight -20 }

定義虛擬路由,VI_1為虛擬路由的標示符(可自定義名稱)

vrrp_instance VI_1 { # 當前節點的身份標識:用來決定主從(MASTER為主機,BACKUP為從機) state BACKUP # 繫結虛擬IP的網路介面,根據自己的機器的網絡卡配置 interface ens33 # 虛擬路由的ID號,主從兩個節點設定必須一樣 virtual_router_id 121 # 填寫本機IP mcast_src_ip 192.168.12.130 # 節點權重優先順序,主節點要比從節點優先順序高 priority 90 # 優先順序高的設定nopreempt,解決異常恢復後再次搶佔造成的腦裂問題 nopreempt # 組播資訊傳送間隔,兩個節點設定必須一樣,預設1s(類似於心跳檢測) advert_int 1 authentication { auth_type PASS auth_pass 1111 } # 將track_script塊加入instance配置塊 track_script { # 執行Nginx監控的指令碼 check_nginx_pid_restart }

virtual_ipaddress {
    # 虛擬IP(VIP),也可擴充套件,可配置多個。
    192.168.12.111
}

} ```

⑥新建scripts目錄並編寫Nginx的重啟指令碼,check_nginx_pid_restart.sh: ```shell [[email protected]]# mkdir /soft/scripts /soft/scripts/keepalived [[email protected]]# touch /soft/scripts/keepalived/check_nginx_pid_restart.sh [[email protected]]# vi /soft/scripts/keepalived/check_nginx_pid_restart.sh

!/bin/sh

通過ps指令查詢後臺的nginx程序數,並將其儲存在變數nginx_number中

nginx_number=ps -C nginx --no-header | wc -l

判斷後臺是否還有Nginx程序在執行

if [ nginx_number -eq 0 ];then # 如果後臺查詢不到Nginx程序存在,則執行重啟指令 /soft/nginx/sbin/nginx -c /soft/nginx/conf/nginx.conf # 重啟後等待1s後,再次查詢後臺程序數 sleep 1 # 如果重啟後依舊無法查詢到nginx程序 if [ ps -C nginx --no-header | wc -l -eq 0 ];then # 將keepalived主機下線,將虛擬IP漂移給從機,從機上線接管Nginx服務 systemctl stop keepalived.service fi fi ```

⑦編寫的指令碼檔案需要更改編碼格式,並賦予執行許可權,否則可能執行失敗: ```shell [[email protected]]# vi /soft/scripts/keepalived/check_nginx_pid_restart.sh

:set fileformat=unix # 在vi命令裡面執行,修改編碼格式 :set ff # 檢視修改後的編碼格式

[[email protected]]# chmod +x /soft/scripts/keepalived/check_nginx_pid_restart.sh ```

⑧由於安裝keepalived時,是自定義的安裝位置,因此需要拷貝一些檔案到系統目錄中: shell [[email protected]]# mkdir /etc/keepalived/ [[email protected]]# cp /soft/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/ [[email protected]]# cp /soft/keepalived/keepalived-2.2.4/keepalived/etc/init.d/keepalived /etc/init.d/ [[email protected]]# cp /soft/keepalived/etc/sysconfig/keepalived /etc/sysconfig/

⑨將keepalived加入系統服務並設定開啟自啟動,然後測試啟動是否正常: ```shell [[email protected]]# chkconfig keepalived on [[email protected]]# systemctl daemon-reload [[email protected]]# systemctl enable keepalived.service [[email protected]]# systemctl start keepalived.service

其他命令: systemctl disable keepalived.service # 禁止開機自動啟動 systemctl restart keepalived.service # 重啟keepalived systemctl stop keepalived.service # 停止keepalived tail -f /var/log/messages # 檢視keepalived執行時日誌 ```

⑩最後測試一下VIP是否生效,通過檢視本機是否成功掛載虛擬IPshell [[email protected]]# ip addr 虛擬IP-VIP

從上圖中可以明顯看見虛擬IP已經成功掛載,但另外一臺機器192.168.12.130並不會掛載這個虛擬IP,只有當主機下線後,作為從機的192.168.12.130才會上線,接替VIP。最後測試一下外網是否可以正常與VIP通訊,即在Windows中直接ping VIP

Ping-VIP

外部通過VIP通訊時,也可以正常Ping通,代表虛擬IP配置成功。

Nginx高可用性測試

   經過上述步驟後,keepalivedVIP機制已經搭建成功,在上個階段中主要做了幾件事: - 一、為部署Nginx的機器掛載了VIP。 - 二、通過keepalived搭建了主從雙機熱備。 - 三、通過keepalived實現了Nginx宕機重啟。

由於前面沒有域名的原因,因此最初server_name配置的是當前機器的IP,所以需稍微更改一下nginx.conf的配置: shell sever{ listen 80; # 這裡從機器的本地IP改為虛擬IP server_name 192.168.12.111; # 如果這裡配置的是域名,那麼則將域名的對映配置改為虛擬IP }

最後來實驗一下效果: Nginx宕機

在上述過程中,首先分別啟動了keepalived、nginx服務,然後通過手動停止nginx的方式模擬了Nginx宕機情況,過了片刻後再次查詢後臺程序,我們會發現nginx依舊存活。

從這個過程中不難發現,keepalived已經為我們實現了Nginx宕機後自動重啟的功能,那麼接著再模擬一下伺服器出現故障時的情況:
伺服器故障

在上述過程中,我們通過手動關閉keepalived服務模擬了機器斷電、硬體損壞等情況(因為機器斷電等情況=主機中的keepalived程序消失),然後再次查詢了一下本機的IP資訊,很明顯會看到VIP消失了!

現在再切換到另外一臺機器:192.168.12.130來看看情況: 130的IP情況

此刻我們會發現,在主機192.168.12.129宕機後,VIP自動從主機飄移到了從機192.168.12.130上,而此時客戶端的請求就最終會來到130這臺機器的Nginx上。

最終,利用KeepalivedNginx做了主從熱備之後,無論是遇到線上宕機還是機房斷電等各類故障時,都能夠確保應用系統能夠為使用者提供7x24小時服務。

十四、Nginx效能優化

   到這裡文章的篇幅較長了,最後再來聊一下關於Nginx的效能優化,主要就簡單說說收益最高的幾個優化項,在這塊就不再展開敘述了,畢竟影響效能都有多方面原因導致的,比如網路、伺服器硬體、作業系統、後端服務、程式自身、資料庫服務等,對於效能調優比較感興趣的可以參考之前《JVM效能調優》中的調優思想

優化一:開啟長連線配置

   通常Nginx作為代理服務,負責分發客戶端的請求,那麼建議開啟HTTP長連線,使用者減少握手的次數,降低伺服器損耗,具體如下:
shell upstream xxx { # 長連線數 keepalive 32; # 每個長連線提供的最大請求數 keepalived_requests 100; # 每個長連線沒有新的請求時,保持的最長時間 keepalive_timeout 60s; }

優化二、開啟零拷貝技術

   零拷貝這個概念,在大多數效能較為不錯的中介軟體中都有出現,例如Kafka、Netty等,而Nginx中也可以配置資料零拷貝技術,如下:
shell sendfile on; # 開啟零拷貝機制 零拷貝讀取機制與傳統資源讀取機制的區別: - 傳統方式:硬體-->核心-->使用者空間-->程式空間-->程式核心空間-->網路套接字 - 零拷貝方式:硬體-->核心-->程式核心空間-->網路套接字

從上述這個過程對比,很輕易就能看出兩者之間的效能區別。

優化三、開啟無延遲或多包共發機制

   在Nginx中有兩個較為關鍵的效能引數,即tcp_nodelay、tcp_nopush,開啟方式如下:
shell tcp_nodelay on; tcp_nopush on; TCP/IP協議中預設是採用了Nagle演算法的,即在網路資料傳輸過程中,每個資料報文並不會立馬傳送出去,而是會等待一段時間,將後面的幾個資料包一起組合成一個數據報文傳送,但這個演算法雖然提高了網路吞吐量,但是實時性卻降低了。

因此你的專案屬於互動性很強的應用,那麼可以手動開啟tcp_nodelay配置,讓應用程式向核心遞交的每個資料包都會立即傳送出去。但這樣會產生大量的TCP報文頭,增加很大的網路開銷。

相反,有些專案的業務對資料的實時性要求並不高,追求的則是更高的吞吐,那麼則可以開啟tcp_nopush配置項,這個配置就類似於“塞子”的意思,首先將連線塞住,使得資料先不發出去,等到拔去塞子後再發出去。設定該選項後,核心會盡量把小資料包拼接成一個大的資料包(一個MTU)再發送出去.

當然若一定時間後(一般為200ms),核心仍然沒有積累到一個MTU的量時,也必須傳送現有的資料,否則會一直阻塞。

tcp_nodelay、tcp_nopush兩個引數是“互斥”的,如果追求響應速度的應用推薦開啟tcp_nodelay引數,如IM、金融等型別的專案。如果追求吞吐量的應用則建議開啟tcp_nopush引數,如排程系統、報表系統等。

注意:
tcp_nodelay一般要建立在開啟了長連線模式的情況下使用。
tcp_nopush引數是必須要開啟sendfile引數才可使用的。

優化四、調整Worker工作程序

   Nginx啟動後預設只會開啟一個Worker工作程序處理客戶端請求,而我們可以根據機器的CPU核數開啟對應數量的工作程序,以此來提升整體的併發量支援,如下:
```shell

自動根據CPU核心數調整Worker程序數量

worker_processes auto; ```

工作程序的數量最高開到8個就OK了,8個之後就不會有再大的效能提升。

同時也可以稍微調整一下每個工作程序能夠開啟的檔案控制代碼數:
```shell

每個Worker能開啟的檔案描述符,最少調整至1W以上,負荷較高建議2-3W

worker_rlimit_nofile 20000; ```

作業系統核心(kernel)都是利用檔案描述符來訪問檔案,無論是開啟、新建、讀取、寫入檔案時,都需要使用檔案描述符來指定待操作的檔案,因此該值越大,代表一個程序能夠操作的檔案越多(但不能超出核心限制,最多建議3.8W左右為上限)。

優化五、開啟CPU親和機制

   對於併發程式設計較為熟悉的夥伴都知道,因為程序/執行緒數往往都會遠超出系統CPU的核心數,因為作業系統執行的原理本質上是採用時間片切換機制,也就是一個CPU核心會在多個程序之間不斷頻繁切換,造成很大的效能損耗。

而CPU親和機制則是指將每個Nginx的工作程序,繫結在固定的CPU核心上,從而減小CPU切換帶來的時間開銷和資源損耗,開啟方式如下:
shell worker_cpu_affinity auto;

優化六、開啟epoll模型及調整併發連線數

   在最開始就提到過:Nginx、Redis都是基於多路複用模型去實現的程式,但最初版的多路複用模型select/poll最大隻能監聽1024個連線,而epoll則屬於select/poll介面的增強版,因此採用該模型能夠大程度上提升單個Worker的效能,如下: shell events { # 使用epoll網路模型 use epoll; # 調整每個Worker能夠處理的連線數上限 worker_connections 10240; }

這裡對於select/poll/epoll模型就不展開細說了,後面的IO模型文章中會詳細剖析。

十五、放在最後的結尾

   至此,Nginx的大部分內容都已闡述完畢,關於最後一小節的效能優化內容,其實在前面就談到的動靜分離、分配緩衝區、資源快取、防盜鏈、資源壓縮等內容,也都可歸納為效能優化的方案。

最後,希望諸君收藏的同時不要忘了點個贊支援一下^_^,在此萬分感謝!