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;
        }
    }
}

Upstream域名解析模塊功能

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 tries功能

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

原文來自： https://www.linuxprobe.com/tengine-nginx-upstream.html