nginx reverse proxy and load balancing strategy practical case

introduction

Let's first look at the trend of nginx in the ranking of web servers:

Existence is reasonable, so why use nginx? It depends on what nginx can do for us.

First of all, nginx can be used as a reverse proxy [the reverse proxy and forward proxy will not be explained here, and interested partners can Google it by themselves]; for example, I want to use the domain name of www.glmapper1.com locally to access www .taobao.com. Then we can do it through nginx at this time.

Furthermore, nginx can achieve load balancing. What is load balancing? That is to say, the application is deployed on different servers, but is entered through a unified domain name, and nginx distributes the request and distributes the request to different servers for processing, which can effectively reduce the pressure on a single server.

In the above two cases, the role of the nginx server is only as a distribution server. The real content can be placed on other servers. In this way, it can also play the role of a layer of security next door, and nginx acts as an isolation layer.

Solve cross-domain problems

Same origin: URL consists of protocol, domain name, port and path. If the protocol, domain name and port of two URLs are the same, it means they are of the same origin.

The browser's same-origin policy: The browser's same-origin policy restricts "documents" or scripts from different origins from reading or setting certain properties on the current "document". Scripts loaded from one domain are not allowed to access document properties from another domain.

Because nginx and tomcat cannot share the same port, the url is the same, the port is different, so there will be cross-domain problems.

PS：点到为止，这里本次测试没有涉及，就不妄自菲薄了！！!

Configuration file parsing

The configuration file mainly consists of four parts:

• main (global settings)
• server (host configuration)
• http (controls all core features of nginx http processing)
  • location (URL matches a specific location setting).
• upstream (load balancing server settings)

The following uses the default configuration file to illustrate the meaning of the specific configuration file attributes:

#Nginx的worker进程运行用户以及用户组
#user  nobody;

#Nginx开启的进程数
worker_processes  1;

#定义全局错误日志定义类型，[debug|info|notice|warn|crit]
#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#指定进程ID存储文件位置
#pid        logs/nginx.pid;


#事件配置
events {
    
    
    #use [ kqueue | rtsig | epoll | /dev/poll | select | poll ];
    #epoll模型是Linux内核中的高性能网络I/O模型，如果在mac上面，就用kqueue模型。
    use kqueue;
    
    #每个进程可以处理的最大连接数，理论上每台nginx服务器的最大连接数为worker_processes*worker_connections。理论值：worker_rlimit_nofile/worker_processes
    worker_connections  1024;
}

#http参数
http {
    #文件扩展名与文件类型映射表
    include       mime.types;
    #默认文件类型
    default_type  application/octet-stream;
    
    #日志相关定义
    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';
    
    #连接日志的路径，指定的日志格式放在最后。
    #access_log  logs/access.log  main;

    #开启高效传输模式
    sendfile        on;
    
    #防止网络阻塞
    #tcp_nopush     on;

    #客户端连接超时时间，单位是秒
    #keepalive_timeout  0;
    keepalive_timeout  65;

    #开启gzip压缩输出
    #gzip  on;

    #虚拟主机基本设置
    server {
        #监听的端口号
        listen       80;
        #访问域名
        server_name  localhost;
        
        #编码格式，如果网页格式与当前配置的不同的话将会被自动转码
        #charset koi8-r;

        #虚拟主机访问日志定义
        #access_log  logs/host.access.log  main;
        
        #对URL进行匹配
        location / {
            #访问路径，可相对也可绝对路径
            root   html;
            #首页文件，匹配顺序按照配置顺序匹配
            index  index.html index.htm;
        }
        
        #错误信息返回页面
        #error_page  404              /404.html;
        
        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
        
        #访问URL以.php结尾则自动转交给127.0.0.1
        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}
        
        #php脚本请求全部转发给FastCGI处理
        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #    root           html;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}

        #禁止访问.ht页面
        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        #    deny  all;
        #}
    }

    #第二个虚拟主机配置
    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    #    listen       8000;
    #    listen       somename:8080;
    #    server_name  somename  alias  another.alias;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}


    #HTTPS虚拟主机定义
    # HTTPS server
    #
    #server {
    #    listen       443 ssl;
    #    server_name  localhost;

    #    ssl_certificate      cert.pem;
    #    ssl_certificate_key  cert.key;

    #    ssl_session_cache    shared:SSL:1m;
    #    ssl_session_timeout  5m;

    #    ssl_ciphers  HIGH:!aNULL:!MD5;
    #    ssl_prefer_server_ciphers  on;

    #    location / {
    #        root   html;
    #        index  index.html index.htm;
    #    }
    #}
    include servers/*;
}

Reverse proxy instance

Suppose I now need to access www.baidu.com locally; the configuration is as follows:

server {
    #监听80端口
    listen 80;
    server_name localhost;
     # individual nginx logs for this web vhost
    access_log /tmp/access.log;
    error_log  /tmp/error.log ;

    location / {
        proxy_pass http://www.baidu.com;
    }

Validation results:

As you can see, I opened Baidu's homepage using localhost in the browser...

load balancing instance

The three most commonly used load strategies are mainly verified below. Virtual host configuration:

server {
    #监听80端口
    listen 80;
    server_name localhost;
    
    # individual nginx logs for this web vhost
    access_log /tmp/access.log;
    error_log  /tmp/error.log ;

    location / {
        #负载均衡
        #轮询 
        #proxy_pass http://polling_strategy;
        #weight权重
        #proxy_pass http://weight_strategy;
        #ip_hash
        # proxy_pass http://ip_hash_strategy;
        #fair
        # proxy_pass http://fair_strategy;
        #url_hash
        # proxy_pass http://url_hash_strategy;
        #重定向
        #rewrite ^ http://localhost:8080;
    }

polling strategy

# 1、轮询（默认）
# 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 
upstream polling_strategy { 
    server glmapper.net:8080; # 应用服务器1
    server glmapper.net:8081; # 应用服务器2
} 

Test results (distinguish current access by port number):

8081：hello
8080：hello
8081：hello
8080：hello

weight strategy

#2、指定权重
#指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 
upstream  weight_strategy { 
    server glmapper.net:8080 weight=1; # 应用服务器1
    server glmapper.net:8081 weight=9; # 应用服务器2
}

Test results: The total number of visits is 15 times. According to the above weight configuration, the proportion of visits of the two machines is 2:13; it meets expectations!

ip hash strategy

#3、IP绑定 ip_hash
#每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，
#可以解决session的问题;在不考虑引入分布式session的情况下，
#原生HttpSession只对当前servlet容器的上下文环境有效
upstream ip_hash_strategy { 
    ip_hash; 
    server glmapper.net:8080; # 应用服务器1
    server glmapper.net:8081; # 应用服务器2
} 

iphash algorithm: ip is a basic dotted decimal system, and the first three ends of ip are added as parameters to the hash function. The purpose of this is to ensure that the first three users with the same IP address will be assigned to the same backend server after hash calculation. The author's consideration is extremely desirable, so the same first three ip addresses usually mean that they are from the same local area network or adjacent area, and using the same backend service makes nginx more consistent to a certain extent.

Why do you want to explain iphash, because the pit was mined; and the pig brother used 5 machines to test this strategy test, and the 5 machines were all in the same LAN [192.168.3.X]; during the test, it was found that The 5 machines were routed to the same server each time. At first, I thought it was a configuration problem, but after investigation, this possibility was also ruled out. Finally, considering that the ip of the same network segment may be treated specially, the guess is confirmed after verification.

Other load balancing strategies

Because of the need to install third-party plug-ins here, the time is limited and will not be verified, just know!

#4、fair（第三方）
#按后端服务器的响应时间来分配请求，响应时间短的优先分配。 
upstream fair_strategy { 
    server glmapper.net:8080; # 应用服务器1
    server glmapper.net:8081; # 应用服务器2
    fair; 
} 

#5、url_hash（第三方）
#按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，
#后端服务器为缓存时比较有效。 
upstream url_hash_strategy { 
    server glmapper.net:8080; # 应用服务器1
    server glmapper.net:8081; # 应用服务器2 
    hash $request_uri; 
    hash_method crc32; 
} 

redirect rewrite

location / {
    #重定向
    #rewrite ^ http://localhost:8080;
}

Verification idea: use the localhost:80 port for local access. According to the configuration of nginx, if the redirection does not take effect, it will finally stay at the current localhost:80 path, and the address bar address in the browser will not change; if it takes effect The address bar address becomes localhost:8080;

Validated and met expectations!

Author: glmapper
Link: https://juejin.im/post/5adc425f518825670f7b6fc8
Source: Nuggets The
copyright belongs to the author. For commercial reprints, please contact the author for authorization, and for non-commercial reprints, please indicate the source.