Nginx反向代理与负载均衡

一、网关、代理与反向代理的关系

众所周知路由器可以连接不同网段的局域网，不同网段的局域网想要进行数据的传递需要经过相应的网关。由于每一个发出去的请求或回来的响应都要经过网关我们便可以在网关处进行一下流量的管理。nginx恰恰可以做到这一点。nginx服务器可以正向代理用户也可以反向代理业务服务器。代理谁谁就是他要保护的对象。nginx在此过程中往往做的就是请求转发的活，并不会真正的处理实际的业务。网关处的带宽往往决定了集群的带宽，所以在进行数据响应时往往会做一些操作。

lvs是一个专业的负载均衡器。

• 常见的反向代理模式
• 隧道式模型：业务服务器收到的请求与响应都要经过Nginx服务器（能力受带宽限制）。
• DS模型：业务服务器收到的请求走Nginx服务器，但是响应直接由业务处理服务器进行响应。

二、反向代理在系统架构中的应用场景

用户使用电脑向目标主机发送请求，请求会先经过路由器，由路由器转发给DNS等服务器进行域名解析，然后数据到达目标服务器所处的机房网关，在机房网关内如果合法能够通过防火墙，进入Nginx服务器使用Nginx服务器进行负载均衡打到相应的业务服务器上即可，业务服务器通常会有一个专门进行身份校验。

三、Nginx反向代理配置

1.不重定向配置

这种代理模式不会将路由重定向，而是直接对需要操作的动作进行转发（响应状态码是200，源主机是Nginx服务器主机，可以很好的将所代理的主机隐藏起来）

配置文件如下：

server {
    listen       80;
    server_name  *.aiecp.com;
    
    location / {
    	# 核心代码
    	proxy_pass http://www.atguigu.com/;
    }
    
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
    	root   html;
    }

}

2.重定向配置

这种代理模式客户端会先向代理服务器发送一个请求，然后代理服务器将路由重定向到指定主机。

配置文件如下：

server {
    listen       80;
    server_name  *.aiecp.com;
    
    location / {
    	# 核心代码
    	proxy_pass http://atguigu.com/;
    }
    
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
    	root   html;
    }

}

四、基于反向代理的负载均衡器（不支持https）

由于我的电脑与硬盘太菜，就没有像张一明老师那样开三台虚拟机了，我是直接在宿主机上跑了三个项目分别占用宿主机的8080,8081,8082端口如下：


由于在内网上进行的实验，内网路由器又在我手里于是就将宿主机的防火墙关掉了。

以下是在本地跑的三个项目，都可以访问到。

在进行配置的时候一直说我请求头非法于是替换了策略（后面研究到修改请求头的时候再进行深究）
将三个项目改成了两个，这两个都是Golang写的主要是为了方便观察。

被代理的第一个主机

被代理的第二个主机：

这里实验的过程中，可以发现虽然设置了权重之类的属性，但是依旧没哟办法做到百分百轮询或者按比例访问，nginx会根据两个端口的响应速率进行转发
在负载均衡的两个端口内，博客明显响应的更慢一些，所以在询问的时候更偏向于转发到8081端口。这时候怎么观察到负载均衡的效果呢？看下面的图片：

之后就可以看到负载均衡的效果啦。

五、负载均衡介绍

1.负载均衡策略

• weight：权重

• down : 当前server暂不参与负载均衡

• backup : 预留的备份服务器； 其它所有的非backup机器down或者忙的时候，请求backup机器。

• max_fails : 请求失败次数限制

• fail_timeout : 经过max_fails后服务暂停时间

• max_conns : 限制最大的连接数

2.负载均衡调度算法

• 轮询:默认算法按时间顺序逐一分配到不同的后端服务器;

  • RR（默认轮询）每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉能自动剔除

  • upstream test {
    server 192.168.31.253:8080;
    server 192.168.31.253;
    }

    server {
    listen 81;
    server_name localhost;
    client_max_body_size 1024M;
    location / {
    proxy_pass http://test;
    proxy_set_header Host $host:$server_port;
    }
    }

• 加权轮询:Weight值越大，分配到访问几率越高（但不是百分百按比例）;

  • 权重指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况
  • upstream test {
    server 192.168.31.253:8081 weight=1;
    server 192.168.31.253:8080 weight=9;
    }

• ip_hash:为每一个请求访问的IP的hash结果分配，可以将来自一个IP的固定访问一个后端服务器;

  • ip_hash 会话粘连, 上面的2种方式都有一个问题，那就是下一个请求来的时候请求可能分发到另外一个服务器，当我们的程序不是无状态的时候（采用了session保存数据），这时候就有一个很大的很问题了，比如把登录信息保存到了session中，那么跳转到另外一台服务器的时候就需要重新登录了，所以很多时候我们需要一个客户只访问一个服务器，那么就需要用iphash了，iphash的每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

  • 会话粘粘可以理解为用户持续访问一个后端机器

    upstream test {
    ip_hash;
    server 192.168.31.253:8080;
    server 192.168.31.253:8081;
    }

• url_hash:需要安装模块安装访问的URL的hash结果来分配，这样每个URL定向到同一个后端服务器

  • url_hash（第三方）:按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

    在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法

  • upstream backend {
    hash $request_uri;
    hash_method crc32;
    server 192.168.31.253:8080;
    server 192.168.31.253:8081;
    }

• least_conn:按照某台机器最少连接数的进行分配访问;

  • 将请求分配到连接数最少的服务上
  • upstream dalaoyang-server {
    least_conn;
    server 192.168.31.253:8080;
    server 192.168.31.253:8081;
    }

• fair 按后端服务器 的响应时间来分配请求，响应时间短的优先分配

  • upstream backend {
    fair;
    server 192.168.31.253:8080;
    server 192.168.31.253:8081;
    }

---

转载：https://blog.csdn.net/apple_51931783/article/details/127800792