幹貨！總結很長，建議先收藏慢慢看！
前言
❝
早期的單機服務，主要存在兩個問題：
①單體結構的部署方式無法承載日益增長的業務流量。
②當後端節點當機後，整個系統會陷入癱瘓，導緻整個項目不可用。
❞
是以引入負載均衡技術的必要性就來了：
- 「系統的高可用」 即多服務時，當某個服務當機後可快速轉移請求至其他服務。
- 「系統的高性能」 多伺服器提高系統更高規模的吞吐量。
- 「系統的拓展性」 當業務突驟增或劇減時，可再加/減節點，高靈活伸縮。
主要有兩種負載方案：硬體層面與軟體層面 ，都知道硬體方面老貴了，老闆們肯定是盡量技術層面解決的就技術解決。
一、Nginx概念淺析
Nginx是一個輕量級的高性能HTTP反向代理伺服器，同時它也是一個通用類型的代理伺服器，支援絕大部分協定，如TCP、UDP、SMTP、HTTPS等。
Nginx是基于多路複用模型建構出來的，具備資源占用少、并發支援高的特點。
官方解釋理論上單節點Nginx同時支援5W并發連接配接，當然實際生産環境中除非硬體跟上才能達到這個峰值的。
用Nginx代理後，用戶端的請求由其進行分發到伺服器處理，伺服器處理完後再傳回Nginx，由Nginx結果傳回給用戶端。
下面我們建一下環境，了解一下Nginx的進階特性，如動靜分離、資源壓縮、緩存配置、IP黑名單、高可用保障等等。
二、Nginx搭建
伺服器相關搭建就省略了，直接上ng。
❶伺服器建立Nginx目錄并進入：
[root@localhost]# mkdir /soft && mkdir /soft/nginx/
[root@localhost]# cd /soft/nginx/ ❷下載下傳Nginx安裝包
可以伺服器遠端工具上傳已經下載下傳好的壓縮包，也用wget指令伺服器線上下載下傳壓縮包：
[root@localhost]# wget https://nginx.org/download/nginx-1.21.6.tar.gz
wget指令的可通過yum指令安裝： 不支援wget指令的，需要用yum指令安裝wget支援：
[root@localhost]# yum -y install wget ❸指令解壓Nginx壓縮包：
[root@localhost]# tar -xvzf nginx-1.21.6.tar.gz ❹下載下傳并安裝Nginx所需的依賴庫和包：
[root@localhost]# yum install --downloadonly --downloaddir=/soft/nginx/ gcc-c++
[root@localhost]# yum install --downloadonly --downloaddir=/soft/nginx/ pcre pcre-devel4
[root@localhost]# yum install --downloadonly --downloaddir=/soft/nginx/ zlib zlib-devel
[root@localhost]# yum install --downloadonly --downloaddir=/soft/nginx/ openssl openssl-devel 也可yum指令一鍵安裝：
[root@localhost]# yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel 完成後ls檢視，所有需要依賴都在裡面：
然後用rpm指令依次建構每個依賴包；或用以下下指令一鍵安裝全部依賴包：
[root@localhost]# rpm -ivh --nodeps *.rpm ❺cd到nginx目錄，執行Nginx配置腳本，提前配置好環境便于後面安裝，預設位于/usr/local/nginx/目錄：
[root@localhost]# cd nginx-1.21.6
[root@localhost]# ./configure --prefix=/soft/nginx/ ❻執行指令編譯并安裝Nginx：
[root@localhost]# make && make install ❼回到/soft/nginx/目錄，用ls可看到安裝nginx後生成的檔案。
❽修改安裝後conf目錄下的nginx.conf：
[root@localhost]# vi conf/nginx.conf
修改端口号：listen 80;
修改IP位址：server_name 你目前機器的本地IP(線上配置域名); ❾制定Nginx配置檔案并啟動：
[root@localhost]# sbin/nginx -c conf/nginx.conf
[root@localhost]# ps aux | grep nginx Nginx其他操作指令：
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端口，重新整理伺服器防火牆：
[root@localhost]# firewall-cmd --zone=public --add-port=80/tcp --permanent
[root@localhost]# firewall-cmd --reload
[root@localhost]# firewall-cmd --zone=public --list-ports ⓫浏覽器輸入Nginx配的IP或域名通路：
如果你看到了Nginx歡迎界面，那麼恭喜你安裝成功。
三、Nginx反向代理-負載均衡
先用SpringBoot+Freemarker搭建一個簡單的WEB項目，然後在該項目中，控制層接口如下：
@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;
}
} 前端index.html源碼：
<html>
<head>
<title>Nginx示範demo</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> 準備工作做好了，再調整一下nginx.conf
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服務啟動時，一個服務的端口改為8080，另外一服務端口号改為8090。
❞
浏覽器通路看看效果：
這裡采用輪詢及配置了權重，是以8080一次、8090兩次...
Nginx分發請求原理
請求流程如下：
請求分發原理
- Nginx監聽了伺服器80端口，是以請求先到Nginx；
- Nginx會根據location配置規則比對，再根據請求路徑/，定位到location /{}規則；
- 然後根據location配置的proxy_pass再找到名為nginx_boot的upstream；
- 再根據upstream配置資訊，把用戶端請求轉發到WEB伺服器處理，（多台機器時因Nginx會根據權重比分發請求的次數）
四、Nginx動靜分離
先思考一下：「為什麼要做動靜分離？它的優點是什麼？」
以淘寶網分析為例：
當浏覽器通路淘寶首頁時，F12可以看到，就首頁加載就出現100+的請求數，而靜态資源一般在項目resources/static/目錄下：
不采用ng動靜分離情況下，一個用戶端請求淘寶首頁，就有100+的并發請求到伺服器。這樣是不是後端伺服器的壓力就是非常的大了。
❝
不難看出首頁100+的請求中，至少有60+是屬于*.js、*.css、*.html、*.jpg.....這類靜态資源的請求呢?。
❞
大多數靜态資源長時間是不會變的，如果靜态資源的請求在向服務端發起請求之前處理了呢？「動靜分離處理後，後端伺服器可以減少一半以上的并發量」。
該怎麼實作動靜分離呢？
①在Nginx目錄下建立一個放靜态資源目錄static_resources：
mkdir static_resources ②把項目的靜态資源全放到該目錄下，然後後端項目中删除靜态資源再打包。
③再微調nginx.conf配置檔案，加一條location比對規則：
location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css){
root /soft/nginx/static_resources;
expires 7d;
} 重新開機nginx和WEB服務，再通路發現原來的靜态資源效果依然還在，如下：
static下的nginx_style.css檔案已被移除，但效果依然還在：
來解釋一下location規則配置：
location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css) - ~表示比對時區分大小寫
- .*表示任何字元都可出現零或多次，（資源名不受限制）
- \.表示比對字尾分隔符.
- (html|...|css)表示比對括号中全部該類型的靜态資源
「友情提示：也可把靜态資源傳到oos上，location配置新的upstream指向」
五、Nginx資源壓縮
有了前面的動靜分離，試想一下靜态資源的Size越小，其傳輸速度肯定也更快，也會更節省帶寬。
是以在部署靜态資源時，也用Nginx來壓縮靜态資源傳輸，不僅節省帶寬資源，也加快響應速度進而并提高系統整體吞吐量。
Nginx提供了三個資源壓縮子產品：ngx_http_gzip_module；ngx_http_gzip_static_module；ngx_http_gunzip_module；
其中ngx_http_gzip_module是Nginx内置的，可直接用該子產品的壓縮指令，其實後續的資源壓縮操作都是基于它的。
Nginx壓縮配置的一些參數和指令：
在Nginx中簡單配置使用一下：
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：無條件對後端的響應結果開啟壓縮機制。
配置好了，在原本的index頁面中引入一個jquery-3.6.0.js檔案測試一下：
<script type="text/javascript" src="jquery-3.6.0.js"></script> 對比下壓縮前後的差異：
從對比結果看，未開啟壓縮機制前，js檔案原始大小為230K，當配置了壓縮後重新開機Nginx，會發現檔案大小從230KB→69KB，這就是差距！
❝
注意點：
①如果是圖檔、視訊類型的資料，ng會預設開啟壓縮機制。
②如果.js檔案，需指定壓縮類型為application/javascript。
❞
六、Nginx緩沖區
先舉個例子，接入Nginx後：“用戶端→Nginx→服務端”，在這個過程中存在：“用戶端→Nginx、Nginx→服務端”兩個連接配接，這兩個連接配接速度肯定不一樣的，這樣是不是使用者的體驗感就極差了。
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配置可參考以下：
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;
} 緩沖區參數，是基于每個請求配置設定的空間，而并不是所有請求的共享空間。
❝
ng緩沖也可以适當減少即時傳輸帶來的帶寬消耗。
❞
七、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可存儲8000個Key)。
- inactive：設定緩存多長時間未被通路後删除（預設是十分鐘）。
- max_size：允許緩存的最大存儲空間，超出後會基于LRU算法移除緩存，Nginx會建立一個Cache manager的程序移除資料，也可以通過purge方式。
- manager_files：manager程序每次移除緩存檔案數量的上限。
- manager_sleep：manager程序每次移除緩存檔案的時間上限。
- manager_threshold：manager程序每次移除緩存後的間隔時間。
- 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：請求命中了陳舊緩存。
- REVALIDDATED：Nginx驗證陳舊緩存依然有效。
- UPDATING：命中的緩存内容陳舊，但正在更新緩存。
- BYPASS：響應結果是從原始伺服器擷取的。
❝
注：這是Nginx内置變量并不是參數項。
❞
接下來實操配置Nginx代理緩存：
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;
}
}
} 測試看一下效果，如下：
第一次通路緩存中沒資料，是以沒有命中緩存。第二、三次，依舊沒有命中緩存，因為緩存配置了緩存的最低條件為：「資源至少要被請求三次以上才會加入緩存」。直至第四次時才命中緩存。這樣做的好處是能減少一些無效緩存占用空間。
緩存清理
既然有了緩存那麼肯定就存在清理緩存，好比手機app用久了需要清理緩存一樣的道理。
如果緩存過多時，不及時清理那麼磁盤空間也就會被“吃光”，是以在前面的proxy_cache_path參數中有purger選項，開啟後可以自動清理緩存，但這個是商業版的要付費。
是以我們可采用三方引入的ngx_cache_purge子產品來替代，先安裝該插件：
①到Nginx安裝目錄下，建立一個cache_purge目錄：
[root@localhost]# mkdir cache_purge && cd cache_purge ②通過wget指令從github上下載下傳插件壓縮檔案并解壓：
[root@localhost]# wget https://github.com/FRiCKLE/ngx_cache_purge/archive/2.3.tar.gz
[root@localhost]# tar -xvzf 2.3.tar.gz ③再去Nginx的解壓目錄下：
[root@localhost]# cd /soft/nginx/nginx1.21.6 ④重新建構一下Nginx，用--add-module的指令添加該插件：
[root@localhost]# ./configure --prefix=/soft/nginx/ --add-module=/soft/nginx/cache_purge/ngx_cache_purge-2.3/ ⑤再次編譯剛剛建構的Nginx，「但切記不要make install」 ：
[root@localhost]# make ⑥删除之前Nginx的啟動檔案：
[root@localhost]# rm -rf /soft/nginx/sbin/nginx ⑦從生成的objs目錄中，複制新的Nginx啟動檔案到原來的位置：
[root@localhost]# cp objs/nginx /soft/nginx/sbin/nginx 三方緩存清除插件ngx_cache_purge就安裝好了，然後微調nginx.conf配置，再添加一條location規則：
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黑白名單功能
Nginx主要是通過allow、deny配置項來實作IP黑白名單的：
allow xxx.xxx.xxx.xxx; # 允許指定的IP通路，可以用于實作白名單。
deny xxx.xxx.xxx.xxx; # 禁止指定的IP通路，可以用于實作黑名單。 當IP配置很多時全堆在nginx.conf檔案中是不友好的，過于備援，此時可建立兩個檔案BlocksIP.conf、WhiteIP.conf：
# --------黑名單：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中：
http{
# 屏蔽該檔案中的所有IP
include /soft/nginx/IP/BlocksIP.conf;
server{
location xxx {
# 某一系列接口隻開放給白名單中的IP
include /soft/nginx/IP/blockip.conf;
}
}
} 這兩個檔案導入注意事項：
如果要整站屏蔽/開放就在http中導入；
如果隻需一個域名下屏蔽/開放就在sever中導入；
如果隻需要針對于某一系列接口屏蔽/開放IP，那麼就在location中導入。
❝
也可以通過ngx_http_geo_module、ngx_http_geo_module第三方庫去實作IP黑白名單（這種可按地區、國家來屏蔽，且提供有IP庫）。
❞
九、Nginx跨域配置
如果是前後端分離、分布式架構、導入三方sdk，跨域問題就必須解決的了。
跨域問題是如何産生的？
其主要原因就在于 「同源政策」 。為了保證使用者資訊安全，防止惡意網站竊取資料，同源政策是必須的，否則cookie就可以共享。那麼http無狀态協定下會導緻使用者的身份資訊被盜取。
同源政策包括三點：「協定+域名+端口」 ，即三者都相同的兩個請求，才可被看做是同源的，同源政策會限制了不同源之間的資源互動。
Nginx解決跨域
nginx.conf中添加配置即可解決跨域：
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注解來解決rpc調用跨域問題。
❞
十、Nginx的防盜鍊設計
什麼是盜鍊？
「盜鍊即是指外部網站引入目前網站的資源對外展示」
舉個例子幫助了解：
❝
比如某圖檔a站、b站，a站的圖檔素材是花錢買的，但b站就直接通過<img src="X站/xxx.jpg" />方式照搬用a站的所有圖檔。
這個時候防盜鍊是不是就能派上用場了。
❞
Nginx的防盜鍊機制，跟一個頭部字段Referer有關。
該字段主要描述了目前請求是從哪裡來的，在Nginx中就可以拿到該值，然後判斷是否是本站的資源引用請求，如果不是則不允許通路。
Nginx中有一個配置項valid_referers，剛好可以滿足這個需求，用法如下：
valid_referers none | blocked | server_names | string ...; - none：表示接受沒有Referer字段的HTTP請求通路。
- blocked：表示允許http://或https//以外的請求通路。
- server_names：資源請求的白名單，也就是可以指定允許通路的域名。
- string：可自定義字元串，支配通配符、正規表達式寫法。
按照文法實作如下：
# 在動靜分離的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;
} 重新開機一下ng，基本都防盜鍊就好啦！
當然防盜鍊機制實作這塊，也可以用第三方插件ngx_http_accesskey_module，該插件實作了更為完善的設計。
❝
防盜鍊是無法解決爬蟲僞造referers資訊來抓取資料。
❞
十一、Nginx大檔案傳輸配置
在一些業務場景下，大檔案傳輸時會存在檔案超出限制、傳輸請求逾時等，Nginx也是可以解決的。
檔案傳輸時ng可能會用的配置項：
在傳輸大檔案時，這四個參數值都可以根據自己項目的實際情況來配置。
❝
這裡隻是作為代理層需要配置的，這裡隻是把作為網關層的Nginx配置調高一點，調到能夠“容納大檔案”傳輸的程度。
❞
十二、Nginx配置SLL證書
網站接入HTTPS就必須用到SSL證書，是以Nginx中還需監聽443端口的請求，HTTPS為了確定通信安全，是以服務端需配置對應的數字證書。
關于SSL證書配置過程：
①先去CA機構或從雲控制台中申請對應的SSL證書，稽核通過後下載下傳Nginx版本的證書。
②下載下傳數字證書後，完整的檔案總共有三個：.crt、.key、.pem：
- .crt：數字證書檔案，.crt是.pem的拓展檔案，是以有些人下載下傳後可能沒有。
- .key：伺服器的私鑰檔案，及非對稱加密的私鑰，用于解密公鑰傳輸的資料。
- .pem：Base64-encoded編碼格式的源證書文本檔案，可自行根需求修改拓展名。
③在Nginx目錄下建立certificate目錄，并将下載下傳好的證書/私鑰等檔案上傳至該目錄。
④最後改一下nginx.conf檔案，如下：
# ----------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;
} 配好後，你的網站即可通過https通路了，并且當用戶端使用http的方式通路時，會自動将其改寫為HTTPS請求。
十三、Nginx的高可用
如果生産中用單個Nginx節點部署，由于Nginx作為整個系統的網關層接入外部流量，一旦Nginx當機，最終就會導緻整個系統癱瘓，對于生産環境無疑是災難。
是以也必須保障Nginx的高可用。
❝
通過keepalived的VIP機制，實作Nginx的高可用。VIP是指Virtual IP，即虛拟IP。
❞
keepalived在之前單體架構開發時，是一個用的較為頻繁的高可用技術，比如MySQL、Redis、MQ、Proxy、Tomcat等都會通過keepalived提供的VIP機制，實作單節點應用的高可用。
Keepalived+重新開機腳本+雙機熱備搭建
①建立一個目錄并下載下傳keepalived到Linux中并解壓：
[root@localhost]# mkdir /soft/keepalived && cd /soft/keepalived
[root@localhost]# wget https://www.keepalived.org/software/keepalived-2.2.4.tar.gz
[root@localhost]# tar -zxvf keepalived-2.2.4.tar.gz ②進入解壓後的keepalived目錄并建構安裝環境，然後編譯并安裝：
[root@localhost]# cd keepalived-2.2.4
[root@localhost]# ./configure --prefix=/soft/keepalived/
[root@localhost]# make && make install ③進入安裝目錄的/soft/keepalived/etc/keepalived/下并編輯配置檔案：
[root@localhost]# cd /soft/keepalived/etc/keepalived/
[root@localhost]# vi keepalived.conf ④編輯主機的keepalived.conf核心配置檔案，如下：
global_defs {
# 自帶的郵件提醒服務，建議用獨立的監控或第三方SMTP，也可選擇配置郵件發送。
notification_email {
root@localhost
}
notification_email_from root@localhost
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檔案，如下：
global_defs {
# 自帶的郵件提醒服務，建議用獨立的監控或第三方SMTP，也可選擇配置郵件發送。
notification_email {
root@localhost
}
notification_email_from root@localhost
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：
[root@localhost]# mkdir /soft/scripts /soft/scripts/keepalived
[root@localhost]# touch /soft/scripts/keepalived/check_nginx_pid_restart.sh
[root@localhost]# 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 ⑦更改編寫的腳本檔案的編碼格式，并賦予執行權限：
[root@localhost]# vi /soft/scripts/keepalived/check_nginx_pid_restart.sh
:set fileformat=unix # 在vi指令裡面執行，修改編碼格式
:set ff # 檢視修改後的編碼格式
[root@localhost]# chmod +x /soft/scripts/keepalived/check_nginx_pid_restart.sh ⑧因安裝keepalived時，是自定義的安裝位置，是以需要拷貝一些檔案到系統目錄中：
[root@localhost]# mkdir /etc/keepalived/
[root@localhost]# cp /soft/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/
[root@localhost]# cp /soft/keepalived/keepalived-2.2.4/keepalived/etc/init.d/keepalived /etc/init.d/
[root@localhost]# cp /soft/keepalived/etc/sysconfig/keepalived /etc/sysconfig/ ⑨将keepalived加入系統服務并設定開啟自啟動，然後測試啟動是否正常：
[root@localhost]# chkconfig keepalived on
[root@localhost]# systemctl daemon-reload
[root@localhost]# systemctl enable keepalived.service
[root@localhost]# 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是否生效，通過檢視本機是否成功挂載虛拟IP：
[root@localhost]# ip addr ❝
可以看見虛拟IP已經成功挂載，但另外一台機器192.168.12.130并不會挂載這個虛拟IP，隻有當主機下線後，作為備機的192.168.12.130才會上線，接替VIP。
❞
測試一下外網是否可以和VIP正常通信：
外部通過VIP通信正常，代表虛拟IP配置成功。
Nginx高可用性測試
keepalived的VIP機制主要做了幾件事：
- 一、為部署Nginx的機器挂載了VIP。
- 二、通過keepalived搭建了主從雙機熱備。
- 三、通過keepalived實作了Nginx當機重新開機。
如果要配域名改一下nginx.conf的配置：
sever{
listen 80;
# 這裡從機器的本地IP改為虛拟IP
server_name 192.168.12.111;
# 如果這裡配置的是域名，那麼則将域名的映射配置改為虛拟IP
} 測試一下效果：
❝
在上述過程中，首先分别啟動了keepalived、nginx服務，然後通過手動停止nginx的方式模拟了Nginx當機情況，過了片刻後再次查詢背景程序，我們會發現nginx依舊存活。
❞
可以看到，keepalived已經為我們實作了Nginx當機後自動重新開機的功能。
接着再模拟一下伺服器出現故障情況：
❝
我們手動關閉keepalived服務模拟了機器斷電、硬體損壞等情況（因為機器斷電等情況=主機中的keepalived程序消失），然後再次查詢了一下本機的IP資訊，很明顯會看到VIP消失了！
❞
在切換到備機：192.168.12.130看看情況：
❝
在主機當機後，VIP自動從主機轉移到了從機上。
❞
十四、Nginx性能優化
最後Nginx的性能優化，主要就簡單說說效益最高的幾個優化項。
優化一：開啟長連接配接配置
用Nginx作為代理服務時，建議開啟HTTP長連接配接，減少用戶端握手的次數，降低伺服器損耗，具體如下：
upstream xxx {
# 長連接配接數
keepalive 32;
# 每個長連接配接提供的最大請求數
keepalived_requests 100;
# 每個長連接配接沒有新的請求時，保持的最長時間
keepalive_timeout 60s;
} 優化二、開啟零拷貝技術
零拷貝在大多數性能較好的中間件中都有，如Kafka、Netty等，而Nginx中也可以配置資料零拷貝技術，如下：
sendfile on; # 開啟零拷貝機制 零拷貝讀取機制與傳統資源讀取機制的差別：
- 「傳統方式：」 硬體-->核心-->使用者空間-->程式空間-->程式核心空間-->網絡套接字
- 「零拷貝方式：」 硬體-->核心-->程式核心空間-->網絡套接字
優化三、開啟無延遲或多包共發機制
Nginx中tcp_nodelay、tcp_nopush兩個參數是比較關鍵的性能參數，如下開啟：
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核數開啟對應數量的工作程序，以此來提升整體的并發量支援，如下：
# 自動根據CPU核心數調整Worker程序數量
worker_processes auto; ❝
注意：工作程序的數量最高開到8個就OK了，8個之後就不會有再大的性能提升。
❞
同時也可以稍微調整一下每個工作程序能夠打開的檔案句柄數：
# 每個Worker能打開的檔案描述符，最少調整至1W以上，負荷較高建議2-3W
worker_rlimit_nofile 20000; ❝
作業系統核心（kernel）都是利用檔案描述符來通路檔案，無論是打開、建立、讀取、寫入檔案時，都需要使用檔案描述符來指定待操作的檔案，是以該值越大，代表一個程序能夠操作的檔案越多（但不能超出核心限制，最多建議3.8W左右為上限）。
❞
優化五、開啟CPU親和機制
對于并發程式設計較為熟悉的夥伴都知道，因為程序/線程數往往都會遠超出系統CPU的核心數，因為作業系統執行的原理本質上是采用時間片切換機制，也就是一個CPU核心會在多個程序之間不斷頻繁切換，造成很大的性能損耗。
而CPU親和機制則是指将每個Nginx的工作程序，綁定在固定的CPU核心上，進而減小CPU切換帶來的時間開銷和資源損耗，開啟方式如下：
worker_cpu_affinity auto; 優化六、開啟epoll模型及調整并發連接配接數
在最開始就提到過：Nginx、Redis都是基于多路複用模型去實作的程式，但最初版的多路複用模型select/poll最大隻能監聽1024個連接配接，而epoll則屬于select/poll接口的增強版，是以采用該模型能夠大程度上提升單個Worker的性能，如下：
events {
# 使用epoll網絡模型
use epoll;
# 調整每個Worker能夠處理的連接配接數上限
worker_connections 10240;
} 終于完了。。。。