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

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

关于代理

什么是代理

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

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

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

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

在这里插入图片描述
反向代理：对象是服务端，为服务端服务

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

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

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

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

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

实现nginx负载均衡的组件
Nginx实现负载均衡的组件主要有两个。一个是proxy模块，还有一个是upstream模块ngx_http_upstream_module，这是nginx实现负载均衡的核心组件。它支持的代理方式包括proxy_pass、fastcgi_pass等。
在这里插入图片描述

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