Tengine如何新增nginx upstream模塊

這篇文章主要介紹了Tengine如何新增nginx upstream模塊，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

后端長連接超時功能

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

感謝你能夠認真閱讀完這篇文章，希望小編分享的“Tengine如何新增nginx upstream模塊”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!