反向代理
- 使用
  - 1.創建代理目標服務端：
  - 2.配置nginx反向代理目標服務端：
  - 3.測驗使用：
負載均衡
- 使用
  - 1.準備服務端
  - 2.修改nginx配置
- 3.測驗
- 負載均衡策略
- 負載均衡的額外引數
快取服務
- 代理快取
  - 語法介紹
  - 使用例子
  - 代理快取補充：
- 瀏覽器快取
  - 測驗
靜態資源訪問

前置知識章節：
1.介紹、安裝、hello world、location匹配 ?
2.??反向代理、負載均衡、快取服務、靜態資源訪問?
3.日志管理、http限流、https配置，http_rewrite模塊，第三方模塊安裝，結語，?

反向代理

??代理有正向代理和反向代理
??正向代理：
所謂的正向，就是以請求發起為角度的，此時代理的是用戶發起的請求，
用戶A無法訪問G網，但A能訪問B網，而B網能訪問G網，那么如果A先通過訪問B網，B網幫他訪問G網，回傳資料給他，那么此時B網就作為了一個代理服務器，而且是正向代理，此時A其實是知道它要訪問G網的，G網并不知道是A訪問它的，所以此時是代理了A，正向代理，

??反向代理：
相對于正向代理的代理用戶發起的請求，反向代理代理的是資源服務器的請求，
用戶A訪問B網的某個資源，但B網沒有，然后它發給C網，C網回傳給B網，B網回傳給C網，此時用戶A不知道它訪問的是C網，所以此時代理的是C網，反向代理，
場景一般是，A能訪問B，但不能訪問C，B能訪問C，我們使用B這臺機來對外提供服務，讓關于C的請求都先經過B，B再請求C來回傳結果，
反向代理有時候用在內網中，用來做請求轉發到內網，這樣一定程度的保護了內網的資源和利用上了內網的服務器，當然對于我們業務來說，服務器有可能并不是部署在內網中的，也可以用在外網服務器代理上，

??反向代理是一個非常重要的功能，可以說nginx你最常用的功能或許就是反向代理了，動靜分離、負載均衡和快取有時候你可能用不上，

使用

1.創建代理目標服務端：

我們首先需要創建一個web服務端，由于我是主攻java的，所以我這里部署一個java的web服務器，并讓他監聽8081埠，（192.168.48.131是我的虛擬機的IP，nginx和這個java web服務端都部署在這里，）
20200614012418
訪問一下這個要被代理的服務端的介面http://192.168.48.131:8081/user/list，發現呼叫成功，
20200614001834

2.配置nginx反向代理目標服務端：

??2.1 修改server:
因為此時是作為一個代理服務器，所以我們要新建一個server塊來充當代理服務器，

?有人有點疑惑，上面的例子只配了location，我們為什么要配server呢？
其實這里是從業務需求來做區分的，因為我們現在的目標是弄一個代理服務器，當然了你也可以不創建，然后把下面的location放到之前的server下即可，什么時候是必須創建的呢？當server_name不一樣的時候，但這個也是需要你根據業務來判斷的，比如你原本使用80埠接收發過來的請求，而現在使用8080埠接收發過來的請求的時候就需要一個新的server_name，
這里新建一個server其實也有介紹server_name的用法的意思，

修改server_name：server_name是當前服務端監聽的地址的意思，
server_name支持幾種語法：

基于確切的域名，域名可以一個或多個，多個使用空格隔開server_name example.com www.example.com
支持通配符的方式,通配符*只能使用在開頭或者結尾，不能使用在中間，當有多個匹配結果的時候，會選擇最長的匹配結果，server_name *.example.com www.example.*
基于正則運算式，當使用正則運算式的時候，開頭必須加上一個~server_name ~^www\d+\.example\.com$;
正則運算式支持<>來獲取一個變數到后面使用以實作二級域名的功能，這里不講，有興趣自查，
上面幾個語法的優先級是：
- 精確域名 > 通配符在前 > 通配符在后 > 正則運算式

??2.2 修改location
??proxy_pass用于設定被代理服務器的地址，可以是主機名稱（https://www.baidu.com這樣的）、IP地址(域名加埠號)的形式，
??下面的這個location的意思是，如果請求路徑開頭是/api的，那么都代理到proxy_pass指定的地址，比如訪問了/api/user/list,那么得到的結果是http://localhost:8081/user/list的結果，

server {
  listen 8080;

  location /api/ {
    proxy_pass http://localhost:8081/;
  }
}

??在lcoation都是location /api/時，proxy_pass不同，請求的資源也是不一樣的：

proxy_pass http://localhost:8081;：請求nginx主機IP:8080/api/user/list，nginx會將該請求代理轉發到http://locahost:8081/api/user/list，
proxy_pass http://localhost:8081/;：請求nginx主機IP:8080/api/user/list，nginx會將該請求代理轉發到http://locahost:8081/user/list，
proxy_pass http://localhost:8081/test;請求nginx主機IP:8080/api/user/list，nginx會將該請求代理轉發到http://locahost:8081/testuser/list，
proxy_pass http://localhost:8081/test/;請求nginx主機IP:8080/api/user/list，nginx會將該請求代理轉發到http://locahost:8081/test/user/list，

3.測驗使用：

在前面，我創建了一個8081的web服務端，而且http://nginx服務器IP:8081/user/list是有一個介面的.
20200614001834
我們試一下使用8080來代理一下這個8081這個服務端：
注意下面的這個server如果寫在default.conf的時候，是與其它server塊同級的，
20200614002940

如果我們能夠通過8080來訪問到http://192.168.48.131:8081/user/list這個介面，那么就說明了我們的反向代理成功了，此時發向8080埠的，以/api開頭的請求都會代理到8081中，

20200614003048

## 其他反向代理指令下面的其他反向代理指令我解釋了一下用途，有需要就自己去了解一下吧， * proxy_set_header：在將客戶端請求發送給后端服務器之前，更改來自客戶端的請求頭資訊， * proxy_connect_timout：配置nginx與后端服務器嘗試建立連接的超時時間， * proxy_read_timeout：定義用于從代理服務器讀取回應的超時， * proxy_send_timeout：設定用于將請求傳輸到代理服務器的超時， * proxy_redirect：用于修改后端服務器回傳的回應頭中的Location和Refresh，[proxy_redirect](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_redirect)

負載均衡

負載均衡其實也算是基于反向代理的，

上面的反向代理提到一點反向代理可以為我們的服務端進行代理，你有時候可能是多個服務端提供同一功能的，為了讓他們能夠平攤壓力，那么你可能需要負載均衡功能，

使用

1.準備服務端

??準備負載均衡用的業務服務端，我這里給的是一個java Spring Boot端的簡單代碼，我部署成多個服務端的時候，由于埠不同，訪問info介面回傳的資料也不同，這樣就可以測驗是否達到了負載均衡，
20200615152747

??部署服務端，使用--server.port來部署到不同的埠，例如java -jar a-simple-web-0.0.2-SNAPSHOT.jar --server.port=8082就把我的jar程式部署到了8082埠，

2.修改nginx配置

我們這里新建一個conf.d/loadbalance.conf，由于nginx.conf內部有一個include /etc/nginx/conf.d/*.conf;可以把conf.d下的組態檔都匯入到nginx.conf的http塊中，所以我們新建的這個conf也是可以匯入到nginx.conf中的，
20200615155759

3.測驗

訪問http://192.168.31.128:9001/user/info，看是否是輪詢的分發請求，如果回應的時候回傳了不同的埠，那么就證明了是輪詢的分發請求，

負載均衡策略

??默認輪詢負載均衡：在不指定負載均衡策略的時候，默認的策略是按順序給負載均衡服務端發送請求，并且一次順序中每個服務端處理兩次請求，比如兩個服務端，那么就是AABBAABB這樣回圈下去，如果服務端有宕機的，會從負載均衡順序中去除，等到宕機的服務端可用后，會在30S（好像是）之后加入到可用負載均衡服務端串列中，

??加權輪詢負載均衡：在輪詢的基礎上加上權重的考慮，假如服務端A的權重是1，服務端B的權重是2，那么6個請求中，服務端A會收到2個請求，服務端B會收到4個請求，
20200615155954

??ip_hash負載均衡：每個請求按ip的哈希結果分配到指定的負載服務端回應，（原理類似求余數，把服務端排序之后，根據哈希處理再處理之后得到的余數來選取服務端），這樣同一個ip回應的服務端是固定的，可以在一定程度解決服務端Session共享的問題，但這樣可能負載壓力就分配的不平均了，
語法例子：

upstream ip-hash {
  ip_hash;
  server localhost:8081;
  server localhost:8082;
}

??也可以使用第三方模塊來負載均衡，但由于我們上面沒有講過第三方模塊，引入前置知識需要占用大量篇幅，所以這里只引出一下，有需要的自查吧，

第三方模塊fair：可以基于回應時間分配請求，優先分配到回應時間短的服務端上，
第三方模塊url_hash：可以基于url的hash結果來分配請求，

負載均衡的額外引數

上面介紹了使用weight引數來實作加權輪詢負載均衡，其實還有一些其他的引數，

max_fails：允許請求失敗的次數，默認值是1，
fail_timeout：重新檢測服務的時間，當服務端請求失敗后，會在fail_timeout時間內標記成不可用，fail_timeout時間之后再次檢測是否可用，不行就再等fail_timeout時間之后再次檢測是否可用，默認是10S.
backup：預留的備份服務端，只有當其他服務端都宕機或者處于忙碌狀態時，才會分發請求給backuo標注的服務端，
down：暫時不參與負載均衡的服務端，只有其他服務端都宕機的時候，這個服務端才參與負載均衡，
max_conns：限制接收的最大的連接數，

upstream web-server {
  server localhost:8081 max_fails=1 fail_timeout=10;
  server localhost:8082;
  server localhost:8083 backup;
  server localhost:8084 down;
}

??使用ip_hash時，不能使用weight和backup，

快取服務

??在瀏覽器訪問某個網站的資源的時候，會看瀏覽器是否快取了這個資料，如果本地有這個快取資料，那么就會直接從本地中獲取了，不會再請求網路了，這是客戶端快取，nginx傳遞的回應的某些資料會影響瀏覽器是否快取資料以及快取多久，
??除了客戶端快取，還有一種代理快取nginx的快取是代理快取，因為它其實是將代理的服務端的結果快取了，代理快取使用ngx_http_proxy_module的指令來配置，
??（除了這兩種，還有（后端）服務端快取，也就是使用redis等技術進行的后端服務端快取，），

代理快取

語法介紹

??proxy_cache_path path：用來定義快取檔案路徑，只能用在http塊，
語法：

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用于定義檔案存放層級，可以有一層（1），兩層（1:2），三層（1:2:2），目錄會根據請求URL地址的哈希結果來創建（從末尾開始截取，），假如哈希結果是9cad383e7b0ee3d1d4b7099aace20b3f，那么levels=1:2代表第一層目錄為長度為一的字符f，第二層是長度為2的字符b3，
keys_zone用來定義當前這個快取存放空間的名字，10m是一個大小
max_size用來定義目錄最大的大小，
inactive用來定義不活躍的快取多久清除，
use_temp_path：快取臨時目錄，一般可以不定義，

??proxy_cache zone|off：可以用在http, server, location，zone是proxy_cache_path的keys_zone.
??proxy_cache_valid [code...] time：快取過期周期，過期之后就不回傳代理快取了， code是http狀態碼，
??proxy_cache_key string：配置快取的標識，比如說請求不一樣的話那肯定不回傳同樣的代理快取了，這就是是否回傳同一個快取的區分標識，默認值是proxy_cache_key $scheme$proxy_host$request_uri;，可以用在http, server, location，其他例子：proxy_cache_key $scheme$proxy_host$uri$args;

使用例子

下面來做一個實驗：嘗試使用nginx的代理快取作為代理的回應，

1.我們新建一個后端介面，這個后端介面能在每一次訪問的時候都在控制臺列印出一個訊息（下面是一個Spring Boot例子）：
20200622222735
2.配置反向代理：
20200622223500

3.一開始先測驗一下http://192.168.31.128/api/user/info，看每一次訪問是否都向后端發起了請求，確實是每一次都發請求的：
20200622223617

4.然后配置代理快取：
20200626003102

5.再次測驗訪問http://192.168.31.128/api/user/info是否每一次訪問都向后端發起了請求，結果應該是后端服務端只會打出一次，或者你可以嘗試關閉后端服務端，然后訪問，如果還是能夠訪問，那么應該是已經代理快取成功了，

代理快取補充：

??永久快取：上面使用proxy_cache配置的其實是臨時快取，也就是說一定時間后會自動過期，如果你的資料在很長很長時間都不會過期，那么可以考慮使用proxy_store.
??如果你想讓部分請求不要快取，可以使用proxy_no_cache [string...],string可以是變數，如果存在某個string值不為空也不為0，那么此請求不會被快取，
??快取清理：incative配置會幫我們清除過期的快取檔案，但還沒過期的不會清除，需要我們手動清除（場景是比如說你更新了大量資料，此時快取中的資料很多都錯誤了，此時需要清除所有快取，），如果你需要清除的話，那么一種方法是手動定義一個Linux腳本來清除快取；一種方法是使用模塊nginx-cache-purge，這些由于篇幅問題，不講述，

瀏覽器快取

瀏覽器是怎么判斷快取是否需要使用本地快取以及快取是否過期的呢？它通過回應頭中的expire，cache-control，Last-Modified，Etag等頭資訊來判斷的，

用于本地校驗是否過期的頭：expire，Cache-control(max-age)，如果有本地快取，那么會使用expire來判斷是否過期，不過期，直接使用本地快取，本地過期之后，再進行遠程校驗，
用于遠程校驗的Last-Modified頭資訊：用于遠程檔案修改校驗的，是一個GMT時間，例如Thu, 02 Jul 2020 01:05:03 GMT，如果校驗時間不一致，那么不使用本地快取，一致則使用本地快取，
用于遠程校驗的的Etag頭資訊：用于遠程檔案修改校驗的，是一個類時間戳的資料，例如："5efd32bf-3fa8e"，如果校驗時間不一致，那么不使用本地快取，一致則使用本地快取，Etag與Last-Modified的區別是，Etag更精確，所以會優先判斷Etag，然后再判斷Last-Modified，
相關nginx模塊：ngx_http_headers_module

?瀏覽器快取機制你可以自己了解一下：博客園-HTTP快取機制，

??Expire

語法：expires [modified] time;
- modified用于執行修改后過期，比如expires modified +24h;就代表修改后24小時內不過期，
- time：過期時間，例如有expires 24h;24天不過期，expires 30d;30天不過期，expires -1;代表永不過期

測驗

測驗之前我們先要提幾點：

瀏覽器有默認的快取策略，Etag和Last-Modified默認是自帶的，會有基于對檔案修改的快取，第一次回應200之后，第二次回應為304的時候，瀏覽器還是會發請求，但此時發請求用于測驗檔案是否過期，不過期則不會傳輸檔案
當配置了expires的時候怎么判斷它生效了呢？回應碼為200，并且不對nginx發起請求，
expires并不會在任何情況都生效，比如說F5重繪和Ctrl+F5重繪就無效，此時測驗應該使用在鏈接欄按回車發請求來測驗，expires可用于什么情況可以參考博客園-HTTP快取機制，

1.我們先在/usr/share/nginx/html下面存盤一張圖片,后面會通過訪問這種圖片，來測驗客戶端快取，

2.我們一開始先不要配置expires：

server {
    listen       80;
    server_name  127.0.0.1;
    location / {
      root /usr/share/nginx/html;
    }
}

3.多次訪問一下http://192.168.31.128/a.jpg看看nginx的訪問日志/var/log/nginx/access.log是否有添加
此時要多留意每次請求的回應碼，應當有以下幾個情況：

如果你使用F5重繪，那么第一次回應碼為200，后面都是304，第一個回應碼為200的時候用于獲取檔案，后面的304會檢查檔案是否修改，不修改則使用快取的檔案，此時每次重繪都應該發了一次請求，access.log中可以觀察到，
如果你使用在鏈接欄按回車發請求來測驗，那么回應碼應當都是200，是每一次都會去請求檔案，此時每次按回車都應該發了一次請求，access.log中可以觀察到，

4.加了expires之后看看，我們簡單的使用兩分鐘看看，

server {
    listen       80;
    server_name  127.0.0.1;
    location / {
      expires 2m;
      root /usr/share/nginx/html;
    }
}

5.多次訪問一下http://192.168.31.128/a.jpg看看nginx的訪問日志是否有添加

如果你使用F5重繪，由于expires不會在F5重繪時生效，所以效果應該和未配置之前是一樣的，
如果你使用在鏈接欄按回車發請求來測驗，那么一開始回應碼應當都是200，但不會真正的發起請求，而是使用快取中的資料，access.log中不會看到請求，（因為我上面定義快取是兩分鐘）兩分鐘之后第一次請求是304，用于校驗檔案是否修改，如果沒修改，那么后面的兩分鐘之內的回應又是不發請求的200，

靜態資源訪問

??nginx可以對外接收靜態資源訪問的請求，

??在上面的location的內容的時候，其實有講到回傳檔案資源的知識，
比如location ~* \.(gif|jpg|jpeg)$匹配任何以.gif、.jpg 或 .jpeg 結尾的請求，然后你發的請求匹配成功的時候，會使用root+location得到的路徑的資源作為回應，其實這些也就是靜態資源了，所以其實也可以通過nginx來達到靜態資源的訪問，

??在前后端分離之后，前端作為靜態資源訪問，應該部署到哪里呢？因為我們此時是不應該把前端靜態資源部署到后端服務器上的，那么這時候放到nginx服務端上也是可以的，利用nginx的靜態資源訪問作為前端的服務端，

??或者你也可以把nginx作為檔案資源訪問的服務端，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/36544.html

標籤：其他

上一篇：將群暉恢復到出廠設定

下一篇：網路通信協議

循序漸進nginx(二)：反向代理、負載均衡、快取服務、靜態資源訪問