Nginx反向代理与负载均衡与504错误

╰+攻爆jí腚メ 2024-02-18 11:41 7阅读 0赞

Nginx反向代理与负载均衡概念简介

关于代理

什么是代理

类似中介  
![在这里插入图片描述][e38a265120754f1a8f3327fe9e51f14c.png]  
在没有代理模式的情况下，客户端和Nginx服务端，都是客户端直接请求服务端，服务端直接响应客户端。

那么在互联网请求里面，客户端往往无法直接向服务端发起请求，那么就需要用到代理服务，来实现客户端和服务通信，如下图所示。  
![在这里插入图片描述][d9b1ec0f5b354b0aa0743c4a616c50cc.png]  
按照应用场景模式进行总结，代理可分为正向代理、反向代理，区别在于两者服务对象不同。

正向代理：代理的对象是客户端，为客户端服务

例如：VPN翻墙：VPN代理你的电脑去访问国外的网站

![在这里插入图片描述][8b9fd9e33c354ea7992560592f1259c2.png]  
反向代理：对象是服务端，为服务端服务

一般出现在公司架构中（代理服务端）  
![在这里插入图片描述][7d5a4cc7f7324d2792234af5cb9e2fb0.png]  
反向代理与负载均衡概念简介

严格来说，Nginx 仅仅是作为 Nginx Proxy 反向代理使用的，因为这个反向代理功能表现的效果是负载均衡集群的效果，所以称之为 Nginx 负载均衡。那么，反向代理和负载均衡有什么区别呢？

普通负载均衡软件，如大名鼎鼎的 LVS，其实现的功能只是对请求数据包的转发（也可能会改写数据包）、传递，其中DR模式明显的特征是：从负载均衡下面的节点服务器来看，接收到的请求还是来自访问负载均衡器的客户端的真实用户。

而反向代理就不一样了，反向代理按收访问用户的请求后，会代理用户重新向代理下的节点服务器发起请求，最后把数据返回给客户端用户，在节点服务器看来，访问节点服务器的客户端用户就是反向代理服务器了，而非真实的网站访问用户。

一言以蔽之，LVS 等的负载均衡是转发用户请求的数据包，而 Nginx 反向代理是接收用户的请求然后重新发起请求去请求其后面的节点。

实现nginx负载均衡的组件  
Nginx实现负载均衡的组件主要有两个。一个是proxy模块，还有一个是upstream模块ngx\_http\_upstream\_module，这是nginx实现负载均衡的核心组件。它支持的代理方式包括proxy\_pass、fastcgi\_pass等。  
![在这里插入图片描述][847b759c0fb94b9e87bded8b8a309475.png]

504大部分是读取超时导致的，那么有什么办法能缓解呢？可以在调用端或proxy上进行重试，比如第一次读取超时是10s，如果失败重试一次，超时时间配置为30s。  
ngx\_http\_upstream\_module 模块可以针对不同的upstream做很多的策略，包括负载均衡、重试、权重等各种策略，如果upstream是自己能控制的服务，那么使用该模块是非常合适的，但在本文的场景中，proxy的后端是一个第三方服务，那么是否可以配置呢？做了个尝试：

upstream up {
        
       server   api.test.com:443 ;
    }
    
    location / {
        
       proxy_pass https://up;
       # proxy_pass https://api.test.com;
       proxy_ssl_server_name on;
       proxy_read_timeout 160;
       proxy_connect_timeout 5;
       proxy_buffering off;
    }

但不管怎么测试，总是返回502错误，如果把upstream换成baidu.com则没问题，所以百思不得其解，那还有其他方法吗？

下面这种方法是利用proxy\_intercept\_errors和error\_page指令：

location / {
        
    
       proxy_set_header Host api.test.com ;
       proxy_ssl_server_name on;
       proxy_read_timeout 10;
       proxy_connect_timeout 5;
       proxy_buffering off;
       proxy_redirect  off;
       proxy_pass https://api.test.com;
       proxy_intercept_errors on;
       error_page 504 = @retry;
    }
    
    location @retry {
        
       proxy_ssl_server_name on;
       proxy_read_timeout 30;
       proxy_connect_timeout 5;
       proxy_buffering off;
       proxy_redirect off;
       proxy_pass https://api.test.com;
       proxy_next_upstream off;
    }

proxy\_intercept\_errors 定义：

Determines whether proxied responses with codes greater than or equal to 300 should be passed to a client or be intercepted and redirected to nginx for processing with the error_page directive.

大概的意思就是对于300以上的http错误，如果proxy\_intercept\_errors指令打开，会拦截错误交给error\_page指令。

那error\_page指令的定义呢：

Defines the URI that will be shown for the specified errors. A uri value can contain variables.

可以配置不同的http错误码对应的url地址，在这个例子中就是跳转到@retry location，从而进行一次重试。

测试了下，确实能成功，504 重试成功的例子：

[08/Nov/2023:18:01:17 +0800] 121.40.211.190 - - - _ 47.252.35.171 to: 104.1.7.192:443 : 104.1.6.192:443: POST /v1/ HTTP/1.1 200 upstream_response_time 10.015 : 10.037 msec 1699437677.553 request_time 20.051

仔细观察，日志中保存了每一次请求ip地址，共两个，总的消耗时间是20.051秒。

504重试失败的例子：

[07/Nov/2023:16:08:11 +0800] 21.40.211.190 - - - _ 47.252.35.171 to: 104.1.7.192:443 : 104.1.6.192:443: POST / HTTP/1.1 504 upstream_response_time 10.006 : 30.006 msec 1699344491.239 request_time 40.013

[e38a265120754f1a8f3327fe9e51f14c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/a62964b1ed2941919a77bd44c919b32e.png
[d9b1ec0f5b354b0aa0743c4a616c50cc.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/a3a32154a695419599f9feea7fd5f07d.png
[8b9fd9e33c354ea7992560592f1259c2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/0264a2e6dea64a45adb66bd1e184c5bd.png
[7d5a4cc7f7324d2792234af5cb9e2fb0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/985130d2b3e045778b9b47bf23cf93c1.png
[847b759c0fb94b9e87bded8b8a309475.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/99180ca037854c91b27456d6e2024914.png