前言

利用 proxy_ pass可以将请求代理到后端服务器，前一篇博客中的的配置示例都指向同一台服务器，如果需要指向多台服务器就要用到 ngx_ http_ upstream_ module。它为反向代理提供了负载均衡及故障转移等重要功能。

代理多台服务器

先来看一个简单的版本：

指令： upstream
语法： upstream name {…}
环境： http含义：定义一组 HTTP服务器，这些服务器可以监听不同的端口，以及 TCP和 UNIX套接字。在同一个 upstream中可以混合使用不同的端口、 TCP和 UNIX套接字。

指令： server
语法： server address [parameters];
环境： upstream
含义：配置后端服务器，参数可以是不同的 IP地址、端口号，甚至域名。 

server指令拥有丰富的参数，其参数说明见下表：

故障转移

如果在前面的配置示例中出现了超过请求失败次数的服务器，下面这些参数可以用来对这些服务器进行配置： proxy_ next_ upstream、 fastcgi_ next_ upstream、 uwsgi_ next_ upstream、 scgi_ next_ upstream、 memcached_ next_ upstream和 grpc_ next_ upstream。

下面用最常见的 proxy_ next_ upstream为例进行说明。

指令： proxy_ next_ upstream
语法： proxy_ next_ upstream error | timeout | invalid_ header | http_ 500 | http_ 502 | http_ 503 | http_ 504 | http_ 403 | http_ 404 | http_ 429 | non_ idempotent | off …;
默认值： proxy_ next_ upstream error timeout;
环境： http、 server、 location
含义：定义转发条件，当请求返回 Nginx时，如果 HTTP状态满足 proxy_ next_ upstream设置的条件，就会触发 Nginx将请求重新转发到下一台后端服务器，并累加出现此状态的服务器的失败次数（当超过 max_ fails和 fail_ timeout的值时就会设置此服务器为不可用）。如果设置为 off，则表示关闭此功能。

指令： proxy_ next_ upstream_ tries
语法： proxy_ next_ upstream_ tries number;
默认值： proxy_ next_ upstream_ tries 0;
环境： http、 server、 location
含义：定义尝试请求的次数，达到次数上限后就停止转发，并将请求内容返回客户端。

指令： proxy_ next_ upstream_ timeout
语法： proxy_ next_ upstream_ timeout time;
默认值： proxy_ next_ upstream_ timeout 0;
环境： http、 server、 location
含义：限制尝试请求的超时时间，如果第一次请求失败，下一次请求就会被此参数值控制。若设置为 0，则表示无超时时间，但尝试的请求仍会受到 proxy_ read_ timeout、 proxy_ send_ timeout、 proxy_ connect_ timeout的影响。

注意：通过这些配置，可以在后端服务器的某些节点出现请求异常时，快速做出故障切换的操作，从而屏蔽这些异常的请求。但是这存在一种隐患，即如果 proxy_ next_ upstream_ tries设置的值比较大，且 proxy_ next_ upstream也设置了很多状态，当发生大面积异常时，重试不断累加，可能会导致请求反复向多个服务器发送，这样会给后端服务器带来更大的压力。

负载均衡

Nginx不仅支持代理多台后端服务器，也支持各种负载均衡模式，负载均衡在 upstream的配置环境内设置（默认根据权重轮询）。

负载均衡指令见下表：

通过 hash分片提升缓存命中率

缓存系统是减少后端服务压力的重要组件，常见的 HTTP缓存系统有 Nginx的 proxy_ cache、 varnish、 squid。如果通过反向代理去获取缓存数据，一般需要使用 hash分片，以避免 URL的请求随机进入缓存系统的某个分片，导致缓存命中率低、后端服务器压力上升。

基于 URL缓存的服务配置一般如下所示，相同的 URL（包含参数）会进入相同的后端缓存系统。

注意：

增减节点会导致 hash重新计算，因此增减节点最好选择在服务的低峰期进行。在缓存系统上使用 max_ fails不一定是最好的选择，但一旦使用请确保 proxy_ next_ upstream的合理性，尽量不要配置各种 HTTP状态码，因为缓存系统代理的是后端服务，当后端服务异常时会将错误的状态码返回给 Nginx，这样会让 Nginx以为缓存系统出了问题，从而将缓存节点当作失败的节点，停止分流。

缓存系统的故障转移应该只以存活检查方式（一般指检查缓存系统的端口是否存活，以及固定检查一个接口是否能返回正常的响应）为主。可以结合健康检测功能，或者动态剔除异常缓存节点的功能来使用，详细介绍请看后续。

利用长连接提升性能

在 Nginx中，使用 upstream进行后端访问默认用的是短连接，但这会增加网络资源的消耗。可以通过配置长连接，来减少因建立连接产生的开销、提升性能。和长连接有关的配置示例如下：

长连接配置指令说明见下表：

注意：如果没有添加长连接，在压力测试（以下简称压测）环境中，可能会出现这样的情景：当压测达到一定的 QPS（ Query Per Second，每秒查询率）后， Nginx服务器突然“卡死”， QPS直接降到几乎为 0，但是压测并没有停；几分钟后又会自动恢复，然后再压测一段时间后， QPS又会突然降到接近于 0。这种情况就要考虑是不是 timewait的状态过多了。

利用 resolver加速对内部域名的访问

proxy_ pass可以直接将域名代理到后端服务器上，请求前会先解析出 IP地址，例如：

反复的 DNS（ Domain Name System，域名系统）解析会影响请求的速度，并且如果出现连接 DNS服务器超时的情况，可能会导致请求无法发送，这里需要用 DNS缓存来解决这个问题，示例代码如下：

resolver指令说明见下表。

注意：解析 DNS后，通过 set $ upstream_ host test2. zhe800. com的方式，将获取的 IP地址再赋值给 proxy_ pass，这是为了让 Nginx重新去解析 DNS中的 IP地址。利用 valid的配置，可以减少 DNS的解析次数，从而提高请求的效率。当然对 DNS缓存时间的控制也要有度，避免出现 DNS切换 IP地址后， Nginx无法快速切换到新 IP地址的情况。如果需要在 upstream内部对域名的配置进行解析，使用 Nginx的开源版会受到一些限制，因为此功能被放到了商业版中，需要和 zone的功能配合使用。

到此这篇关于Nginx upstream使用指南的文章就介绍到这了,更多相关Nginx upstream使用内容请搜索IT俱乐部以前的文章或继续浏览下面的相关文章希望大家以后多多支持IT俱乐部！