upstream模塊
  • 對於upstream模塊而説，它默認已經被編譯進Nginx中了
  • 想禁用的話，通過 `–without-http_upstream_model 這樣一個參數來明確的禁用

1 ）基本用法

1.1 upstream

  • 語法： upstream name { … }
  • 默認值：無
  • 上下文：http
  • 示例
upstream {
	......
	......
}

1.2 server

  • 和 upstream 段平行，用於指定我們後端的一個具體應用服務的一個具體地址
  • 語法：server address [parameters];
  • address 是ip地址+端口，後面可跟一些url
  • 默認值：無
  • 上下文：upstream
  • parameters 可選值
    可選參數
    含義
    weight=number
    權重值，默認為1
    max_conns=number
    上游服務器的最大併發連接數
    fail_timeout=time
    服務器不可用的判定時間
    max_fails=number
    服務器不可用的檢查次數
    backup
    備份服務器，僅當其他服務器都不可用時
    down
    標記服務器長期不可用，離線維護
  • weight 權重值越大，代表這台服務器的處理能力更強，被分配的請求會更多
  • max_conns 定義之後，超出直接拒絕
  • fail_timeout 會啓動一個計數器，結合 max_fails
  • max_fails 最大失敗次數，結合 fail_timeout
  • 定義 fail_timeout 為 10s, max_fails 為 3
  • 10s 內如果出現3次沒有返回結果，則判定當前服務器不可用
  • backup 當所有其他服務器掛掉不可用了，才會將請求調度到 backup 服務器
  • down 永遠不會被調度

1.3 keepalive

  • 語法：keepalive connections;
  • 這個 connections 不宜過大
  • 默認值：無
  • 上下文：upstream
  • 示例：keepalive 16;
  • 是限制每一個worker子進程與上游服務器，建立空閒長連接的一個最大數量
  • 可以通過keepalive這樣一個參數來啓用Nginx與上游服務器之間的一個長連接功能
  • 啓用長連接的情形下的話，有很多的併發請求都調度給某一台上游服務器，上游服務器處理完之後，結果都返回給Nginx了
  • 如果開啓長連接功能，這些連接可能並不會關閉, 存在這樣一種情形，某一個時刻併發請求特別多，超過了五千個併發連接
  • 上游服務器處理完之後，把這五千個請求全部返回給Nginx，但是在這時候沒有任何請求了，那這五千千個連接都在這空閒着嗎？
  • 所以會很浪費的，因為你又開啓了keepalive長連接功能，所以同時這五千個鏈接都會在這保持長連接
  • 所以説我們的keepalive後面跟一個connection的這樣一個參數，就定義了Nginx和後端的上游服務器可以開啓的長連接的一個空閒長連接的最大數量
  • 示例中：keepalive 16; 也就是説在一個時刻內，Nginx到上游服務器的空閒的長連接是16個，所謂空閒的長連接就是這個長連接TCP連接接建立着，但是上面沒有請求去發送，但這就是空閒的長連接
  • 這個也是有利於我們去更好的去複用這個系統資源，避免某些極端情況的發生的

1.4 keepalive_requests

  • 語法：keepalive_requests number;
  • 默認值：keepalive_requests 100;
  • 上下文：upstream
  • 單個長連接可以處理的最多的HTTP請求個數
  • 建立一個長連接之後, 不可能無限制制的允許請求的發生, 也不能無限限制的讓這個長連接一直存在
  • 假如説你這個長接接不不停的發送HTTP請求，最多發送100個HTTP請求之後，就要強制關閉
  • 如果客户端還有請求發送過來，把這個長連接關閉掉之後，再次啓動一個新的連接給你處理請求

1.5 keepalive_timeout

  • 語法：keepalive_timeout time;
  • 默認值：keepalive_timeout 60s
  • 上下文：upstream
  • 空閒長連接的最長保持時間
  • 當現在系統比較空閒的時候，仍然保持了很多長連接
  • 這個時候，每一個長連接最長保持多長時間，也是有一定的限制的
  • 長期沒有請求在這個長鏈接上發送的話，可以通過keepalive_timeout 後面定義這樣一個時間值，比如説60秒內
  • 這個長連接上60秒內沒有任何請求發送的話，那這個長連接會被自動銷燬

1.6 queue (商業版，開源沒有)

  • 語法：queue number [timeout=time]
  • 默認值：無
  • 上下文：upstream
  • 示例：queue 100 timeout=30s;
  • 這裏的 100 是隊列長度
  • 所有上游服務器不可用時，請求會被放到隊列中等待

2 ）配置示例

upstream back_end {
	server 127.0.0.1:8080 weight=3 max_conns=1000 fail_timeout=10s
max_fails=2;
	keepalive 32；
	keepalive_requests 50；
	keepalive_timeout 30s;
}
應用程序服務器的配置示例
  • 總配置目錄：/etc/nginx/nginx.conf
include /etc/ngin/conf.d/*.conf;
  • vim /etc/nginx/conf.d/app_server.conf 單個可用的配置
server {
	listen 8080;
	server_name localhost;
	location /proxy/ {
		root /opt/nginx/html/app;
		index proxy.html;
	}
}
  • $ mkdir /opt/nginx/html/app/proxy -p && cd /opt/nginx/html/app/proxy
  • 寫一個腳本，產生隨機數，模擬動態服務 $ vim create_random_number.sh
#!/bin/bash
#

DIR=/opt/nginx/html/app/proxy
FILE=proxy.html

while true;do
		echo "Application Server,This time create number: $RANDOM" > $DIR/$FILE
		sleep  1
done
  • 運行腳本 $ nohup sh create_random_number.sh &
  • 多次查看，發現文件有變化 $ cat proxy.html 基於這種形式來模擬動態服務
  • 多次通過 $ curl localhost:8080/proxy/ 可查看對應的變化
反向代理配置示例

1 ）proxy_pass 指令

  • 由http_proxy模塊提供(ngx_http_proxy_module)
  • 默認已被編譯進nginx
  • 禁用須通過 --without-http_proxy_module
  • 語法：proxy_pass URL;
  • URL 的參數原則
  • URL 必須以 http(s) 開頭
  • URL 可以攜帶變量
  • URL 中是否帶uri, 回直接影響發往上游請求的URL
  • 默認值：無
  • 上下文：location、if、limit_except
  • 示例一：proxy_pass http:/127.0.0.1:8080
  • 示例二：proxy_pass http:/127.0.0.1:8090/proxy

2 ）配置示例 proxy.conf

upstream back_end {
	server                  192.168.184.20:8080 weight=2 max_conns=1000 fail_timeout=10s max_fails=3;
	keepalive               32；
	keepalive_requests      80；
	keepalive_timeout       20s;
}

server {
	listen              80；
	server_name         proxy.baidu.com;
	location /proxy {
		proxy_pass      http://back_end/proxy;
	}
}
  • 本機 proxy.baidu.com 配置好 hosts
  • 訪問：proxy.baidu.com/proxy 同樣可以看到變化的效果
  • 這裏會尋找上游服務器中的 proxy.html，之前上游服務器的腳本仍舊還在運行
  • 這裏仍然會動態改變 proxy.html 的內容

3 ）proxy 常見誤區

兩種常見用法

  • proxy_pass http://192.168.184.20:8080
  • proxy_pass http://192.168.184.20:8080/
  • 帶 / 和 不帶 / 用法區別
  • A. 不帶/意味着Nginx不會修改用户URL,而是直接透傳給上游的應用服務器
  • 配置示例
location /bbs/ {
	proxy_pass http://127.0.0.1:8080
}
  • 用户請求url: /bbs/abc/test.html
  • 請求到達Nginx的url: /bbs/abc/test.html
  • 請求到達上游服務器的url: /bbs/abc/test.html
  • B. 帶/意味着Nginx會修改用户url,修改方法：將location後的URL從用户URL中刪除
  • 配置示例
location /bbs/ {
	proxy_pass http://127.0.0.1:8080/
}
  • 用户請求url: /bbs/abc/test.html
  • 請求到達Nginx的url: /bbs/abc/test.html
  • 請求到達上游應用服務器的url: /abc/test.html
  • 代理到上游服務器的URL結尾是否有必要加 /
  • 這個根據上述示例來選擇場景應用