Nginx的「遠方表哥」—Tengine

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

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

一、認識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親緣性；
•  監控系統的負載和資源佔用從而對系統進行保護；
•  顯示對運維人員更友好的出錯信息，便於定位出錯機器；
•  更強大的防攻擊（訪問速度限制）模塊；
•  更方便的命令行參數，如列出編譯的模塊列表、支持的指令等；
•  能夠根據訪問文件類型設置過時時間；

 

二、編譯安裝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.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))

網頁訪問驗證

 

四、使用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個網頁服務器

 

五、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軟件包。

 

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