dibo中间件

nginx的反向代理

2019-06-29  本文已影响0人  OOM_Killer

反向代理是nginx的主要功能之一,平时我们在使用Nginx的时候一般就是用其性能高效的反向代理功能。
为了线上环境中的降级和服务替换,nginx的upstream模块提供了通用的参数。
通用的参数有(不论是round-robin,还是hash)

round-robin算法

round-robin 轮询是nginx反向代理的默认使用的算法。
指定上游服务地址的upstream模块。
指令。

upstream backend1{
    server 192.168.0.2:80 weight=1 max_fails=3 fail_timeout=30s;
}
对上游服务使用keepalive长连接

通过复用tcp连接,降低nginx与上游服务器的建立、关闭连接的消耗,提高吞吐量的同时降低时延。
对上游连接设定的http头部(因为http1.0 不支持keepalive)

proxy_http_version 1.1;
proxy_set_header Connection "";

测试

如下是我nginx的配置。

upstream backend {
        keepalive 32;
        server 192.168.199.214:8081 weight=1 max_fails=2 fail_timeout=5s;
        server 192.168.199.214:8082 weight=1 max_fails=2 fail_timeout=5s;
}

server {
        listen 80;
        server_name app.prometheus.wjx;

        location / {
                proxy_http_version 1.1;
                proxy_set_header Connection "";
                proxy_pass http://backend;
        }

}

一台后端挂了后,nginx如何处理

当我将8081 的这台机器挂掉后。
从tcp层面会有RST,也就是http无法再用这条tcp连接。所以当然http请求是无法发送到8081这台机器,nginx会默认将请求发往下一台server 8082。tcp建立通了,才会有http请求过去,也就是说nginx是有高效的错误处理能力的。当配置的5s后(不一定就5s),nginx会再试8081 端的server,5s后再有请求,会重新尝试与8081建立tcp连接。


抓包得出
keepalive 对nginx和后端的影响
  1. 当keepalive配置只有1,压力测试
ab -n 10 -c 2 http://localhost/
wireshark抓包

从上图可以看出,其实只有一个keepalive连接,其他的还是使用了短连接。

  1. 当keepalive为2048时,压力测试
    只建立了两个tcp连接,分别是两个后端server的。也就是每个server一条连接,传输了所有的数据。


    wireshark抓包
  2. 不开启keepalive。压力测试
    开启keepalive的时候,nginx的timewait达到了 14000+个。而server端的timewait几乎为0。(因为开启时,server会认为这是一个长连接,不会主动关闭,而不开启的话,server会在一次请求结束后主动关闭长连接)
    不开启keepalive的时候,nginx的timewait为1000+个,而server端为900+个。
    而看看抓包情况。。。满屏的tcp syn握手包。


    wireshark握手包

least_conn 算法

这个算法是由upstream_least_conn 模块提供的。功能是从所有的上游服务中找出并发连接数最少的一个,将请求转发到它。
一般很少用到,当所有的server的连接都相同的时候,该算法会退化成round_robin算法。

upstream模块提供的变量

变量 作用
upstream_addr 上游服务的ip地址+port
upstream_connect_time 与上游服务建立连接消耗的时间
upstream_header_time 接收上游服务发回响应的头部消耗的时间
upstream_response_time 接收上游服务响应消耗的时间
upstream_bytes_received 从上游服务接收到的响应长度
upstream_response_length 从上游服务返回的响应包体的长度
upstream_status 上游服务的返回的状态码未连接上是502

proxy 模块

proxy_pass 是反向代理中最重要的一个模块。
其大体流程如图所示。


proxy_pass.png

proxy_request_buffering 和 proxy_buffering 为 off 时才会边读包体边发送

根据指令生成发往上游的请求行
接收客户端请求的包体
nginx与上游服务建立连接
nginx接收upstream的响应
上游出现失败时的容错方案

当upstream的上游服务返回失败时的处理方法。

location / {
                proxy_http_version 1.1;
                proxy_set_header Connection "";
                proxy_connect_timeout 1s;
                proxy_next_upstream off;
                proxy_pass http://backend;
        }

proxy_next_upsteam

上一篇下一篇

猜你喜欢

热点阅读