引言
一、性能怪獸-Nginx概念深入淺出
二浅浮、Nginx環(huán)境搭建
三沫浆、Nginx反向代理-負(fù)載均衡
四、Nginx動(dòng)靜分離
五滚秩、Nginx資源壓縮
六专执、Nginx緩沖區(qū)
七、Nginx緩存機(jī)制
八郁油、Nginx實(shí)現(xiàn)IP黑白名單
九本股、Nginx跨域配置
十攀痊、Nginx防盜鏈設(shè)計(jì)
十一、Nginx大文件傳輸配置
十二拄显、Nginx配置SLL證書
十三苟径、Nginx的高可用
十四、Nginx性能優(yōu)化
十五躬审、放在最后的結(jié)尾
引言
早期的業(yè)務(wù)都是基于單體節(jié)點(diǎn)部署棘街，由于前期訪問流量不大，因此單體結(jié)構(gòu)也可滿足需求承边，但隨著業(yè)務(wù)增長遭殉，流量也越來越大，那么最終單臺(tái)服務(wù)器受到的訪問壓力也會(huì)逐步增高博助。時(shí)間一長险污，單臺(tái)服務(wù)器性能無法跟上業(yè)務(wù)增長，就會(huì)造成線上頻繁宕機(jī)的現(xiàn)象發(fā)生富岳，最終導(dǎo)致系統(tǒng)癱瘓無法繼續(xù)處理用戶的請(qǐng)求蛔糯。
因此在這種背景下，引入負(fù)載均衡技術(shù)可帶來的收益：
「系統(tǒng)的高可用：」 當(dāng)某個(gè)節(jié)點(diǎn)宕機(jī)后可以迅速將流量轉(zhuǎn)移至其他節(jié)點(diǎn)窖式。
「系統(tǒng)的高性能：」 多臺(tái)服務(wù)器共同對(duì)外提供服務(wù)渤闷，為整個(gè)系統(tǒng)提供了更高規(guī)模的吞吐。
「系統(tǒng)的拓展性：」 當(dāng)業(yè)務(wù)再次出現(xiàn)增長或萎靡時(shí)脖镀，可再加入/減少節(jié)點(diǎn)飒箭，靈活伸縮。
OK~蜒灰，既然引入負(fù)載均衡技術(shù)可給我們帶來如此巨大的好處弦蹂，那么又有那些方案可供選擇呢？主要有兩種負(fù)載方案强窖，「「硬件層面與軟件層面」」 凸椿，比較常用的硬件負(fù)載器有A10、F5等翅溺，但這些機(jī)器動(dòng)輒大幾萬乃至幾十萬的成本脑漫，因此一般大型企業(yè)會(huì)采用該方案，如銀行咙崎、國企优幸、央企等。而成本有限褪猛，但依舊想做負(fù)載均衡的項(xiàng)目网杆，那么可在軟件層面實(shí)現(xiàn)，如典型的Nginx等，軟件層的負(fù)載也是本文的重點(diǎn)碳却，畢竟Boss們的準(zhǔn)則之一就是：「「能靠技術(shù)實(shí)現(xiàn)的就盡量不花錢队秩。」」
一昼浦、性能怪獸-Nginx概念深入淺出
Nginx是目前負(fù)載均衡技術(shù)中的主流方案馍资，幾乎絕大部分項(xiàng)目都會(huì)使用它，Nginx是一個(gè)輕量級(jí)的高性能HTTP反向代理服務(wù)器关噪，同時(shí)它也是一個(gè)通用類型的代理服務(wù)器迷帜，支持絕大部分協(xié)議，如TCP色洞、UDP、SMTP冠胯、HTTPS等火诸。
Nginx與Redis相同，都是基于多路復(fù)用模型構(gòu)建出的產(chǎn)物荠察，因此它與Redis同樣具備 「「資源占用少置蜀、并發(fā)支持高」」 的特點(diǎn)，在理論上單節(jié)點(diǎn)的Nginx同時(shí)支持5W并發(fā)連接悉盆，而實(shí)際生產(chǎn)環(huán)境中盯荤，硬件基礎(chǔ)到位再結(jié)合簡單調(diào)優(yōu)后確實(shí)能達(dá)到該數(shù)值。
先來看看Nginx引入前后焕盟，客戶端請(qǐng)求處理流程的對(duì)比：
原本客戶端是直接請(qǐng)求目標(biāo)服務(wù)器秋秤，由目標(biāo)服務(wù)器直接完成請(qǐng)求處理工作，但加入Nginx后脚翘，所有的請(qǐng)求會(huì)先經(jīng)過Nginx灼卢，再由其進(jìn)行分發(fā)到具體的服務(wù)器處理，處理完成后再返回Nginx来农，最后由Nginx將最終的響應(yīng)結(jié)果返回給客戶端鞋真。
了解了Nginx的基本概念后，再來快速搭建一下環(huán)境沃于，以及了解一些Nginx的高級(jí)特性涩咖，如動(dòng)靜分離、資源壓縮繁莹、緩存配置檩互、IP黑名單、高可用保障等咨演。
二盾似、Nginx環(huán)境搭建
?首先創(chuàng)建Nginx的目錄并進(jìn)入：
[root@localhost]# mkdir /soft && mkdir /soft/nginx/
[root@localhost]# cd /soft/nginx/
?下載Nginx的安裝包，可以通過FTP工具上傳離線環(huán)境包，也可通過wget命令在線獲取安裝包：
[root@localhost]# wget https://nginx.org/download/nginx-1.21.6.tar.gz
沒有wget命令的可通過yum命令安裝：
[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
執(zhí)行完成后零院，然后ls查看目錄文件溉跃，會(huì)看一大堆依賴：
緊接著通過rpm命令依次將依賴包一個(gè)個(gè)構(gòu)建，或者通過如下指令一鍵安裝所有依賴包：
[root@localhost]# rpm -ivh --nodeps *.rpm
?進(jìn)入解壓后的nginx目錄告抄，然后執(zhí)行Nginx的配置腳本撰茎，為后續(xù)的安裝提前配置好環(huán)境，默認(rèn)位于/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
修改端口號(hào)：listen 80;
修改IP地址：server_name 你當(dāng)前機(jī)器的本地IP(線上配置域名);
?制定配置文件并啟動(dòng)Nginx：
[root@localhost]# sbin/nginx -c conf/nginx.conf
[root@localhost]# ps aux | grep nginx
Nginx其他操作命令：
sbin/nginx -t -c conf/nginx.conf # 檢測(cè)配置文件是否正常
sbin/nginx -s reload -c conf/nginx.conf # 修改配置后平滑重啟
sbin/nginx -s quit # 優(yōu)雅關(guān)閉Nginx，會(huì)在執(zhí)行完當(dāng)前的任務(wù)后再退出
sbin/nginx -s stop # 強(qiáng)制終止Nginx募疮，不管當(dāng)前是否有任務(wù)在執(zhí)行
?開放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
?在Windows/Mac的瀏覽器中，直接輸入剛剛配置的IP地址訪問Nginx：
最終看到如上的Nginx歡迎界面阿浓，代表Nginx安裝完成
三他嚷、Nginx反向代理-負(fù)載均衡
首先通過SpringBoot+Freemarker快速搭建一個(gè)WEB項(xiàng)目：springboot-web-nginx，然后在該項(xiàng)目中芭毙，創(chuàng)建一個(gè)IndexNginxController.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類中，存在一個(gè)成員變量：port退敦，它的值即是從application.properties配置文件中獲取server.port值粘咖。當(dāng)出現(xiàn)訪問/資源的請(qǐng)求時(shí)，跳轉(zhuǎn)前端index頁面侈百，并將該值攜帶返回瓮下。
前端的index.ftl文件代碼如下：
<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>歡迎來到熊貓高級(jí)會(huì)所，我是竹子${port}號(hào)钝域！</h1>
</div>
</div>
</body>
</html>
從上可以看出其邏輯并不復(fù)雜唱捣，僅是從響應(yīng)中獲取了port輸出。
OK~网梢，前提工作準(zhǔn)備就緒后震缭，再簡單修改一下nginx.conf的配置即可：
upstream nginx_boot{
# 30s內(nèi)檢查心跳發(fā)送兩次包，未回復(fù)就代表該機(jī)器宕機(jī)战虏，請(qǐng)求分發(fā)權(quán)重比為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請(qǐng)配置成你WEB服務(wù)所在的機(jī)器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;
# 請(qǐng)求交給名為nginx_boot的upstream上
proxy_pass http://nginx_boot;
}
}
最終來看看效果：
負(fù)載均衡效果-動(dòng)圖演示
因?yàn)榕渲昧苏?qǐng)求分發(fā)的權(quán)重烦感，8080巡社、8090的權(quán)重比為2:1，因此請(qǐng)求會(huì)根據(jù)權(quán)重比均攤到每臺(tái)機(jī)器手趣，也就是8080一次晌该、8090兩次肥荔、8080一次......
Nginx請(qǐng)求分發(fā)原理
客戶端發(fā)出的請(qǐng)求192.168.12.129最終會(huì)轉(zhuǎn)變?yōu)椋篽ttp://192.168.12.129:80/，然后再向目標(biāo)IP發(fā)起請(qǐng)求朝群，流程如下：
由于Nginx監(jiān)聽了192.168.12.129的80端口燕耿，所以最終該請(qǐng)求會(huì)找到Nginx進(jìn)程；
Nginx首先會(huì)根據(jù)配置的location規(guī)則進(jìn)行匹配姜胖，根據(jù)客戶端的請(qǐng)求路徑/誉帅，會(huì)定位到location /{}規(guī)則；
然后根據(jù)該location中配置的proxy_pass會(huì)再找到名為nginx_boot的upstream右莱；
最后根據(jù)upstream中的配置信息蚜锨，將請(qǐng)求轉(zhuǎn)發(fā)到運(yùn)行WEB服務(wù)的機(jī)器處理，由于配置了多個(gè)WEB服務(wù)慢蜓，且配置了權(quán)重值亚再，因此Nginx會(huì)依次根據(jù)權(quán)重比分發(fā)請(qǐng)求。
四晨抡、Nginx動(dòng)靜分離
動(dòng)靜分離應(yīng)該是聽的次數(shù)較多的性能優(yōu)化方案氛悬，那先思考一個(gè)問題：「「為什么需要做動(dòng)靜分離呢？它帶來的好處是什么凄诞？」」 其實(shí)這個(gè)問題也并不難回答，當(dāng)你搞懂了網(wǎng)站的本質(zhì)后忍级，自然就理解了動(dòng)靜分離的重要性帆谍。先來以淘寶為例分析看看：
當(dāng)瀏覽器輸入www.taobao.com訪問淘寶首頁時(shí)，打開開發(fā)者調(diào)試工具可以很明顯的看到轴咱，首頁加載會(huì)出現(xiàn)100+的請(qǐng)求數(shù)汛蝙，而正常項(xiàng)目開發(fā)時(shí)，靜態(tài)資源一般會(huì)放入到resources/static/目錄下：
IDEA 工程結(jié)構(gòu)
在項(xiàng)目上線部署時(shí)朴肺，這些靜態(tài)資源會(huì)一起打成包窖剑，那此時(shí)思考一個(gè)問題：「「假設(shè)淘寶也是這樣干的，那么首頁加載時(shí)的請(qǐng)求最終會(huì)去到哪兒被處理戈稿？」」 答案毋庸置疑西土，首頁100+的所有請(qǐng)求都會(huì)來到部署WEB服務(wù)的機(jī)器處理，那則代表著一個(gè)客戶端請(qǐng)求淘寶首頁鞍盗，就會(huì)對(duì)后端服務(wù)器造成100+的并發(fā)請(qǐng)求需了。毫無疑問，這對(duì)于后端服務(wù)器的壓力是尤為巨大的般甲。
既然有這么多請(qǐng)求屬于靜態(tài)的肋乍，這些資源大概率情況下，長時(shí)間也不會(huì)出現(xiàn)變動(dòng)敷存，那為何還要讓這些請(qǐng)求到后端再處理呢墓造？能不能在此之前就提前處理掉？當(dāng)然OK，因此經(jīng)過分析之后能夠明確一點(diǎn)：「「做了動(dòng)靜分離之后觅闽，至少能夠讓后端服務(wù)減少一半以上的并發(fā)量帝雇。」」 到此時(shí)大家應(yīng)該明白了動(dòng)靜分離能夠帶來的性能收益究竟有多大谱煤。
OK~摊求，搞清楚動(dòng)靜分離的必要性之后，如何實(shí)現(xiàn)動(dòng)靜分離呢刘离？其實(shí)非常簡單室叉，實(shí)戰(zhàn)看看。
①先在部署Nginx的機(jī)器硫惕，Nginx目錄下創(chuàng)建一個(gè)目錄static_resources：
mkdir static_resources
②將項(xiàng)目中所有的靜態(tài)資源全部拷貝到該目錄下茧痕，而后將項(xiàng)目中的靜態(tài)資源移除重新打包。
③稍微修改一下nginx.conf的配置恼除，增加一條location匹配規(guī)則：
location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css){
root /soft/nginx/static_resources;
expires 7d;
}
然后照常啟動(dòng)nginx和移除了靜態(tài)資源的WEB服務(wù)踪旷，你會(huì)發(fā)現(xiàn)原本的樣式、js效果豁辉、圖片等依舊有效令野，如下：
其中static目錄下的nginx_style.css文件已被移除，但效果依舊存在（綠色字體+藍(lán)色大邊框)：
移除后效果動(dòng)圖
最后解讀一下那條location規(guī)則：
location ~ .*\.(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css)
~代表匹配時(shí)區(qū)分大小寫
.*代表任意字符都可以出現(xiàn)零次或多次徽级，即資源名不限制
.代表匹配后綴分隔符.
(html|...|css)代表匹配括號(hào)里所有靜態(tài)資源類型
綜上所述气破，簡單一句話概述：該配置表示匹配以.html~.css為后綴的所有資源請(qǐng)求。
「最后提一嘴餐抢，也可以將靜態(tài)資源上傳到文件服務(wù)器中现使，然后location中配置一個(gè)新的upstream指向】鹾郏」
五碳锈、Nginx資源壓縮
建立在動(dòng)靜分離的基礎(chǔ)之上，如果一個(gè)靜態(tài)資源的Size越小欺抗，那么自然傳輸速度會(huì)更快售碳，同時(shí)也會(huì)更節(jié)省帶寬，因此我們?cè)诓渴痦?xiàng)目時(shí)绞呈，也可以通過Nginx對(duì)于靜態(tài)資源實(shí)現(xiàn)壓縮傳輸团滥，一方面可以節(jié)省帶寬資源，第二方面也可以加快響應(yīng)速度并提升系統(tǒng)整體吞吐报强。
在Nginx也提供了三個(gè)支持資源壓縮的模塊ngx_http_gzip_module灸姊、ngx_http_gzip_static_module、ngx_http_gunzip_module秉溉，其中ngx_http_gzip_module屬于內(nèi)置模塊力惯，代表著可以直接使用該模塊下的一些壓縮指令碗誉，后續(xù)的資源壓縮操作都基于該模塊，先來看看壓縮配置的一些參數(shù)/指令：
了解了Nginx中的基本壓縮配置后父晶，接下來可以在Nginx中簡單配置一下：
http{
# 開啟壓縮機(jī)制
gzip on;
# 指定會(huì)被壓縮的文件類型(也可自己配置其他類型)
gzip_types text/plain application/javascript text/css application/xml text/javascript image/jpeg image/gif image/png;
# 設(shè)置壓縮級(jí)別哮缺，越高資源消耗越大，但壓縮效果越好
gzip_comp_level 5;
# 在頭部中添加Vary: Accept-Encoding（建議開啟）
gzip_vary on;
# 處理壓縮請(qǐng)求的緩沖區(qū)數(shù)量和大小
gzip_buffers 16 8k;
# 對(duì)于不支持壓縮功能的客戶端請(qǐng)求不開啟壓縮機(jī)制
gzip_disable "MSIE [1-6]\."; # 低版本的IE瀏覽器不支持壓縮
# 設(shè)置壓縮響應(yīng)所支持的HTTP最低版本
gzip_http_version 1.1;
# 設(shè)置觸發(fā)壓縮的最小閾值
gzip_min_length 2k;
# 關(guān)閉對(duì)后端服務(wù)器的響應(yīng)結(jié)果進(jìn)行壓縮
gzip_proxied off;
}
在上述的壓縮配置中甲喝，最后一個(gè)gzip_proxied選項(xiàng)尝苇，可以根據(jù)系統(tǒng)的實(shí)際情況決定，總共存在多種選項(xiàng)：
off：關(guān)閉Nginx對(duì)后臺(tái)服務(wù)器的響應(yīng)結(jié)果進(jìn)行壓縮埠胖。
expired：如果響應(yīng)頭中包含Expires信息糠溜，則開啟壓縮。
no-cache：如果響應(yīng)頭中包含Cache-Control:no-cache信息直撤，則開啟壓縮非竿。
no-store：如果響應(yīng)頭中包含Cache-Control:no-store信息，則開啟壓縮谋竖。
private：如果響應(yīng)頭中包含Cache-Control:private信息红柱，則開啟壓縮。
no_last_modified：如果響應(yīng)頭中不包含Last-Modified信息蓖乘，則開啟壓縮锤悄。
no_etag：如果響應(yīng)頭中不包含ETag信息，則開啟壓縮嘉抒。
auth：如果響應(yīng)頭中包含Authorization信息零聚，則開啟壓縮。
any：無條件對(duì)后端的響應(yīng)結(jié)果開啟壓縮機(jī)制众眨。
OK~握牧，簡單修改好了Nginx的壓縮配置后容诬，可以在原本的index頁面中引入一個(gè)jquery-3.6.0.js文件：
<script type="text/javascript" src="jquery-3.6.0.js"></script>
分別來對(duì)比下壓縮前后的區(qū)別：
從圖中可以很明顯看出娩梨，未開啟壓縮機(jī)制前訪問時(shí)，js文件的原始大小為230K览徒，當(dāng)配置好壓縮后再重啟Nginx狈定，會(huì)發(fā)現(xiàn)文件大小從230KB→69KB，效果立竿見影习蓬！
六纽什、Nginx緩沖區(qū)
先來思考一個(gè)問題，接入Nginx的項(xiàng)目一般請(qǐng)求流程為：“客戶端→Nginx→服務(wù)端”躲叼，在這個(gè)過程中存在兩個(gè)連接：“客戶端→Nginx芦缰、Nginx→服務(wù)端”，那么兩個(gè)不同的連接速度不一致枫慷，就會(huì)影響用戶的體驗(yàn)（比如瀏覽器的加載速度跟不上服務(wù)端的響應(yīng)速度）让蕾。
其實(shí)也就類似電腦的內(nèi)存跟不上CPU速度浪规，所以對(duì)于用戶造成的體驗(yàn)感極差，因此在CPU設(shè)計(jì)時(shí)都會(huì)加入三級(jí)高速緩沖區(qū)探孝，用于緩解CPU和內(nèi)存速率不一致的矛盾笋婿。在Nginx也同樣存在緩沖區(qū)的機(jī)制，主要目的就在于：「「用來解決兩個(gè)連接之間速度不匹配造成的問題」」 顿颅，有了緩沖后缸濒，Nginx代理可暫存后端的響應(yīng)，然后按需供給數(shù)據(jù)給客戶端粱腻。先來看看一些關(guān)于緩沖區(qū)的配置項(xiàng)：
proxy_buffering：是否啟用緩沖機(jī)制庇配，默認(rèn)為on關(guān)閉狀態(tài)。
client_body_buffer_size：設(shè)置緩沖客戶端請(qǐng)求數(shù)據(jù)的內(nèi)存大小栖疑。
proxy_buffers：為每個(gè)請(qǐng)求/連接設(shè)置緩沖區(qū)的數(shù)量和大小讨永，默認(rèn)4 4k/8k。
proxy_buffer_size：設(shè)置用于存儲(chǔ)響應(yīng)頭的緩沖區(qū)大小遇革。
proxy_busy_buffers_size：在后端數(shù)據(jù)沒有完全接收完成時(shí)卿闹，Nginx可以將busy狀態(tài)的緩沖返回給客戶端，該參數(shù)用來設(shè)置busy狀態(tài)的buffer具體有多大萝快，默認(rèn)為proxy_buffer_size*2锻霎。
proxy_temp_path：當(dāng)內(nèi)存緩沖區(qū)存滿時(shí)，可以將數(shù)據(jù)臨時(shí)存放到磁盤揪漩，該參數(shù)是設(shè)置存儲(chǔ)緩沖數(shù)據(jù)的目錄旋恼。
path是臨時(shí)目錄的路徑。
語法：proxy_temp_path path; path是臨時(shí)目錄的路徑
proxy_temp_file_write_size：設(shè)置每次寫數(shù)據(jù)到臨時(shí)文件的大小限制奄容。
proxy_max_temp_file_size：設(shè)置臨時(shí)的緩沖目錄中允許存儲(chǔ)的最大容量冰更。
非緩沖參數(shù)項(xiàng)：
proxy_connect_timeout：設(shè)置與后端服務(wù)器建立連接時(shí)的超時(shí)時(shí)間。
proxy_read_timeout：設(shè)置從后端服務(wù)器讀取響應(yīng)數(shù)據(jù)的超時(shí)時(shí)間昂勒。
proxy_send_timeout：設(shè)置向后端服務(wù)器傳輸請(qǐng)求數(shù)據(jù)的超時(shí)時(shí)間蜀细。
具體的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;
}
上述的緩沖區(qū)參數(shù)，是基于每個(gè)請(qǐng)求分配的空間戈盈，而并不是所有請(qǐng)求的共享空間奠衔。當(dāng)然，具體的參數(shù)值還需要根據(jù)業(yè)務(wù)去決定塘娶，要綜合考慮機(jī)器的內(nèi)存以及每個(gè)請(qǐng)求的平均數(shù)據(jù)大小归斤。
七、Nginx緩存機(jī)制
對(duì)于性能優(yōu)化而言刁岸，緩存是一種能夠大幅度提升性能的方案脏里，因此幾乎可以在各處都能看見緩存，如客戶端緩存虹曙、代理緩存迫横、服務(wù)器緩存等等鸦难，Nginx的緩存則屬于代理緩存的一種。對(duì)于整個(gè)系統(tǒng)而言员淫，加入緩存帶來的優(yōu)勢(shì)額外明顯：
減少了再次向后端或文件服務(wù)器請(qǐng)求資源的帶寬消耗合蔽。
降低了下游服務(wù)器的訪問壓力，提升系統(tǒng)整體吞吐介返。
縮短了響應(yīng)時(shí)間拴事，提升了加載速度，打開頁面的速度更快圣蝎。
那么在Nginx中刃宵，又該如何配置代理緩存呢？先來看看緩存相關(guān)的配置項(xiàng)：
「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];
是的牲证，你沒有看錯(cuò)，就是這么長....关面，解釋一下每個(gè)參數(shù)項(xiàng)的含義：
path：緩存的路徑地址坦袍。
levels：緩存存儲(chǔ)的層次結(jié)構(gòu)，最多允許三層目錄等太。
use_temp_path：是否使用臨時(shí)目錄捂齐。
keys_zone：指定一個(gè)共享內(nèi)存空間來存儲(chǔ)熱點(diǎn)Key(1M可存儲(chǔ)8000個(gè)Key)。
inactive：設(shè)置緩存多長時(shí)間未被訪問后刪除（默認(rèn)是十分鐘）缩抡。
max_size：允許緩存的最大存儲(chǔ)空間奠宜，超出后會(huì)基于LRU算法移除緩存，Nginx會(huì)創(chuàng)建一個(gè)Cache manager的進(jìn)程移除數(shù)據(jù)瞻想，也可以通過purge方式压真。
manager_files：manager進(jìn)程每次移除緩存文件數(shù)量的上限。
manager_sleep：manager進(jìn)程每次移除緩存文件的時(shí)間上限蘑险。
manager_threshold：manager進(jìn)程每次移除緩存后的間隔時(shí)間滴肿。
loader_files：重啟Nginx載入緩存時(shí)，每次加載的個(gè)數(shù)漠其，默認(rèn)100嘴高。
loader_sleep：每次載入時(shí)竿音，允許的最大時(shí)間上限，默認(rèn)200ms。
loader_threshold：一次載入后惑灵，停頓的時(shí)間間隔鸭津，默認(rèn)50ms。
purger：是否開啟purge方式移除數(shù)據(jù)宽气。
purger_files：每次移除緩存文件時(shí)的數(shù)量随常。
purger_sleep：每次移除時(shí)潜沦，允許消耗的最大時(shí)間。
purger_threshold：每次移除完成后绪氛，停頓的間隔時(shí)間唆鸡。
「proxy_cache」：開啟或關(guān)閉代理緩存，開啟時(shí)需要指定一個(gè)共享內(nèi)存區(qū)域枣察。
語法：
proxy_cache zone | off;
zone為內(nèi)存區(qū)域的名稱争占，即上面中keys_zone設(shè)置的名稱。
「proxy_cache_key」：定義如何生成緩存的鍵序目。
語法：
proxy_cache_key string;
string為生成Key的規(guī)則臂痕，如proxy_host$request_uri。
「proxy_cache_valid」：緩存生效的狀態(tài)碼與過期時(shí)間猿涨。
語法：
proxy_cache_valid [code ...] time;
code為狀態(tài)碼握童，time為有效時(shí)間，可以根據(jù)狀態(tài)碼設(shè)置不同的緩存時(shí)間叛赚。
例如：proxy_cache_valid 200 302 30m;
「proxy_cache_min_uses」：設(shè)置資源被請(qǐng)求多少次后被緩存澡绩。
語法：
proxy_cache_min_uses number;
number為次數(shù)，默認(rèn)為1俺附。
「proxy_cache_use_stale」：當(dāng)后端出現(xiàn)異常時(shí)英古，是否允許Nginx返回緩存作為響應(yīng)。
語法：
proxy_cache_use_stale error;
error為錯(cuò)誤類型昙读，可配置timeout|invalid_header|updating|http_500...召调。
「proxy_cache_lock」：對(duì)于相同的請(qǐng)求，是否開啟鎖機(jī)制蛮浑，只允許一個(gè)請(qǐng)求發(fā)往后端唠叛。
語法：
proxy_cache_lock on | off;
「proxy_cache_lock_timeout」：配置鎖超時(shí)機(jī)制，超出規(guī)定時(shí)間后會(huì)釋放請(qǐng)求沮稚。
proxy_cache_lock_timeout time;
「proxy_cache_methods」：設(shè)置對(duì)于那些HTTP方法開啟緩存艺沼。
語法：
proxy_cache_methods method;
method為請(qǐng)求方法類型，如GET蕴掏、HEAD等障般。
「proxy_no_cache」：定義不存儲(chǔ)緩存的條件，符合時(shí)不會(huì)保存盛杰。
語法：
proxy_no_cache string...;
string為條件挽荡，例如arg_nocache $arg_comment;
「proxy_cache_bypass」：定義不讀取緩存的條件，符合時(shí)不會(huì)從緩存中讀取即供。
語法：
proxy_cache_bypass string...;
和上面proxy_no_cache的配置方法類似定拟。
「add_header」：往響應(yīng)頭中添加字段信息。
語法：
add_header fieldName fieldValue;
「$upstream_cache_status」：記錄了緩存是否命中的信息逗嫡，存在多種情況：
MISS：請(qǐng)求未命中緩存青自。
HIT：請(qǐng)求命中緩存株依。
EXPIRED：請(qǐng)求命中緩存但緩存已過期。
STALE：請(qǐng)求命中了陳舊緩存延窜。
REVALIDDATED：Nginx驗(yàn)證陳舊緩存依然有效恋腕。
UPDATING：命中的緩存內(nèi)容陳舊，但正在更新緩存逆瑞。
BYPASS：響應(yīng)結(jié)果是從原始服務(wù)器獲取的吗坚。
OK~，對(duì)于Nginx中的緩存配置項(xiàng)大概了解后呆万，接著來配置一下Nginx代理緩存：
http{
# 設(shè)置緩存的目錄商源，并且內(nèi)存中緩存區(qū)名為hot_cache，大小為128m谋减，
# 三天未被訪問過的緩存自動(dòng)清楚牡彻，磁盤中緩存的最大容量為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;
# 對(duì)于200出爹、206庄吼、304、301严就、302狀態(tài)碼的數(shù)據(jù)緩存1天
proxy_cache_valid 200 206 304 301 302 1d;
# 對(duì)于其他狀態(tài)的數(shù)據(jù)緩存30分鐘
proxy_cache_valid any 30m;
# 定義生成緩存鍵的規(guī)則（請(qǐng)求的url+參數(shù)作為key）
proxy_cache_key $host$uri$is_args$args;
# 資源至少被重復(fù)訪問三次后再加入緩存
proxy_cache_min_uses 3;
# 出現(xiàn)重復(fù)請(qǐng)求時(shí)总寻，只讓一個(gè)去后端讀數(shù)據(jù)，其他的從緩存中讀取
proxy_cache_lock on;
# 上面的鎖超時(shí)時(shí)間為3s梢为，超過3s未獲取數(shù)據(jù)渐行，其他請(qǐng)求直接去后端
proxy_cache_lock_timeout 3s;
# 對(duì)于請(qǐng)求參數(shù)或cookie中聲明了不緩存的數(shù)據(jù)，不再加入緩存
proxy_no_cache $cookie_nocache $arg_nocache $arg_comment;
# 在響應(yīng)頭中添加一個(gè)緩存是否命中的狀態(tài)（便于調(diào)試）
add_header Cache-status $upstream_cache_status;
}
}
}
接著來看一下效果铸董，如下：
第一次訪問時(shí)祟印，因?yàn)檫€沒有請(qǐng)求過資源，所以緩存中沒有數(shù)據(jù)粟害，因此沒有命中緩存蕴忆。第二、三次悲幅，依舊沒有命中緩存套鹅，直至第四次時(shí)才顯示命中，這是為什么呢汰具？因?yàn)樵谇懊娴木彺媾渲弥凶柯梗覀兣渲昧思尤刖彺娴淖畹蜅l件為：「「資源至少要被請(qǐng)求三次以上才會(huì)加入緩存∮舾保」」 這樣可以避免很多無效緩存占用空間减牺。
緩存清理
當(dāng)緩存過多時(shí)豌习，如果不及時(shí)清理會(huì)導(dǎo)致磁盤空間被“吃光”存谎，因此我們需要一套完善的緩存清理機(jī)制去刪除緩存拔疚，在之前的proxy_cache_path參數(shù)中有purger相關(guān)的選項(xiàng)，開啟后可以幫我們自動(dòng)清理緩存既荚，但遺憾的是：purger系列參數(shù)只有商業(yè)版的NginxPlus才能使用稚失，因此需要付費(fèi)才可使用。
不過天無絕人之路恰聘，我們可以通過強(qiáng)大的第三方模塊ngx_cache_purge來替代句各，先來安裝一下該插件：①首先去到Nginx的安裝目錄下，創(chuàng)建一個(gè)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
④重新構(gòu)建一次Nginx晴叨，通過--add-module的指令添加剛剛的第三方模塊：
[root@localhost]# ./configure --prefix=/soft/nginx/ --add-module=/soft/nginx/cache_purge/ngx_cache_purge-2.3/
⑤重新根據(jù)剛剛構(gòu)建的Nginx凿宾，再次編譯一下，「但切記不要make install」 ：
[root@localhost]# make
⑥刪除之前Nginx的啟動(dòng)文件兼蕊，不放心的也可以移動(dòng)到其他位置：
[root@localhost]# rm -rf /soft/nginx/sbin/nginx
⑦從生成的objs目錄中初厚，重新復(fù)制一個(gè)Nginx的啟動(dòng)文件到原來的位置：
[root@localhost]# cp objs/nginx /soft/nginx/sbin/nginx
至此，第三方緩存清除模塊ngx_cache_purge就安裝完成了孙技，接下來稍微修改一下nginx.conf配置产禾，再添加一條location規(guī)則：
location ~ /purge(/.*) {
# 配置可以執(zhí)行清除操作的IP（線上可以配置成內(nèi)網(wǎng)機(jī)器）
# allow 127.0.0.1; # 代表本機(jī)
allow all; # 代表允許任意IP清除緩存
proxy_cache_purge $host$1$is_args$args;
}
然后再重啟Nginx，接下來即可通過http://xxx/purge/xx的方式清除緩存牵啦。
八亚情、Nginx實(shí)現(xiàn)IP黑白名單
有時(shí)候往往有些需求，可能某些接口只能開放給對(duì)應(yīng)的合作商哈雏，或者購買/接入API的合作伙伴楞件，那么此時(shí)就需要實(shí)現(xiàn)類似于IP白名單的功能。而有時(shí)候有些惡意攻擊者或爬蟲程序裳瘪，被識(shí)別后需要禁止其再次訪問網(wǎng)站履因，因此也需要實(shí)現(xiàn)IP黑名單。那么這些功能無需交由后端實(shí)現(xiàn)盹愚，可直接在Nginx中處理栅迄。
Nginx做黑白名單機(jī)制，主要是通過allow皆怕、deny配置項(xiàng)來實(shí)現(xiàn)：
allow xxx.xxx.xxx.xxx; # 允許指定的IP訪問毅舆，可以用于實(shí)現(xiàn)白名單。
deny xxx.xxx.xxx.xxx; # 禁止指定的IP訪問愈腾，可以用于實(shí)現(xiàn)黑名單憋活。
要同時(shí)屏蔽/開放多個(gè)IP訪問時(shí)，如果所有IP全部寫在nginx.conf文件中定然是不顯示的虱黄，這種方式比較冗余悦即，那么可以新建兩個(gè)文件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網(wǎng)段中的所有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網(wǎng)段中的所有IP訪問
deny all; # 除開上述IP外，其他IP全部禁止訪問
分別將要禁止/開放的IP添加到對(duì)應(yīng)的文件后辜梳，可以再將這兩個(gè)文件在nginx.conf中導(dǎo)入：
http{
# 屏蔽該文件中的所有IP
include /soft/nginx/IP/BlocksIP.conf;
server{
location xxx {
# 某一系列接口只開放給白名單中的IP
include /soft/nginx/IP/blockip.conf;
}
}
}
對(duì)于文件具體在哪兒導(dǎo)入粱甫，這個(gè)也并非隨意的，如果要整站屏蔽/開放就在http中導(dǎo)入作瞄，如果只需要一個(gè)域名下屏蔽/開放就在sever中導(dǎo)入茶宵，如果只需要針對(duì)于某一系列接口屏蔽/開放IP，那么就在location中導(dǎo)入宗挥。
九乌庶、Nginx跨域配置
跨域問題在之前的單體架構(gòu)開發(fā)中，其實(shí)是比較少見的問題契耿，除非是需要接入第三方SDK時(shí)瞒大，才需要處理此問題。但隨著現(xiàn)在前后端分離搪桂、分布式架構(gòu)的流行糠赦，跨域問題也成為了每個(gè)Java開發(fā)必須要懂得解決的一個(gè)問題。
跨域問題產(chǎn)生的原因
產(chǎn)生跨域問題的主要原因就在于 「同源策略」 锅棕，為了保證用戶信息安全拙泽，防止惡意網(wǎng)站竊取數(shù)據(jù)，同源策略是必須的裸燎，否則cookie可以共享顾瞻。由于http無狀態(tài)協(xié)議通常會(huì)借助cookie來實(shí)現(xiàn)有狀態(tài)的信息記錄，例如用戶的身份/密碼等德绿，因此一旦cookie被共享荷荤，那么會(huì)導(dǎo)致用戶的身份信息被盜取。
同源策略主要是指三點(diǎn)相同移稳，「「協(xié)議+域名+端口」」 相同的兩個(gè)請(qǐng)求蕴纳，則可以被看做是同源的，但如果其中任意一點(diǎn)存在不同个粱，則代表是兩個(gè)不同源的請(qǐng)求古毛，同源策略會(huì)限制了不同源之間的資源交互。
Nginx解決跨域問題
弄明白了跨域問題的產(chǎn)生原因都许，接下來看看Nginx中又該如何解決跨域呢稻薇？其實(shí)比較簡單，在nginx.conf中稍微添加一點(diǎn)配置即可：
location / {
# 允許跨域的請(qǐng)求胶征，可以自定義變量$http_origin塞椎，*表示所有
add_header 'Access-Control-Allow-Origin' *;
# 允許攜帶cookie請(qǐng)求
add_header 'Access-Control-Allow-Credentials' 'true';
# 允許跨域請(qǐng)求的方法：GET,POST,OPTIONS,PUT
add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT';
# 允許請(qǐng)求時(shí)攜帶的頭部信息，*表示所有
add_header 'Access-Control-Allow-Headers' *;
# 允許發(fā)送按段獲取資源的請(qǐng)求
add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
# 一定要有＞Φ汀０负荨服傍！否則Post請(qǐng)求無法進(jìn)行跨域！
# 在發(fā)送Post跨域請(qǐng)求前骂铁，會(huì)以O(shè)ptions方式發(fā)送預(yù)檢請(qǐng)求吹零，服務(wù)器接受時(shí)才會(huì)正式請(qǐng)求
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;
# 對(duì)于Options方式的請(qǐng)求返回204，表示接受跨域請(qǐng)求
return 204;
}
}
在nginx.conf文件加上如上配置后从铲，跨域請(qǐng)求即可生效了瘪校。
十澄暮、Nginx防盜鏈設(shè)計(jì)
首先了解一下何謂盜鏈：「「盜鏈即是指外部網(wǎng)站引入當(dāng)前網(wǎng)站的資源對(duì)外展示」」 名段，來舉個(gè)簡單的例子理解：
?好比壁紙網(wǎng)站X站、Y站泣懊，X站是一點(diǎn)點(diǎn)去購買版權(quán)伸辟、簽約作者的方式，從而積累了海量的壁紙素材馍刮，但Y站由于資金等各方面的原因信夫，就直接通過<img src="X站/xxx.jpg" />這種方式照搬了X站的所有壁紙資源，繼而提供給用戶下載卡啰。
?
那么如果我們自己是這個(gè)X站的Boss静稻，心中必然不爽，那么此時(shí)又該如何屏蔽這類問題呢匈辱？那么接下來要敘說的「「防盜鏈」」 登場了振湾！
Nginx的防盜鏈機(jī)制實(shí)現(xiàn)，跟一個(gè)頭部字段：Referer有關(guān)亡脸，該字段主要描述了當(dāng)前請(qǐng)求是從哪兒發(fā)出的押搪，那么在Nginx中就可獲取該值，然后判斷是否為本站的資源引用請(qǐng)求浅碾，如果不是則不允許訪問大州。Nginx中存在一個(gè)配置項(xiàng)為valid_referers，正好可以滿足前面的需求垂谢，語法如下：
valid_referers none | blocked | server_names | string ...;
none：表示接受沒有Referer字段的HTTP請(qǐng)求訪問厦画。
blocked：表示允許http://或https//以外的請(qǐng)求訪問。
server_names：資源的白名單滥朱，這里可以指定允許訪問的域名苛白。
string：可自定義字符串，支配通配符焚虱、正則表達(dá)式寫法购裙。
簡單了解語法后，接下來的實(shí)現(xiàn)如下：
# 在動(dòng)靜分離的location中開啟防盜鏈機(jī)制
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;
}
根據(jù)上述中的內(nèi)容配置后鹃栽，就已經(jīng)通過Nginx實(shí)現(xiàn)了最基本的防盜鏈機(jī)制躏率，最后只需要額外重啟一下就好啦躯畴！當(dāng)然，對(duì)于防盜鏈機(jī)制實(shí)現(xiàn)這塊薇芝，也有專門的第三方模塊ngx_http_accesskey_module實(shí)現(xiàn)了更為完善的設(shè)計(jì)蓬抄，感興趣的小伙伴可以自行去看看。
?
PS：防盜鏈機(jī)制也無法解決爬蟲偽造referers信息的這種方式抓取數(shù)據(jù)夯到。
?
十一嚷缭、Nginx大文件傳輸配置
在某些業(yè)務(wù)場景中需要傳輸一些大文件，但大文件傳輸時(shí)往往都會(huì)會(huì)出現(xiàn)一些Bug耍贾，比如文件超出限制阅爽、文件傳輸過程中請(qǐng)求超時(shí)等，那么此時(shí)就可以在Nginx稍微做一些配置荐开，先來了解一些關(guān)于大文件傳輸時(shí)可能會(huì)用的配置項(xiàng)：
在傳輸大文件時(shí)付翁，client_max_body_size、client_header_timeout晃听、proxy_read_timeout百侧、proxy_send_timeout這四個(gè)參數(shù)值都可以根據(jù)自己項(xiàng)目的實(shí)際情況來配置。
?
上述配置僅是作為代理層需要配置的能扒，因?yàn)樽罱K客戶端傳輸文件還是直接與后端進(jìn)行交互佣渴，這里只是把作為網(wǎng)關(guān)層的Nginx配置調(diào)高一點(diǎn)，調(diào)到能夠“容納大文件”傳輸?shù)某潭瘸醢摺．?dāng)然辛润，Nginx中也可以作為文件服務(wù)器使用，但需要用到一個(gè)專門的第三方模塊nginx-upload-module越平，如果項(xiàng)目中文件上傳的作用處不多频蛔，那么建議可以通過Nginx搭建，畢竟可以節(jié)省一臺(tái)文件服務(wù)器資源秦叛。但如若文件上傳/下載較為頻繁晦溪，那么還是建議額外搭建文件服務(wù)器，并將上傳/下載功能交由后端處理挣跋。
?
十二三圆、Nginx配置SLL證書
隨著越來越多的網(wǎng)站接入HTTPS，因此Nginx中僅配置HTTP還不夠避咆，往往還需要監(jiān)聽443端口的請(qǐng)求舟肉，HTTPS為了確保通信安全，所以服務(wù)端需配置對(duì)應(yīng)的數(shù)字證書查库，當(dāng)項(xiàng)目使用Nginx作為網(wǎng)關(guān)時(shí)路媚，那么證書在Nginx中也需要配置，接下來簡單聊一下關(guān)于SSL證書配置過程：
①先去CA機(jī)構(gòu)或從云控制臺(tái)中申請(qǐng)對(duì)應(yīng)的SSL證書樊销，審核通過后下載Nginx版本的證書整慎。
②下載數(shù)字證書后脏款，完整的文件總共有三個(gè)：.crt、.key裤园、.pem：
.crt：數(shù)字證書文件撤师，.crt是.pem的拓展文件，因此有些人下載后可能沒有拧揽。
.key：服務(wù)器的私鑰文件剃盾，及非對(duì)稱加密的私鑰，用于解密公鑰傳輸?shù)臄?shù)據(jù)淤袜。
.pem：Base64-encoded編碼格式的源證書文本文件痒谴，可自行根需求修改拓展名。
③在Nginx目錄下新建certificate目錄饮怯，并將下載好的證書/私鑰等文件上傳至該目錄闰歪。
④最后修改一下nginx.conf文件即可嚎研，如下：
# ----------HTTPS配置-----------
server {
# 監(jiān)聽HTTPS默認(rèn)的443端口
listen 443;
# 配置自己項(xiàng)目的域名
server_name www.xxx.com;
# 打開SSL加密傳輸
ssl on;
# 輸入域名后蓖墅，首頁文件所在的目錄
root html;
# 配置首頁的文件名
index index.html index.htm index.jsp index.ftl;
# 配置自己下載的數(shù)字證書
ssl_certificate certificate/xxx.pem;
# 配置自己下載的服務(wù)器私鑰
ssl_certificate_key certificate/xxx.key;
# 停止通信時(shí)，加密會(huì)話的有效期临扮，在該時(shí)間段內(nèi)不需要重新交換密鑰
ssl_session_timeout 5m;
# TLS握手時(shí)论矾，服務(wù)器采用的密碼套件
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
# 服務(wù)器支持的TLS版本
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# 開啟由服務(wù)器決定采用的密碼套件
ssl_prefer_server_ciphers on;
location / {
....
}
}
# ---------HTTP請(qǐng)求轉(zhuǎn)HTTPS-------------
server {
# 監(jiān)聽HTTP默認(rèn)的80端口
listen 80;
# 如果80端口出現(xiàn)訪問該域名的請(qǐng)求
server_name www.xxx.com;
# 將請(qǐng)求改寫為HTTPS（這里寫你配置了HTTPS的域名）
rewrite ^(.*)$ https://www.xxx.com;
}
OK~，根據(jù)如上配置了Nginx后杆勇，你的網(wǎng)站即可通過https://的方式訪問贪壳，并且當(dāng)客戶端使用http://的方式訪問時(shí)，會(huì)自動(dòng)將其改寫為HTTPS請(qǐng)求蚜退。
十三闰靴、Nginx的高可用
線上如果采用單個(gè)節(jié)點(diǎn)的方式部署Nginx，難免會(huì)出現(xiàn)天災(zāi)人禍钻注，比如系統(tǒng)異常蚂且、程序宕機(jī)、服務(wù)器斷電幅恋、機(jī)房爆炸杏死、地球毀滅....哈哈哈，夸張了捆交。但實(shí)際生產(chǎn)環(huán)境中確實(shí)存在隱患問題淑翼，由于Nginx作為整個(gè)系統(tǒng)的網(wǎng)關(guān)層接入外部流量，所以一旦Nginx宕機(jī)品追，最終就會(huì)導(dǎo)致整個(gè)系統(tǒng)不可用玄括，這無疑對(duì)于用戶的體驗(yàn)感是極差的，因此也得保障Nginx高可用的特性肉瓦。
?
接下來則會(huì)通過keepalived的VIP機(jī)制蛹疯，實(shí)現(xiàn)Nginx的高可用苦始。VIP并不是只會(huì)員的意思，而是指Virtual IP赚爵，即虛擬IP。
?
keepalived在之前單體架構(gòu)開發(fā)時(shí)千所，是一個(gè)用的較為頻繁的高可用技術(shù)籽孙，比如MySQL、Redis嗦随、MQ呜舒、Proxy蔚袍、Tomcat等各處都會(huì)通過keepalived提供的VIP機(jī)制霸饲，實(shí)現(xiàn)單節(jié)點(diǎn)應(yīng)用的高可用。
Keepalived+重啟腳本+雙機(jī)熱備搭建
①首先創(chuàng)建一個(gè)對(duì)應(yīng)的目錄并下載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
②進(jìn)入解壓后的keepalived目錄并構(gòu)建安裝環(huán)境精钮，然后編譯并安裝：
[root@localhost]# cd keepalived-2.2.4
[root@localhost]# ./configure --prefix=/soft/keepalived/
[root@localhost]# make && make install
③進(jìn)入安裝目錄的/soft/keepalived/etc/keepalived/并編輯配置文件：
[root@localhost]# cd /soft/keepalived/etc/keepalived/
[root@localhost]# vi keepalived.conf
④編輯主機(jī)的keepalived.conf核心配置文件威鹿，如下：
global_defs {
# 自帶的郵件提醒服務(wù)，建議用獨(dú)立的監(jiān)控或第三方SMTP轨香，也可選擇配置郵件發(fā)送忽你。
notification_email {
root@localhost
}
notification_email_from root@localhost
smtp_server localhost
smtp_connect_timeout 30
# 高可用集群主機(jī)身份標(biāo)識(shí)(集群中主機(jī)身份標(biāo)識(shí)名稱不能重復(fù)，建議配置成本機(jī)IP)
router_id 192.168.12.129
}
# 定時(shí)運(yùn)行的腳本文件配置
vrrp_script check_nginx_pid_restart {
# 之前編寫的nginx重啟腳本的所在位置
script "/soft/scripts/keepalived/check_nginx_pid_restart.sh"
# 每間隔3秒執(zhí)行一次
interval 3
# 如果腳本中的條件成立臂容，重啟一次則權(quán)重-20
weight -20
}
# 定義虛擬路由科雳，VI_1為虛擬路由的標(biāo)示符（可自定義名稱）
vrrp_instance VI_1 {
# 當(dāng)前節(jié)點(diǎn)的身份標(biāo)識(shí)：用來決定主從（MASTER為主機(jī)，BACKUP為從機(jī)）
state MASTER
# 綁定虛擬IP的網(wǎng)絡(luò)接口脓杉，根據(jù)自己的機(jī)器的網(wǎng)卡配置
interface ens33
# 虛擬路由的ID號(hào)糟秘，主從兩個(gè)節(jié)點(diǎn)設(shè)置必須一樣
virtual_router_id 121
# 填寫本機(jī)IP
mcast_src_ip 192.168.12.129
# 節(jié)點(diǎn)權(quán)重優(yōu)先級(jí)，主節(jié)點(diǎn)要比從節(jié)點(diǎn)優(yōu)先級(jí)高
priority 100
# 優(yōu)先級(jí)高的設(shè)置nopreempt球散，解決異衬蜃恢復(fù)后再次搶占造成的腦裂問題
nopreempt
# 組播信息發(fā)送間隔，兩個(gè)節(jié)點(diǎn)設(shè)置必須一樣蕉堰，默認(rèn)1s（類似于心跳檢測(cè)）
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
# 將track_script塊加入instance配置塊
track_script {
# 執(zhí)行Nginx監(jiān)控的腳本
check_nginx_pid_restart
}
virtual_ipaddress {
# 虛擬IP(VIP)凌净，也可擴(kuò)展，可配置多個(gè)屋讶。
192.168.12.111
}
}
⑤克隆一臺(tái)之前的虛擬機(jī)作為從（備）機(jī)冰寻，編輯從機(jī)的keepalived.conf文件，如下：
global_defs {
# 自帶的郵件提醒服務(wù)皿渗，建議用獨(dú)立的監(jiān)控或第三方SMTP斩芭，也可選擇配置郵件發(fā)送。
notification_email {
root@localhost
}
notification_email_from root@localhost
smtp_server localhost
smtp_connect_timeout 30
# 高可用集群主機(jī)身份標(biāo)識(shí)(集群中主機(jī)身份標(biāo)識(shí)名稱不能重復(fù)乐疆，建議配置成本機(jī)IP)
router_id 192.168.12.130
}
# 定時(shí)運(yùn)行的腳本文件配置
vrrp_script check_nginx_pid_restart {
# 之前編寫的nginx重啟腳本的所在位置
script "/soft/scripts/keepalived/check_nginx_pid_restart.sh"
# 每間隔3秒執(zhí)行一次
interval 3
# 如果腳本中的條件成立划乖，重啟一次則權(quán)重-20
weight -20
}
# 定義虛擬路由，VI_1為虛擬路由的標(biāo)示符（可自定義名稱）
vrrp_instance VI_1 {
# 當(dāng)前節(jié)點(diǎn)的身份標(biāo)識(shí)：用來決定主從（MASTER為主機(jī)诀拭，BACKUP為從機(jī)）
state BACKUP
# 綁定虛擬IP的網(wǎng)絡(luò)接口迁筛，根據(jù)自己的機(jī)器的網(wǎng)卡配置
interface ens33
# 虛擬路由的ID號(hào)，主從兩個(gè)節(jié)點(diǎn)設(shè)置必須一樣
virtual_router_id 121
# 填寫本機(jī)IP
mcast_src_ip 192.168.12.130
# 節(jié)點(diǎn)權(quán)重優(yōu)先級(jí)，主節(jié)點(diǎn)要比從節(jié)點(diǎn)優(yōu)先級(jí)高
priority 90
# 優(yōu)先級(jí)高的設(shè)置nopreempt细卧，解決異澄咀恢復(fù)后再次搶占造成的腦裂問題
nopreempt
# 組播信息發(fā)送間隔，兩個(gè)節(jié)點(diǎn)設(shè)置必須一樣贪庙，默認(rèn)1s（類似于心跳檢測(cè)）
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
# 將track_script塊加入instance配置塊
track_script {
# 執(zhí)行Nginx監(jiān)控的腳本
check_nginx_pid_restart
}
virtual_ipaddress {
# 虛擬IP(VIP)蜘犁，也可擴(kuò)展，可配置多個(gè)止邮。
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指令查詢后臺(tái)的nginx進(jìn)程數(shù)，并將其保存在變量nginx_number中
nginx_number=`ps -C nginx --no-header | wc -l`
# 判斷后臺(tái)是否還有Nginx進(jìn)程在運(yùn)行
if [ $nginx_number -eq 0 ];then
# 如果后臺(tái)查詢不到`Nginx`進(jìn)程存在导披，則執(zhí)行重啟指令
/soft/nginx/sbin/nginx -c /soft/nginx/conf/nginx.conf
# 重啟后等待1s后屈扎，再次查詢后臺(tái)進(jìn)程數(shù)
sleep 1
# 如果重啟后依舊無法查詢到nginx進(jìn)程
if [ `ps -C nginx --no-header | wc -l` -eq 0 ];then
# 將keepalived主機(jī)下線，將虛擬IP漂移給從機(jī)撩匕，從機(jī)上線接管Nginx服務(wù)
systemctl stop keepalived.service
fi
fi
⑦編寫的腳本文件需要更改編碼格式鹰晨，并賦予執(zhí)行權(quán)限，否則可能執(zhí)行失斨贡稀：
[root@localhost]# vi /soft/scripts/keepalived/check_nginx_pid_restart.sh
:set fileformat=unix # 在vi命令里面執(zhí)行模蜡，修改編碼格式
:set ff # 查看修改后的編碼格式
[root@localhost]# chmod +x /soft/scripts/keepalived/check_nginx_pid_restart.sh
⑧由于安裝keepalived時(shí)，是自定義的安裝位置扁凛，因此需要拷貝一些文件到系統(tǒng)目錄中：
[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加入系統(tǒng)服務(wù)并設(shè)置開啟自啟動(dòng)忍疾，然后測(cè)試啟動(dòng)是否正常：
[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 # 禁止開機(jī)自動(dòng)啟動(dòng)
systemctl restart keepalived.service # 重啟keepalived
systemctl stop keepalived.service # 停止keepalived
tail -f /var/log/messages # 查看keepalived運(yùn)行時(shí)日志
⑩最后測(cè)試一下VIP是否生效，通過查看本機(jī)是否成功掛載虛擬IP：
[root@localhost]# ip addr
?
從上圖中可以明顯看見虛擬IP已經(jīng)成功掛載谨朝，但另外一臺(tái)機(jī)器192.168.12.130并不會(huì)掛載這個(gè)虛擬IP卤妒，只有當(dāng)主機(jī)下線后，作為從機(jī)的192.168.12.130才會(huì)上線叠必，接替VIP荚孵。最后測(cè)試一下外網(wǎng)是否可以正常與VIP通信，即在Windows中直接ping VIP：
?
外部通過VIP通信時(shí)纬朝，也可以正常Ping通，代表虛擬IP配置成功骄呼。推薦：Java面試題
Nginx高可用性測(cè)試
經(jīng)過上述步驟后共苛，keepalived的VIP機(jī)制已經(jīng)搭建成功，在上個(gè)階段中主要做了幾件事：
- 一蜓萄、為部署
Nginx的機(jī)器掛載了VIP隅茎。 - 二、通過
keepalived搭建了主從雙機(jī)熱備嫉沽。 - 三辟犀、通過
keepalived實(shí)現(xiàn)了Nginx宕機(jī)重啟。
由于前面沒有域名的原因绸硕，因此最初server_name配置的是當(dāng)前機(jī)器的IP堂竟，所以需稍微更改一下nginx.conf的配置：
sever{
listen 80;
# 這里從機(jī)器的本地IP改為虛擬IP
server_name 192.168.12.111;
# 如果這里配置的是域名魂毁，那么則將域名的映射配置改為虛擬IP
}
最后來實(shí)驗(yàn)一下效果：
?
在上述過程中，首先分別啟動(dòng)了keepalived出嘹、nginx服務(wù)席楚，然后通過手動(dòng)停止nginx的方式模擬了Nginx宕機(jī)情況，過了片刻后再次查詢后臺(tái)進(jìn)程税稼，我們會(huì)發(fā)現(xiàn)nginx依舊存活烦秩。
?
從這個(gè)過程中不難發(fā)現(xiàn)，keepalived已經(jīng)為我們實(shí)現(xiàn)了Nginx宕機(jī)后自動(dòng)重啟的功能郎仆，那么接著再模擬一下服務(wù)器出現(xiàn)故障時(shí)的情況：
?
在上述過程中只祠，我們通過手動(dòng)關(guān)閉keepalived服務(wù)模擬了機(jī)器斷電、硬件損壞等情況（因?yàn)闄C(jī)器斷電等情況=主機(jī)中的keepalived進(jìn)程消失）扰肌，然后再次查詢了一下本機(jī)的IP信息铆农，很明顯會(huì)看到VIP消失了！
?
現(xiàn)在再切換到另外一臺(tái)機(jī)器：192.168.12.130來看看情況：
?
此刻我們會(huì)發(fā)現(xiàn)狡耻，在主機(jī)192.168.12.129宕機(jī)后墩剖，VIP自動(dòng)從主機(jī)飄移到了從機(jī)192.168.12.130上，而此時(shí)客戶端的請(qǐng)求就最終會(huì)來到130這臺(tái)機(jī)器的Nginx上夷狰。
?
「「最終岭皂，利用Keepalived對(duì)Nginx做了主從熱備之后，無論是遇到線上宕機(jī)還是機(jī)房斷電等各類故障時(shí)沼头，都能夠確保應(yīng)用系統(tǒng)能夠?yàn)橛脩籼峁?x24小時(shí)服務(wù)爷绘。」」
十四进倍、Nginx性能優(yōu)化
到這里文章的篇幅較長了土至，最后再來聊一下關(guān)于Nginx的性能優(yōu)化，主要就簡單說說收益最高的幾個(gè)優(yōu)化項(xiàng)猾昆，在這塊就不再展開敘述了陶因，畢竟影響性能都有多方面原因?qū)е碌模热缇W(wǎng)絡(luò)垂蜗、服務(wù)器硬件楷扬、操作系統(tǒng)、后端服務(wù)贴见、程序自身烘苹、數(shù)據(jù)庫服務(wù)等。
優(yōu)化一：打開長連接配置
通常Nginx作為代理服務(wù)片部，負(fù)責(zé)分發(fā)客戶端的請(qǐng)求镣衡，那么建議開啟HTTP長連接，用戶減少握手的次數(shù)，降低服務(wù)器損耗，具體如下：
upstream xxx {
# 長連接數(shù)
keepalive 32;
# 每個(gè)長連接提供的最大請(qǐng)求數(shù)
keepalived_requests 100;
# 每個(gè)長連接沒有新的請(qǐng)求時(shí)，保持的最長時(shí)間
keepalive_timeout 60s;
}
優(yōu)化二虑灰、開啟零拷貝技術(shù)
零拷貝這個(gè)概念跛十，在大多數(shù)性能較為不錯(cuò)的中間件中都有出現(xiàn)，例如Kafka、Netty等，而Nginx中也可以配置數(shù)據(jù)零拷貝技術(shù)，如下：
sendfile on; # 開啟零拷貝機(jī)制
零拷貝讀取機(jī)制與傳統(tǒng)資源讀取機(jī)制的區(qū)別：
「傳統(tǒng)方式：」 硬件-->內(nèi)核-->用戶空間-->程序空間-->程序內(nèi)核空間-->網(wǎng)絡(luò)套接字
「零拷貝方式：」 硬件-->內(nèi)核-->程序內(nèi)核空間-->網(wǎng)絡(luò)套接字
從上述這個(gè)過程對(duì)比剖张，很輕易就能看出兩者之間的性能區(qū)別。
優(yōu)化三揩环、開啟無延遲或多包共發(fā)機(jī)制
在Nginx中有兩個(gè)較為關(guān)鍵的性能參數(shù)搔弄，即tcp_nodelay、tcp_nopush丰滑，開啟方式如下：
tcp_nodelay on;
tcp_nopush on;
TCP/IP協(xié)議中默認(rèn)是采用了Nagle算法的顾犹，即在網(wǎng)絡(luò)數(shù)據(jù)傳輸過程中，每個(gè)數(shù)據(jù)報(bào)文并不會(huì)立馬發(fā)送出去褒墨，而是會(huì)等待一段時(shí)間炫刷，將后面的幾個(gè)數(shù)據(jù)包一起組合成一個(gè)數(shù)據(jù)報(bào)文發(fā)送，但這個(gè)算法雖然提高了網(wǎng)絡(luò)吞吐量郁妈，但是實(shí)時(shí)性卻降低了浑玛。
?
因此你的項(xiàng)目屬于交互性很強(qiáng)的應(yīng)用，那么可以手動(dòng)開啟tcp_nodelay配置噩咪，讓應(yīng)用程序向內(nèi)核遞交的每個(gè)數(shù)據(jù)包都會(huì)立即發(fā)送出去顾彰。但這樣會(huì)產(chǎn)生大量的TCP報(bào)文頭，增加很大的網(wǎng)絡(luò)開銷胃碾。
?
相反涨享，有些項(xiàng)目的業(yè)務(wù)對(duì)數(shù)據(jù)的實(shí)時(shí)性要求并不高，追求的則是更高的吞吐仆百，那么則可以開啟tcp_nopush配置項(xiàng)厕隧，這個(gè)配置就類似于“塞子”的意思，首先將連接塞住儒旬，使得數(shù)據(jù)先不發(fā)出去栏账，等到拔去塞子后再發(fā)出去。設(shè)置該選項(xiàng)后栈源，內(nèi)核會(huì)盡量把小數(shù)據(jù)包拼接成一個(gè)大的數(shù)據(jù)包（一個(gè)MTU）再發(fā)送出去.
?
當(dāng)然若一定時(shí)間后（一般為200ms），內(nèi)核仍然沒有積累到一個(gè)MTU的量時(shí)竖般，也必須發(fā)送現(xiàn)有的數(shù)據(jù)甚垦，否則會(huì)一直阻塞。
?
tcp_nodelay、tcp_nopush兩個(gè)參數(shù)是“互斥”的艰亮，如果追求響應(yīng)速度的應(yīng)用推薦開啟tcp_nodelay參數(shù)闭翩，如IM、金融等類型的項(xiàng)目迄埃。如果追求吞吐量的應(yīng)用則建議開啟tcp_nopush參數(shù)疗韵，如調(diào)度系統(tǒng)、報(bào)表系統(tǒng)等侄非。
?
注意：①tcp_nodelay一般要建立在開啟了長連接模式的情況下使用蕉汪。②tcp_nopush參數(shù)是必須要開啟sendfile參數(shù)才可使用的。
?
優(yōu)化四逞怨、調(diào)整Worker工作進(jìn)程
Nginx啟動(dòng)后默認(rèn)只會(huì)開啟一個(gè)Worker工作進(jìn)程處理客戶端請(qǐng)求者疤，而我們可以根據(jù)機(jī)器的CPU核數(shù)開啟對(duì)應(yīng)數(shù)量的工作進(jìn)程，以此來提升整體的并發(fā)量支持叠赦，如下：
# 自動(dòng)根據(jù)CPU核心數(shù)調(diào)整Worker進(jìn)程數(shù)量
worker_processes auto;
?
工作進(jìn)程的數(shù)量最高開到8個(gè)就OK了驹马，8個(gè)之后就不會(huì)有再大的性能提升。
?
同時(shí)也可以稍微調(diào)整一下每個(gè)工作進(jìn)程能夠打開的文件句柄數(shù)：
# 每個(gè)Worker能打開的文件描述符除秀，最少調(diào)整至1W以上糯累，負(fù)荷較高建議2-3W
worker_rlimit_nofile 20000;
?
操作系統(tǒng)內(nèi)核（kernel）都是利用文件描述符來訪問文件，無論是打開册踩、新建泳姐、讀取、寫入文件時(shí)棍好，都需要使用文件描述符來指定待操作的文件仗岸，因此該值越大，代表一個(gè)進(jìn)程能夠操作的文件越多（但不能超出內(nèi)核限制借笙，最多建議3.8W左右為上限）扒怖。
?
優(yōu)化五、開啟CPU親和機(jī)制
對(duì)于并發(fā)編程較為熟悉的伙伴都知道业稼，因?yàn)檫M(jìn)程/線程數(shù)往往都會(huì)遠(yuǎn)超出系統(tǒng)CPU的核心數(shù)盗痒，因?yàn)椴僮飨到y(tǒng)執(zhí)行的原理本質(zhì)上是采用時(shí)間片切換機(jī)制，也就是一個(gè)CPU核心會(huì)在多個(gè)進(jìn)程之間不斷頻繁切換低散，造成很大的性能損耗俯邓。
而CPU親和機(jī)制則是指將每個(gè)Nginx的工作進(jìn)程，綁定在固定的CPU核心上熔号，從而減小CPU切換帶來的時(shí)間開銷和資源損耗稽鞭，開啟方式如下：
worker_cpu_affinity auto;
優(yōu)化六、開啟epoll模型及調(diào)整并發(fā)連接數(shù)
在最開始就提到過：Nginx引镊、Redis都是基于多路復(fù)用模型去實(shí)現(xiàn)的程序朦蕴，但最初版的多路復(fù)用模型select/poll最大只能監(jiān)聽1024個(gè)連接篮条，而epoll則屬于select/poll接口的增強(qiáng)版，因此采用該模型能夠大程度上提升單個(gè)Worker的性能吩抓，如下：
events {
# 使用epoll網(wǎng)絡(luò)模型
use epoll;
# 調(diào)整每個(gè)Worker能夠處理的連接數(shù)上限
worker_connections 10240;
}
?
這里對(duì)于select/poll/epoll模型就不展開細(xì)說了涉茧，后面的IO模型文章中會(huì)詳細(xì)剖析。
?
十五疹娶、放在最后的結(jié)尾
至此伴栓，Nginx的大部分內(nèi)容都已闡述完畢，關(guān)于最后一小節(jié)的性能優(yōu)化內(nèi)容雨饺，其實(shí)在前面就談到的動(dòng)靜分離钳垮、分配緩沖區(qū)、資源緩存沛膳、防盜鏈扔枫、資源壓縮等內(nèi)容，也都可歸納為性能優(yōu)化的方案锹安。
