【nginx实战】nginx正向代理、反向代理、由反向代理实现的负载均衡、故障转移详解

本文将要讨论以下内容

1. 正向代理与反向代理的基本概念
2. Nginx正向代理服务的配置指令、Nginx反向代理服务的配置指令
3. Nginx反向代理服务器的应用——负载均衡、故障转移
4. 案例分析

 

正向代理的概念
局域网内的机器借助代理服务访问局域网外的网站，此代理服务器提供的服务就为正向代理服务。

作用

1. 主要是为了增强局域网内部网络的安全性，使得网外的威胁因素不容易影响到网内，这里代理服务器起到了一部分防火墙的功能。
2. 利用代理服务器也可以对局域网访问外网进行必要的监控和管理。

正向代理服务器不支持外部对内部网络的访问请求，即图的箭头方向不能反过来。

 
反向代理的概念
如果局域网向Internet提供资源，让Internet上的其他用户可以访问局域网内的资源，此代理服务器提供的服务就叫做反向代理（Reverse Proxy）服务。

小结

正向代理服务器用来让局域网客户机接入外网以访问外网资源，反向代理服务器用来让外网的客户端接入局域网中的站点以访问站点中的资源。
 
在正向代理服务器中，我们的角色是客户端，目的是要访问外网的资源；在反向代理服务器中，我们的角色是站点，目的是把站点的资源发布出去让其他客户端能够访问。

 

1.1. resolver指令

该指令用于指定DNS服务器的IP地址。DNS服务器的主要工作是进行域名解析，将域名映射为对应的IP地址。

使用该指令的一个例子如下：

 

1.2. resolver_timeout指令

该指令用于设置DNS服务器域名解析超时时间，语法结构为：

 

1.3. proxy_pass指令

该指令用于设置代理服务器的协议和地址，它不仅仅用于Nginx服务器的代理服务，更主要的是应用于反向代理服务。该指令的语法结构为：

其中，URL即为设置的代理服务器协议和地址。在代理服务配置中，该指令配置为

其中，代理服务器协议设置为HTTP，$http_host 和 $request_uri两个变量是Nginx配置支持的用于自动获取主机和URI的变量。

 

• 设置DNS服务器地址为8.8.8.8，使用默认的53端口作为DNS服务器的服务端口
• 代理服务的监听端口设置为82端口，Nginx服务器接收到的所有请求都由location块进行过滤处理。
• resolver指令是必需的，如果没有该指令，Nginx服务器无法处理接收到的域名。
• 注意：Nginx服务器的代理服务器不支持正向代理HTTPS站点。

 

Nginx服务器提供的反向代理服务能够同时接收的客户端连接的计算方法为：

配置Nginx服务器反向代理用到的指令配置在Nginx配置文件的http块、server块或者location块中，一般是单独配置一个server块用来设置反向代理服务。这些指令主要由ngx_http_proxy_module模块进行解析和处理。该模块是Nginx服务器的标准HTTP模块。

 

本小节涉及的指令比较重要，是为客户端提供正常Web服务的基础，大家应该熟练掌握，尤其是proxy_pass指令，在实际应用过程中需要注意一些配置细节，需要小心使用。

1.1. proxy_pass指令

1. 基础用法
该指令用来设置被代理服务器的地址，可以是主机名称、IP地址加端口号等形式。其语法结构为：

其中，URL为要设置的被代理服务器的地址：

• 包含传输协议、主机名称/IP地址加端口号、URI等要素。
• 传输协议通常是“http”或者“https://”。
• 指令同时还接受以“unix”开始的UNIX-domain套接字路径。

 
2. 配置一组服务器
如果被代理服务器是一组服务器的话，可以使用upstream指令配置后端服务器组。

在组内的各个服务器中都指明了传输协议“http://”，而在proxy_pass指令中就不需要指明了。

 
3. URI问题
如果URL中不包含URI，Nginx服务器不会改变原地址的URI；但是如果包含了URI，Nginx服务器将会使用新的URI替代原来的URI。

proxy_pass中不含有URI

proxy_pass中含有URI

小结：在使用proxy_pass指令时，如果不想改变原地址中的URI，就不要在URL变量中配置URI。

 
proxy_pass的URL末尾是否加斜杠“/”

在该配置中，location块使用“/”作为uri的值来匹配不包含URI的客户端请求。

 

1.2. proxy_set_header指令

该指令可以更改（ing）Nginx服务器接收到的客户端请求的请求头信息，然后将新的请求头发送给被代理的服务器。其语法结构为：

 

什么情况下会导致：ing

通过httpclient请求到nginx时，请求的header出现了丢失的情况？

 

1.3. proxy_ignore_headers指令

通过使用这个指令，可以控制哪些响应头部不会被传递给客户端，从而影响到客户端接收到的响应信息。

例如，想要代理服务器转发请求时忽略掉 和 这两个响应头部，可以这样配置：

 

1.4. proxy_timeout

（在客户端或代理服务器）两个成功连续的读（或写）操作之间如果超过timeout时间没有数据传输，链接将关闭。

以下是 proxy_timeout 的基本语法：

例如，设置代理请求的超时时间为 5 秒：

 

1.5. proxy_connect_timeout

用于设置代理与后端服务器建立连接时允许的最大时间。
如果在指定的时间内未能成功建立连接，Nginx 将终止连接并返回适当的错误。

例如，设置代理连接建立的超时时间为 3 秒：

 

Nginx服务器实现负载均衡，主要使用的配置是proxy_pass指令和upsteam指令。

1.1. 轮询（默认）

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

注意：

• 在轮询中，如果服务器down掉了，会自动剔除该服务器。
• 缺省配置就是轮询策略。
• 此策略适合服务器配置相当，无状态且短平快的服务使用。

 

1.2. weight

weight 代表权重，默认为1，weight和访问比率成正比，用于后端服务器性能不均的情况。

在该例子中，

1. weight参数用于指定轮询几率，weight的默认值为1
2. weight的数值与访问比率成正比，比如Tomcat 7.0被访问的几率为其他服务器的两倍。

注意：

• 权重越高分配到需要处理的请求越多。
• 此策略可以与least_conn和ip_hash结合使用。
• 此策略比较适合服务器的硬件配置差别比较大的情况。

 

1.3. ip_hash

ngx_http_upstream_module#ip_hash

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

不管刷新多少遍，始终访问的是同一台tomcat服务器，但当ip_hash到的机器挂掉时，会在剩余的机器中会重新ip_hash选定机器。

注意：

• 在nginx版本1.3.1之前，不能在ip_hash中使用权重（weight）。
• ip_hash不能与backup同时使用。
• 此策略适合有状态服务，比如session。
• 当有服务器需要剔除，必须手动down掉（这样不利于更新和故障时候的响应）

 

1.4. 最少连接least_conn

把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况下，least_conn这种方式就可以达到更好的负载均衡效果。

注意：此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况。

 

4.1. 例子1：轮询

例子实现功能

• backend服务器组中所有服务器访问优先级由weight设置。
• 所有访问www.myweb.name（由server_name配置进行匹配）的请求都会在backend服务器组中实现负载均衡。

访问过程说明

当有访问（server_name设置的）www.myweb.name的请求时，nginx会将请求转发到backend（通过upstream设置的server列表，根据轮询+权重选出一台）服务器来处理，处理后返回给客户端response。

 

4.2. 例子2：对特定资源实现负载均衡

根据相同域名的不同URI的请求前缀请求特定资源，实现负载均衡。

 

根据不同的域名+端口定位到请求的资源

 

1.1. nginx判断节点失效的逻辑

• Nginx 默认判断失败节点状态以connect refuse和timeout状态为准，不以HTTP错误状态进行判断失败，因为HTTP只要能返回状态说明该节点还可以正常连接，所以nginx判断其还是存活状态；
• 通过添加了proxy_next_upstream指令设置对404、502、503、504、500和time out等错误进行转到备机处理，在next_upstream过程中，会对fails进行累加，如果备用机处理还是错误则直接返回错误信息（但404不进行记录到错误数，如果不配置错误状态也不对其进行错误状态记录），

综述，nginx记录错误数量只记录timeout 、connect refuse、502、500、503、504这6种状态，timeout和connect refuse是永远被记录错误状态，而502、500、503、504只有在配置proxy_next_upstream后nginx才会记录这4种HTTP错误到fails中，当fails大于等于max_fails时，则该节点失效；

 

1.2. nginx处理节点失效和恢复的逻辑

参数设置：

nginx可以通过设置

• max_fails（最大尝试失败次数）
• fail_timeout（失效时间，在到达最大尝试失败次数后，在fail_timeout的时间范围内节点被置为失效，除非所有节点都失效，否则该时间内，节点不进行恢复）
  对节点失败的尝试次数和失效时间进行设置。

节点失效和恢复逻辑：

a. 当超过最大尝试次数或失效时间未超过配置失效时间，则nginx会对节点状会置为失效状态，nginx不对该后端进行连接，直到超过失效时间或者所有节点都失效后，该节点重新置为有效，重新探测。
b. 在fail_timeout时间内，被判定为down的后端server是不可能得到接收数据机会的，即使它恢复过来了！
c. fail_timeout时间过后，nginx会尝试去通过发送数据请求到这个down的后端服务器上去测试它是否起来没有。

 

1.3. 所有节点失效后nginx将重新恢复所有节点进行探测

如果探测所有节点均失效，备机也为失效时，那么nginx会对所有节点恢复为有效，重新尝试探测有效节点，如果探测到有效节点则返回正确节点内容，如果还是全部错误，那么继续探测下去，当没有正确信息时，节点失效时默认返回状态为502，但是下次访问节点时会继续探测正确节点，直到找到正确的为止。

 

和一起使用，就构成了NGINX的故障转移机制，使得在某一台服务器无法连接或出现问题(连接错误、超时或者上游服务器返回特定 HTTP 状态码)时，能够尝试将请求发送到下一台服务器。

在此配置中，Nginx会首先尝试连接到。如果在5秒内无法建立连接，或者该服务器返回500、502、503或504的HTTP状态码，Nginx将尝试连接到下一个上游服务器。

 

使用 backup 参数为某些上游服务器标记为备份服务器。备份服务器仅在其他所有服务器不可用时才被使用。
示例：

这些方法可以单独或组合使用，具体取决于需求和架构。

 

有一个发送短信的http服务，客户端调用之后，只有一次请求，但是发了三次短信。

分析：

1. 代码中没有重试机制，通过请求分布来看，不是一台机器处理了三次，而是每台机器都处理了一次。
2. 由nginx转发导致。 查看接口的响应时间发现每个接口的响应时间为18s左右。分析是由于后端服务器未能及时返回数据，导致了nginx的超时重试机器，将请求分发到了另外一台机器上。

查看nginx的配置文件，发现如下配置：

即实现了请求的故障转移，此时说明我们timeout设置的时间与实际接口请求情况不符。

 

解决方式：

nginx的熔断机制

当某台服务器被（反向代理服务器）转发处理请求，当出现一定次数的错误的情况下，nginx在一定时间内不再将请求分配给这台服务器进行处理。 过了熔断时间后，nginx会再次尝试分配一次请求给该服务器处理，如果还是失败，那么继续熔断。

upstream指令块中server定义的熔断参数配置

• max_fails = number; # 熔断机制的错误次数 阈值（默认1）
• fail_timeout = time #熔断时间（nginx标记服务器不可用的持续时间，默认10s）

配置如下：