Nginx的“遠方表哥”—Tengine

本文收錄在Linux運維企業架構實戰系列

　　今天想起當初研究nginx反向代理負載均衡時，nginx自身的upstream后端配置用着非常不舒服； 當時使用的淘寶基於nginx二次開發的Tengine，今天總結一下。

1、認識Tengine

1.1 介紹

• Tengine是由淘寶網發起的Web服務器項目。它在Nginx的基礎上，針對大訪問量網站的需求，添加了很多高級功能和特性。它的目的是打造一個高效、安全的Web平台。
• Tengine的性能和穩定性已經在大型的網站如淘寶網，天貓商城等得到了很好的檢驗。
• 它的最終目標是打造一個高效、穩定、安全、易用的Web平台。
• 從2011年12月開始，Tengine成為一個開源項目。
• 現在，它由Tengine團隊開發和維護。Tengine團隊的核心成員來自於淘寶、搜狗等互聯網企業。

 

1.2 功能

•  繼承Nginx-1.6.2的所有特性，兼容Nginx的配置；
•  動態模塊加載（DSO）支持。加入一個模塊不再需要重新編譯整個Tengine；
•  支持SO_REUSEPORT選項，建連性能提升為官方nginx的三倍；
•  支持SPDY v3協議，自動檢測同一端口的SPDY請求和HTTP請求；
•  流式上傳到HTTP后端服務器或FastCGI服務器，大量減少機器的I/O壓力；
•  更加強大的負載均衡能力，包括一致性hash模塊、會話保持模塊，還可以對后端的服務器進行主動健康檢查，根據服務器狀態自動上線下線，以及動態解析upstream中出現的域名；
•  輸入過濾器機制支持。通過使用這種機制Web應用防火牆的編寫更為方便；
•  支持設置proxy、memcached、fastcgi、scgi、uwsgi在后端失敗時的重試次數
•  動態腳本語言Lua支持。擴展功能非常高效簡單；
•  支持管道（pipe）和syslog（本地和遠端）形式的日志以及日志抽樣；
•  支持按指定關鍵字(域名，url等)收集Tengine運行狀態；
•  組合多個CSS、JavaScript文件的訪問請求變成一個請求；
•  自動去除空白字符和注釋從而減小頁面的體積
•  自動根據CPU數目設置進程個數和綁定CPU親緣性；
•  監控系統的負載和資源占用從而對系統進行保護；
•  顯示對運維人員更友好的出錯信息，便於定位出錯機器；
•  更強大的防攻擊（訪問速度限制）模塊；
•  更方便的命令行參數，如列出編譯的模塊列表、支持的指令等；
•  可以根據訪問文件類型設置過期時間；

 

2、編譯安裝tengine

2.1 下載指定版本

官網：http://tengine.taobao.org/download.html

[root@along app]# wget http://tengine.taobao.org/download/tengine-2.2.3.tar.gz
[root@along app]# tar -xvf tengine-2.2.3.tar.gz

　　

2.2 創建用戶，下載依賴的安裝包

[root@along app]# groupadd nginx
[root@along app]# useradd -s /sbin/nologin -g nginx -M nginx
[root@along app]# yum -y install gc gcc gcc-c++ pcre-devel zlib-devel openssl-devel

　　

2.3 編譯安裝

[root@along app]# cd tengine-2.2.3/
[root@along tengine]# ./configure --user=nginx --group=nginx --prefix=/app/tengine --with-http_stub_status_module --with-http_ssl_module --with-http_gzip_static_module
[root@along tengine]# make && make install
[root@along tengine]# chown -R nginx.nginx /app/tengine
[root@along tengine]# ll /app/tengine
total 8
drwxr-xr-x 2 nginx nginx 4096 Feb 20 14:55 conf
drwxr-xr-x 2 nginx nginx   40 Feb 20 14:50 html
drwxr-xr-x 2 nginx nginx 4096 Feb 20 14:50 include
drwxr-xr-x 2 nginx nginx    6 Feb 20 14:50 logs
drwxr-xr-x 2 nginx nginx    6 Feb 20 14:50 modules
drwxr-xr-x 2 nginx nginx   35 Feb 20 14:50 sbin

注：

•  #指定運行權限的用戶   --user=nginx
•  #指定運行的權限用戶組   --group=nginx
•  #指定安裝路徑   --prefix=/usr/local/nginx
•  #支持nginx狀態查詢 --with-http_stub_status_module
•  #開啟ssl支持   --with-http_ssl_module
•  #開啟GZIP功能   --with-http_gzip_static_module

 

3、開啟服務

3.1 配置開機啟動腳本

[root@along nginx]# vim /usr/lib/systemd/system/nginx.service
[Unit]
Description=nginx - high performance web server
Documentation=http://nginx.org/en/docs/
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/app/tengine/logs/nginx.pid
ExecStartPre=/app/tengine/sbin/nginx -t -c /app/tengine/conf/nginx.conf
ExecStart=/app/tengine/sbin/nginx -c /app/tengine/conf/nginx.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

　　

3.2 啟動服務

[root@along ~]# systemctl start nginx
[root@along ~]# ss -nutlp |grep 80
tcp    LISTEN     0      128       *:80                    *:*                   users:(("nginx",pid=4933,fd=6),("nginx",pid=4932,fd=6))

網頁訪問驗證

 

4、使用tengine的負載均衡功能

　　因為tengine的其他功能和nginx配置差不多，就不在演示了；主要演示，我認為較為方便的反向代理配置。

4.1 配置反向代理

tengine配置反向代理格式和haproxy很相似；

后端兩台服務器事先自己准備好網頁服務（nginx/httpd等都可以）

[root@along tengine]# cd /app/tengine/conf/
[root@along conf]# vim nginx.conf
http {
... ...
#配置后端代理集群，默認是輪詢算法
    upstream srv {
        server 192.168.10.101:80;
        server 192.168.10.106:80;
        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_http_send "HEAD / HTTP/1.0\r\n\r\n";
        check_http_expect_alive http_2xx http_3xx;
    }
... ...
#在server端location反向代理
    server {
        location / {
            proxy_pass http://srv;
        }
    }
... ...
}

　　

4.2 重啟服務器，驗證

（1）驗證配置是否有誤

[root@along tengine]# ./sbin/nginx -t
nginx: the configuration file /app/tengine/conf/nginx.conf syntax is ok
nginx: configuration file /app/tengine/conf/nginx.conf test is successful

　　

（2）重啟服務器

[root@along tengine]# systemctl restart nginx

　　

（3）網頁訪問驗證

因為默認是輪詢算法，所以刷新頁面，就會輪詢調度到后台2個網頁服務器

 

5、nginx upstream模塊調度算法詳解

5.1 輪詢

　　輪詢是upstream的默認分配方式，即每個請求按照時間順序輪流分配到不同的后端服務器，如果某個后端服務器down掉后，能自動剔除。

upstream srv {
        server 192.168.10.101:80;
        server 192.168.10.106:80;
}

　　

5.2 weight加權輪詢

　　加權輪詢，輪詢的加強版，即可以指定輪詢比率，weight和訪問幾率成正比，主要應用於后端服務器異質的場景下。

upstream srv {
        server 192.168.10.101:80 weight=1;
        server 192.168.10.106:80 weight=2;
}

　　

5.3 ip_hash 

　　每個請求按照訪問ip（即Nginx的前置服務器或者客戶端IP）的hash結果分配，這樣每個訪客會固定訪問一個后端服務器，可以解決session一致問題。

 

upstream srv {
        ip_hash;
        server 192.168.10.101:80;
        server 192.168.10.106:80;
}

注意：

•  當負載調度算法為ip_hash時，后端服務器在負載均衡調度中的狀態不能是weight和backup。
•  導致負載不均衡。

 

5.4 fair 

　　fair顧名思義，公平地按照后端服務器的響應時間（rt）來分配請求，響應時間短即rt小的后端服務器優先分配請求。如果需要使用這種調度算法，必須下載Nginx的upstr_fair模塊。

upstream srv {
        fair;
        server 192.168.10.101:80;
        server 192.168.10.106:80;
}

　　

5.5 url_hash（目前用consistent_hash替代url_hash）

　　與ip_hash類似，但是按照訪問url的hash結果來分配請求，使得每個url定向到同一個后端服務器，主要應用於后端服務器為緩存時的場景下。

upstream srv {
        server 192.168.10.101:80;
        server 192.168.10.106:80;
        hash $request_uri;
        hash_method crc32;
}

•  其中，hash_method為使用的hash算法，需要注意的是：此時，server語句中不能加weight等參數。
•  提示：url_hash用途cache服務業務，memcached，squid，varnish。特點：每個rs都是不同的。
•  按訪問url的hash結果來分配請求，讓每個url定向到同一個后端服務器，后端服務器為緩存服務器時效果顯著。在upstream中加入hash語句, server語句中不能寫入weight等其他的參數，hash_ method是使用的hash算法。。
•  url_ hash.按訪問ur1的hash結果來分配請求，使每個url定向到同-一個后端服務器，可以進一步提高后端緩存服務器的效率命中率。Nginx 本身是不支持ur1_ hash的，如果需要使用這種調度算法，必須安裝Nginx的hash軟件包。

 

6、upstream段用法介紹

（1）參數說明

•  server：關鍵字，必選。
•  address：主機名、域名、ip或unix socket，也可以指定端口號，必選。
•  parameters：可選參數，可選參數如下：
  •  down：表示當前的server暫時不參與負載均衡。
  •  backup：預留的備份機器。當其他所有的非backup機器出現故障或者忙的時候，才會請求backup機器，因此這台機器的壓力最輕。
  •  weight：默認為1.weight越大，負載的權重就越大。
  •  max_fails：允許請求失敗的次數，默認為1。當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤。
  •  fail_timeout：在經歷了max_fails次失敗后，暫停服務的時間。max_fails可以和fail_timeout一起使用。
  •  max_fails和fail_timeout一般會關聯使用：如果某台server在fail_timeout時間內出現了max_fails次連接失敗，那么Nginx會認為其已經掛掉了，從而在fail_timeout時間內不再去請求它，fail_timeout默認是10s，max_fails默認是1，即默認情況是只要發生錯誤就認為服務器掛掉了，如果將max_fails設置為0，則表示取消這項檢查。

 

（2）舉例說明如下：

upstream backend {
	server    backend1.example.com weight=5;
	server    127.0.0.1:8080 max_fails=3 fail_timeout=30s;
	server    unix:/tmp/backend3;           
}