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

文章目录一. 正向代理与反向代理的概念二. Nginx服务器的正向代理服务1. Nginx服务器正向代理服务的配置的3个指令1.1. resolver指令1.2. resolver_timeout指令1.3. proxy_pass指令2. Nginx服务器正向代理服务的使用三. Nginx服务器的反向代理服务1. 反向代理的基本指令1.1. proxy_pass指令1.2. proxy_set_header指令1.3. proxy_ignore_headers指令1.4. proxy_timeout1.5. proxy_connect_timeout四. Nginx服务器的负载均衡1. nginx的upstream负载均衡方式1.1. 轮询默认1.2. weight1.3. ip_hash1.4. 最少连接least_conn3. 负载均衡常见参数4. 实现例子4.1. 例子1轮询4.2. 例子2对特定资源实现负载均衡4.3. 例子3对不同域名实现负载均衡五. nginx实现故障转移1. 基本逻辑1.1. nginx判断节点失效的逻辑1.2. nginx处理节点失效和恢复的逻辑1.3. 所有节点失效后nginx将重新恢复所有节点进行探测2. proxy_next_upstream proxy_connect_timeout3. Backup Servers六. 案例分析1. 问题描述2. 问题分析与解决本文将要讨论以下内容正向代理与反向代理的基本概念Nginx正向代理服务的配置指令、Nginx反向代理服务的配置指令Nginx反向代理服务器的应用——负载均衡、故障转移案例分析一. 正向代理与反向代理的概念正向代理的概念局域网内的机器借助代理服务访问局域网外的网站此代理服务器提供的服务就为正向代理服务。作用主要是为了增强局域网内部网络的安全性使得网外的威胁因素不容易影响到网内这里代理服务器起到了一部分防火墙的功能。利用代理服务器也可以对局域网访问外网进行必要的监控和管理。正向代理服务器不支持外部对内部网络的访问请求即图的箭头方向不能反过来。反向代理的概念如果局域网向Internet提供资源让Internet上的其他用户可以访问局域网内的资源此代理服务器提供的服务就叫做反向代理Reverse Proxy服务。小结正向代理服务器用来让局域网客户机接入外网以访问外网资源反向代理服务器用来让外网的客户端接入局域网中的站点以访问站点中的资源。在正向代理服务器中我们的角色是客户端目的是要访问外网的资源在反向代理服务器中我们的角色是站点目的是把站点的资源发布出去让其他客户端能够访问。二. Nginx服务器的正向代理服务1. Nginx服务器正向代理服务的配置的3个指令1.1. resolver指令该指令用于指定DNS服务器的IP地址。DNS服务器的主要工作是进行域名解析将域名映射为对应的IP地址。resolver address...[validtime];■ addressDNS服务器的IP地址。如果不指定端口号默认使用53端口。 ■ time设置数据包在网络中的有效时间。 出现该指令的主要原因是在访问站点时有很多情况使得数据包在一定时间内不能被传递到目的地但是又不能让该数据包无期限地存在于是就需要设定一段时间当数据包**在这段时间内没有到达目的地就会被丢弃**然后发送者会接收到一个消息并决定是否要重发该数据包。使用该指令的一个例子如下resolver127.0.0.1[::1]:5353valid30s;1.2. resolver_timeout指令该指令用于设置DNS服务器域名解析超时时间语法结构为resolver_timeouttime;1.3. proxy_pass指令该指令用于设置代理服务器的协议和地址它不仅仅用于Nginx服务器的代理服务更主要的是应用于反向代理服务。该指令的语法结构为proxy_pass URL;其中URL即为设置的代理服务器协议和地址。在代理服务配置中该指令配置为proxy_pass http://$http_host$request_uri;其中代理服务器协议设置为HTTP$http_host 和 $request_uri两个变量是Nginx配置支持的用于自动获取主机和URI的变量。2. Nginx服务器正向代理服务的使用… server{resolver8.8.8.8;listen82;location /{proxy_pass http://$http_host$request_uri;}}…设置DNS服务器地址为8.8.8.8使用默认的53端口作为DNS服务器的服务端口代理服务的监听端口设置为82端口Nginx服务器接收到的所有请求都由location块进行过滤处理。resolver指令是必需的如果没有该指令Nginx服务器无法处理接收到的域名。注意Nginx服务器的代理服务器不支持正向代理HTTPS站点。三. Nginx服务器的反向代理服务Nginx服务器提供的反向代理服务能够同时接收的客户端连接的计算方法为worker_processes * worker_connections /4配置Nginx服务器反向代理用到的指令配置在Nginx配置文件的http块、server块或者location块中一般是单独配置一个server块用来设置反向代理服务。这些指令主要由ngx_http_proxy_module模块进行解析和处理。该模块是Nginx服务器的标准HTTP模块。1. 反向代理的基本指令本小节涉及的指令比较重要是为客户端提供正常Web服务的基础大家应该熟练掌握尤其是proxy_pass指令在实际应用过程中需要注意一些配置细节需要小心使用。1.1. proxy_pass指令1. 基础用法该指令用来设置被代理服务器的地址可以是主机名称、IP地址加端口号等形式。其语法结构为proxy_pass URL;其中URL为要设置的被代理服务器的地址包含传输协议、主机名称/IP地址加端口号、URI等要素。传输协议通常是“http”或者“https://”。指令同时还接受以“unix”开始的UNIX-domain套接字路径。proxy_pass http://www.myweb.name/uri;proxy_pass http://localhost:8000/uri/;proxy_pass http://unix:8000/uri/;2. 配置一组服务器如果被代理服务器是一组服务器的话可以使用upstream指令配置后端服务器组。…#配置后端服务器组upstream proxy_svrs{server http://192.168.1.1:8001/uri/;server http://192.168.1.2:8001/uri/;server http://192.168.1.3:8001/uri/;}server{… listen80;server_name www.myweb.name;location /{proxy_pass proxy_svrs;#使用服务器组的名称}}在组内的各个服务器中都指明了传输协议“http://”而在proxy_pass指令中就不需要指明了。3. URI问题如果URL中不包含URINginx服务器不会改变原地址的URI但是如果包含了URINginx服务器将会使用新的URI替代原来的URI。proxy_pass中不含有URI#如果客户端使用http://www.myweb.name:80/server发起请求该请求#被配置中显示的location块进行处理由于proxy_pass指令的URL变量不#含有URI所以转向的地址为“http://192.168.1.1:80/server。… server{… listen80;server_name www.myweb.name;location /server/{… proxy_pass http://192.168.1.1;}}proxy_pass中含有URI#如果客户端仍然使用“http://www. myweb.name/server/”发起请求#Nginx服务器将会把地址转向“http://192.168.1.1/loc/”。… server{… listen80;server_name www.myweb.name;location /server/{… proxy_pass http://192.168.1.1/loc/;}}小结在使用proxy_pass指令时如果不想改变原地址中的URI就不要在URL变量中配置URI。proxy_pass的URL末尾是否加斜杠“/”#配置1 proxy_pass http://192.168.1.1;#不包含uri #配置2 proxy_pass http://192.168.1.1/;#包含了uri/在该配置中location块使用“/”作为uri的值来匹配不包含URI的客户端请求。# 由于请求URL中不包含URI因此配置1和配置2的效果是一样的。# 配置2# 因为根据替换逻辑http://www.myweb.name/index.htm 请求的/,会被替换为/,相当于没有替换。… server{… listen80;server_name www.myweb.name;#注意location的uri变量location /{…#配置1 proxy_pass http://192.168.1.1;#配置2 proxy_pass http://192.168.1.1/;}}# 请求http://www.myweb.name/server/index.htm#使用配置1因为proxy_pass没有uri所以客户端请求uri不会被替换#使用配置2proxy_pass有uri客户端请求的uri会将被location中/server/替换为(proxy_pass的uri)/转向的URL为“http://192.168.1.1/index.htm。… server{… listen80;server_name www.myweb.name;location /server/#注意location的uri变量{…#配置1 proxy_pass http://192.168.1.1;#配置2 proxy_pass http://192.168.1.1/;}}1.2. proxy_set_header指令该指令可以更改ingNginx服务器接收到的客户端请求的请求头信息然后将新的请求头发送给被代理的服务器。其语法结构为proxy_set_header field value;■ field要更改的信息所在的头域。 ■ value更改的值支持使用文本、变量或者变量的组合。什么情况下会导致ing通过httpclient请求到nginx时请求的header出现了丢失的情况1.3. proxy_ignore_headers指令通过使用这个指令可以控制哪些响应头部不会被传递给客户端从而影响到客户端接收到的响应信息。proxy_ignore_headers field...;# 其中field为要设置的HTTP响应头的头域例如“X-Accel-Redirect”、#“X-Accel-Expires”、“Expires”、“Cache-Control”或“Set-Cookie”等。例如想要代理服务器转发请求时忽略掉Set-Cookie和Cache-Control这两个响应头部可以这样配置location /{proxy_pass http://backend_server;proxy_ignore_headers Set-Cookie Cache-Control;}1.4. proxy_timeoutnginx官网 - proxy_timeout在客户端或代理服务器两个成功连续的读或写操作之间如果超过timeout时间没有数据传输链接将关闭。以下是 proxy_timeout 的基本语法proxy_timeouttimeout;#1.timeout: 指定的超时时间以秒为单位。可以是整数或者带有小数点的浮点数。例如设置代理请求的超时时间为 5 秒location /{proxy_pass http://backend_server;proxy_timeout 5s;}1.5. proxy_connect_timeout用于设置代理与后端服务器建立连接时允许的最大时间。如果在指定的时间内未能成功建立连接Nginx 将终止连接并返回适当的错误。例如设置代理连接建立的超时时间为 3 秒location /{proxy_pass http://backend_server;proxy_connect_timeout 3s;}四. Nginx服务器的负载均衡Nginx服务器实现负载均衡主要使用的配置是proxy_pass指令和upsteam指令。1. nginx的upstream负载均衡方式方式解释轮询默认方式weight权重方式ip_hash依据ip分配方式least_conn最少连接方式1.1. 轮询默认每个请求按时间顺序逐一分配到不同的后端服务器如果后端服务器down掉能自动剔除。注意在轮询中如果服务器down掉了会自动剔除该服务器。缺省配置就是轮询策略。此策略适合服务器配置相当无状态且短平快的服务使用。1.2. weightweight 代表权重默认为1weight和访问比率成正比用于后端服务器性能不均的情况。upstream backServer { server localhost:8080 weight2; #tomcat 7.0 server localhost:8081; #tomcat 8.0 server localhost:8082 backup; #tomcat 8.5 server localhost:8083 max_fails3 fail_timeout20s; #tomcat 9.0 }在该例子中weight参数用于指定轮询几率weight的默认值为1weight的数值与访问比率成正比比如Tomcat 7.0被访问的几率为其他服务器的两倍。注意权重越高分配到需要处理的请求越多。此策略可以与least_conn和ip_hash结合使用。此策略比较适合服务器的硬件配置差别比较大的情况。1.3. ip_hashngx_http_upstream_module#ip_hash每个请求按访问ip的hash结果分配这样每个访客固定访问一个后端服务器可以解决session的问题。不管刷新多少遍始终访问的是同一台tomcat服务器但当ip_hash到的机器挂掉时会在剩余的机器中会重新ip_hash选定机器。upstream backServer{ ip_hash; server 192.168.203.14:88; server 192.168.203.15:80; }注意在nginx版本1.3.1之前不能在ip_hash中使用权重weight。ip_hash不能与backup同时使用。此策略适合有状态服务比如session。当有服务器需要剔除必须手动down掉这样不利于更新和故障时候的响应1.4. 最少连接least_conn把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端使它们的负载大致相同但是有些请求占用的时间很长会导致其所在的后端负载较高。这种情况下least_conn这种方式就可以达到更好的负载均衡效果。upstream backServer{ least_conn; server 127.0.0.1:8080; server 127.0.0.1:9090; }注意此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况。3. 负载均衡常见参数参数说明fail_timeout与max_fails结合使用。max_fails设置在fail_timeout参数设置的时间内最大失败次数如果在这个时间内所有针对该服务器的请求都失败了那么认为该服务器会被认为是停机了。fail_time服务器会被认为停机的时间长度,默认为10s。backup标记该服务器为备用服务器。当主服务器停止时请求会被发送到它这里。down标记服务器永久停机了。4. 实现例子4.1. 例子1轮询例子实现功能backend服务器组中所有服务器访问优先级由weight设置。所有访问www.myweb.name由server_name配置进行匹配的请求都会在backend服务器组中实现负载均衡。…#配置后端服务器组upstream backend{server192.168.1.2:80weight5;server192.168.1.3:80weight2;#默认weight1server192.168.1.4:80;}server{listen80;server_name www.myweb.name;index index.html index.htm;location /{proxy_pass http://backend;proxy_set_header Host$host;…}…}访问过程说明当有访问server_name设置的www.myweb.name的请求时nginx会将请求转发到backend通过upstream设置的server列表根据轮询权重选出一台服务器来处理处理后返回给客户端response。4.2. 例子2对特定资源实现负载均衡根据相同域名的不同URI的请求前缀请求特定资源实现负载均衡。…#其他配置#配置后端服务器组1upstream videobackend{server192.168.1.2:80;server192.168.1.3:80;server192.168.1.4:80;}#配置后端服务器组2upstream filebackend{server192.168.1.5:80;server192.168.1.6:80;server192.168.1.7:80;}server{listen80;server_name www.myweb.name;index index.html index.htm;# location用于接收来自serverwww.myweb.name的请求并根据不同的uri前缀将请求转发到不同的后端中#使用后端服务器组1location /video/{proxy_pass http://videobackend;proxy_set_header Host$host;…}#使用后端服务器组2location /file/{proxy_pass http://filebackend;# 设置header 保留客户端的真实信息proxy_set_header Host$host;proxy_set_header X-Real-IP$remote_addr;proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for;…}…}4.3. 例子3对不同域名实现负载均衡根据不同的域名端口定位到请求的资源… upstream bbsbackend{server192.168.1.2:80weight2;server192.168.1.3:80weight2;server192.168.1.4:80;}upstream homebackend{server192.168.1.4:80;server192.168.1.5:80;server192.168.1.6:80;}# 开始配置server 1server{listen80;server_name home.myweb.name;index index.html index.htm;location /{proxy_pass http://homebackend;proxy_set_header Host$host;…}…}# 开始配置server 2server{listen81;server_name bbs.myweb.name;index index.html index.htm;location /{proxy_pass http://bbsbackend;proxy_set_header Host$host;…}…}五. nginx实现故障转移1. 基本逻辑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但是下次访问节点时会继续探测正确节点直到找到正确的为止。2. proxy_next_upstream proxy_connect_timeoutproxy_next_upstream和proxy_connect_timeout一起使用就构成了NGINX的故障转移机制使得在某一台服务器无法连接或出现问题(连接错误、超时或者上游服务器返回特定 HTTP 状态码)时能够尝试将请求发送到下一台服务器。location / { proxy_pass http://backend_servers; proxy_connect_timeout 10s; proxy_next_upstream error timeout http_500 http_502 http_503 http_504; # 其他配置项... }在此配置中Nginx会首先尝试连接到backend1.example.com。如果在5秒内无法建立连接或者该服务器返回500、502、503或504的HTTP状态码Nginx将尝试连接到下一个上游服务器backend2.example.com。3. Backup Servers使用 backup 参数为某些上游服务器标记为备份服务器。备份服务器仅在其他所有服务器不可用时才被使用。示例upstream backend_servers{server backend_server1;server backend_server2 backup;server backend_server3 backup;}这些方法可以单独或组合使用具体取决于需求和架构。六. 案例分析1. 问题描述有一个发送短信的http服务客户端调用之后只有一次请求但是发了三次短信。2. 问题分析与解决分析代码中没有重试机制通过请求分布来看不是一台机器处理了三次而是每台机器都处理了一次。由nginx转发导致。 查看接口的响应时间发现每个接口的响应时间为18s左右。分析是由于后端服务器未能及时返回数据导致了nginx的超时重试机器将请求分发到了另外一台机器上。查看nginx的配置文件发现如下配置proxy_next_upstream http_502 http_504 errortimeoutinvalid_header;即实现了请求的故障转移此时说明我们timeout设置的时间与实际接口请求情况不符。解决方式nginx的熔断机制当某台服务器被反向代理服务器转发处理请求当出现一定次数的错误的情况下nginx在一定时间内不再将请求分配给这台服务器进行处理。 过了熔断时间后nginx会再次尝试分配一次请求给该服务器处理如果还是失败那么继续熔断。upstream指令块中server定义的熔断参数配置max_fails number; # 熔断机制的错误次数 阈值默认1fail_timeout time #熔断时间nginx标记服务器不可用的持续时间默认10s配置如下... upstream starrocks-tcp2{ip_hash;server hostname1:8030weight1max_fails1fail_timeout10s;#Leaderserver hostname2:8030weight1max_fails1fail_timeout10s;#Followerserver hostname3:8030weight1max_fails1fail_timeout10s;#Follower}...参考《Nginx高性能Web服务器详解》https://zhuanlan.zhihu.com/p/547130562nginx官网 - ngx_stream_proxy_module