Tengine新增nginx upstream模組的使用

Tengine是淘寶在Nginx基礎之上的二次開發版，Tengine完全相容Nginx，因此可以參照Nginx的方式來配置Tengine。但Tengine提供了很多比較實用的特性，以及效能的優化。比如針對upstream模組，Tengine再次開發的一些小模組，下面說明一下。

ngx_http_upstream_keepalive_module模組增加nginx後端長連線的超時支援:

upstream backend {
    server 127.0.0.1:8080;
    keepalive 32;
    keepalive_timeout 30s;      #設定後端連線的最大idle時間為30s
}

1）keepalive_timeout

Syntax: keepalive_timeout time
Default: -
Context: upstream

該指令設定後端長連線的最大空閒超時時間，引數的時間單位可以是s（秒），ms（毫秒），m（分鐘）。預設時間單位是秒。

ngx_http_upstream_check_module，該模組可以為Tengine提供主動式後端伺服器健康檢查的功能。該模組在Tengine-1.4.0版本以前沒有預設開啟，它可以在配置編譯選項的時候開啟：./configure –with-http_upstream_check_module。

1）check

Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port]
Default: interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp
Context: upstream
該指令可以開啟後端伺服器的健康檢查功能，指令後面的引數意義是：
interval：向後端傳送的健康檢查包的間隔。
fall(fall_count)：如果連續失敗次數達到fall_count，伺服器就被認為是down。
rise(rise_count)：如果連續成功次數達到rise_count，伺服器就被認為是up。
timeout：後端健康請求的超時時間。
default_down：設定初始時伺服器的狀態，如果是true，就說明預設是down的，如果是false，就是up的。預設值是true，也就是一開始伺服器認為是不可用，要等健康檢查包達到一定成功次數以後才會被認為是健康的。
type：健康檢查包的型別，現在支援以下多種型別
tcp：簡單的tcp連線，如果連線成功，就說明後端正常。
ssl_hello：傳送一個初始的SSL hello包並接受伺服器的SSL hello包。
http：傳送HTTP請求，通過後端的回覆包的狀態來判斷後端是否存活。
mysql：向mysql伺服器連線，通過接收伺服器的greeting包來判斷後端是否存活。
ajp：向後端傳送AJP協議的Cping包，通過接收Cpong包來判斷後端是否存活。
port：指定後端伺服器的檢查埠。你可以指定不同於真實服務的後端伺服器的埠，比如後端提供的是443埠的應用，你可以去檢查80埠的狀態來判斷後端健康狀況。預設是0，表示跟後端server提供真實服務的埠一樣。該選項出現於Tengine-1.4.0。

2）check_keepalive_requests

Syntax: check_keepalive_requests request_num
Default: 1
Context: upstream

該指令可以配置一個連線傳送的請求數，其預設值為1，表示Tengine完成1次請求後即關閉連線。

3）check_http_send

Syntax: check_http_send http_packet
Default: "GET / HTTP/1.0"
Context: upstream

該指令可以配置http健康檢查包傳送的請求內容。為了減少傳輸資料量，推薦採用”HEAD”方法。當採用長連線進行健康檢查時，需在該指令中新增keep-alive請求頭，如：”HEAD / HTTP/1.1\r\nConnection: keep-alive\r\n\r\n”。 同時，在採用”GET”方法的情況下，請求uri的size不宜過大，確保可以在1個interval內傳輸完成，否則會被健康檢查模組視為後端伺服器或網路異常。

4）check_http_expect_alive

Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ]
Default: http_2xx | http_3xx
Context: upstream

該指令指定HTTP回覆的成功狀態，預設認為2XX和3XX的狀態是健康的。

5）check_shm_size

Syntax: check_shm_size size
Default: 1M
Context: http

所有的後端伺服器健康檢查狀態都存於共享記憶體中，該指令可以設定共享記憶體的大小。預設是1M，如果你有1千臺以上的伺服器並在配置的時候出現了錯誤，就可能需要擴大該記憶體的大小。

6）check_status

Syntax: check_status [html|csv|json]
Default: check_status html
Context: location

顯示伺服器的健康狀態頁面。該指令需要在http塊中配置。在Tengine-1.4.0以後，你可以配置顯示頁面的格式。支援的格式有: html、csv、 json。預設型別是html。你也可以通過請求的引數來指定格式，假設‘/status’是你狀態頁面的URL， format引數改變頁面的格式，比如：

/status?format=html
/status?format=csv
/status?format=json

同時你也可以通過status引數來獲取相同伺服器狀態的列表，比如：

/status?format=html&status=down
/status?format=csv&status=up

下面是一個HTML狀態頁面的例子（server number是後端伺服器的數量，generation是Nginx reload的次數。Index是伺服器的索引，Upstream是在配置中upstream的名稱，Name是伺服器IP，Status是伺服器的狀態，Rise是伺服器連續檢查成功的次數，Fall是連續檢查失敗的次數，Check type是檢查的方式，Check port是後端專門為健康檢查設定的埠）：

下面是csv格式頁面的例子：

0,backend,106.187.48.116:80,up,46,0,http,80

下面是json格式頁面的例子：

{"servers": {
  "total": 1,
  "generation": 3,
  "server": [
   {"index": 0, "upstream": "backend", "name": "106.187.48.116:80", "status": "up", "rise": 58, "fall": 0, "type": "http", "port": 80}
  ]
 }}

增強版upstream使用示例：

http {
    upstream cluster1 {
        # simple round-robin
        server 192.168.0.1:80;
        server 192.168.0.2:80;
 
        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_http_send "HEAD / HTTP/1.0";
        check_http_expect_alive http_2xx http_3xx;
    }
 
    upstream cluster2 {
        # simple round-robin
        server 192.168.0.3:80;
        server 192.168.0.4:80;
 
        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_keepalive_requests 100;
        check_http_send "HEAD / HTTP/1.1 Connection: keep-alive";
        check_http_expect_alive http_2xx http_3xx;
    }
 
    server {
        listen 80;
 
        location /1 {
            proxy_pass http://cluster1;
        }
 
        location /2 {
            proxy_pass http://cluster2;
        }
 
        location /status {
            check_status;
            access_log   off;
            allow SOME.IP.ADD.RESS;
            deny all;
        }
    }
}

ngx_http_upstream_dynamic_module，此模組提供了在執行時動態解析upstream中server域名的功能，用的不多。
dynamic_resolve
Syntax: dynamic_resolve [fallback=stale|next|shutdown] [fail_timeout=time]
Default: -
Context: upstream.

指定在某個upstream中啟用動態域名解析功能，fallback引數指定了當域名無法解析時採取的動作：

stale, 使用tengine啟動的時候獲取的舊地址
next, 選擇upstream中的下一個server
shutdown, 結束當前請求
fail_timeout引數指定了將DNS服務當做無法使用的時間，也就是當某次DNS請求失敗後，假定後續多長的時間內DNS服務依然不可用，以減少對無效DNS的查詢。

upstream backend {
    dynamic_resolve fallback=stale fail_timeout=30s;
    server a.com;
    server b.com;
}

limit upstream retries，限制每個請求對後端伺服器訪問的最大嘗試次數，支援proxy、memcached、fastcgi、scgi和uwsgi模組。 可以使用下面的指令開啟訪問次數進行限制。

# 限制fastcgi代理的後端嘗試次數
fastcgi_upstream_tries num
 
# 限制proxy代理的後端嘗試次數
proxy_upstream_tries num
 
# 限制memcached代理的後端嘗試次數
memcached_upstream_tries num
 
# 限制scgi代理的後端嘗試次數
scgi_upstream_tries num
 
# 限制uwsgi代理的後端嘗試次數
uwsgi_upstream_tries num

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31559985/viewspace-2375508/，如需轉載，請註明出處，否則將追究法律責任。