b2c信息网

您现在的位置是:首页 > 头条资讯 > 正文

头条资讯

nginx的健康检查(nginx反向代理 健康检查)

hacker2022-06-09 06:55:23头条资讯65
本文目录一览:1、请教问题nginx反向代理proxy

本文目录一览:

请教问题nginx反向代理proxy

一、反向代理:Web服务器的“经纪人”

1.1 反向代理初印象

反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。

Nginx搭建反向代理服务器过程详解

从上图可以看出:反向代理服务器位于网站机房,代理网站Web服务器接收Http请求,对请求进行转发。

1.2 反向代理的作用

①保护网站安全:任何来自Internet的请求都必须先经过代理服务器;Nginx搭建反向代理服务器过程详解

②通过配置缓存功能加速Web请求:可以缓存真实Web服务器上的某些静态资源,减轻真实Web服务器的负载压力;Nginx搭建反向代理服务器过程详解

③实现负载均衡:充当负载均衡服务器均衡地分发请求,平衡集群中各个服务器的负载压力;Nginx搭建反向代理服务器过程详解

二、初识Nginx:简单却不平凡

2.1 Nginx是神马?

Nginx搭建反向代理服务器过程详解

Nginx是一款轻量级的网页服务器、反向代理器以及电子邮件代理服务器。其将源代码以类BSD许可证的形式发布,因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。

Source:Nginx(发音同engine x),它是由俄罗斯程序员Igor Sysoev所开发的。起初是供俄国大型的门户网站及搜索引擎Rambler(俄语:Рамблер)使用。此软件BSD-like协议下发行,可以在UNIX、GNU/Linux、BSD、Mac OS X、Solaris,以及Microsoft Windows等操作系统中运行。

说到Web服务器,Apache服务器和IIS服务器是两大巨头;但是运行速度更快、更灵活的对手:Nginx 正在迎头赶上。

2.2 Nginx的应用现状

Nginx 已经在俄罗斯最大的门户网站── Rambler Media()上运行了3年时间,同时俄罗斯超过20%的虚拟主机平台采用Nginx作为反向代理服务器。

Nginx搭建反向代理服务器过程详解Nginx搭建反向代理服务器过程详解Nginx搭建反向代理服务器过程详解Nginx搭建反向代理服务器过程详解Nginx搭建反向代理服务器过程详解在国内,已经有 淘宝、新浪博客、新浪播客、网易新闻、六间房、56.com、Discuz!、水木社区、豆瓣、YUPOO、海内、迅雷在线 等多家网站使用 Nginx 作为Web服务器或反向代理服务器。

2.3 Nginx的核心特点

(1)跨平台:Nginx 可以在大多数 Unix like OS编译运行,而且也有Windows的移植版本;(2)配置异常简单:非常容易上手。配置风格跟程序开发一样,神一般的配置;(3)非阻塞、高并发连接:数据复制时,磁盘I/O的第一阶段是非阻塞的。官方测试能够支撑5万并发连接,在实际生产环境中跑到2~3万并发连接数。(这得益于Nginx使用了最新的epoll模型);PS:对于一个Web服务器来说,首先看一个请求的基本过程:建立连接—接收数据—发送数据,在系统底层看来 :上述过程(建立连接—接收数据—发送数据)在系统底层就是读写事件。

①如果采用阻塞调用的方式,当读写事件没有准备好时,必然不能够进行读写事件,那么久只好等待,等事件准备好了,才能进行读写事件,那么请求就会被耽搁 。

②既然没有准备好阻塞调用不行,那么采用非阻塞调用方式。非阻塞就是:事件马上返回,告诉你事件还没准备好呢,你慌什么,过会再来吧。好吧,你过一会,再来检查一下事件,直到事件准备好了为止,在这期间,你就可以先去做其它事情,然后再来看看事件好了没。虽然不阻塞了,但你得不时地过来检查一下事件的状态,你可以做更多的事情了,但带来的开销也是不小的。

(4)事件驱动:通信机制采用epoll模型,支持更大的并发连接。

①非阻塞通过不断检查事件的状态来判断是否进行读写操作,这样带来的开销很大,因此就有了异步非阻塞的事件处理机制。这种机制让你可以同时监控多个事件,调用他们是阻塞的,但可以设置超时时间,在超时时间之内,如果有事件准备好了,就返回。这种机制解决了上面阻塞调用与非阻塞调用的两个问题。

②以epoll模型为例:当事件没有准备好时,就放入epoll(队列)里面。如果有事件准备好了,那么就去处 理;如果事件返回的是EAGAIN,那么继续将其放入epoll里面。从而,只要有事件准备好了,我们就去处理它,只有当所有事件都没有准备好时,才在 epoll里面等着。这样,我们就可以并发处理大量的并发了,当然,这里的并发请求,是指未处理完的请求,线程只有一个,所以同时能处理的请求当然只有一 个了,只是在请求间进行不断地切换而已,切换也是因为异步事件未准备好,而主动让出的。这里的切换是没有任何代价,你可以理解为循环处理多个准备好的事 件,事实上就是这样的。

③与多线程方式相比,这种事件处理方式是有很大的优势的,不需要创建线程,每个请求占用的内存也很少,没有上下文切换, 事件处理非常的轻量级,并发数再多也不会导致无谓的资源浪费(上下文切换)。对于IIS服务器,每个请求会独占一个工作线程,当并发数上到几千时,就同时 有几千的线程在处理请求了。这对操作系统来说,是个不小的挑战:因为线程带来的内存占用非常大,线程的上下文切换带来的cpu开销很大,自然性能就上不 去,从而导致在高并发场景下性能下降严重。

总结:通过异步非阻塞的事件处理机制,Nginx实现由进程循环处理多个准备好的事件,从而实现高并发和轻量级。

(5)Master/Worker结构:一个master进程,生成一个或多个worker进程。

Nginx搭建反向代理服务器过程详解

PS:Master-Worker设计模式核心思想是将原来串行的逻辑并行化, 并将逻辑拆分成很多独立模块并行执行。其中主要包含两个主要组件Master和Worker,Master主要将逻辑进行拆分,拆分为互相独立的部分,同 时维护了Worker队列,将每个独立部分下发到多个Worker并行执行,Worker主要进行实际逻辑计算,并将结果返回给Master。

问:nginx采用这种进程模型有什么好处?

答:采用独立的进程,可以让互相之间不会影响,一个进程退出后,其它进程还在工作,服务不会中断,Master 进程则很快重新启动新的Worker进程。当然,Worker进程的异常退出,肯定是程序有bug了,异常退出,会导致当前Worker上的所有请求失 败,不过不会影响到所有请求,所以降低了风险。

(6)内存消耗小:处理大并发的请求内存消耗非常小。在3万并发连接下,开启的10个Nginx 进程才消耗150M内存(15M*10=150M)。

(7)内置的健康检查功能:如果 Nginx 代理的后端的某台 Web 服务器宕机了,不会影响前端访问。

(8)节省带宽:支持 GZIP 压缩,可以添加浏览器本地缓存的 Header 头。

(9)稳定性高:用于反向代理,宕机的概率微乎其微。

三、构建实战:Nginx+IIS构筑Web服务器集群的负载均衡这里我们主要在Windows环境下,通过将同一个Web网站部署到不同服务器的IIS上,再通过一个统一的Nginx反响代理服务器对外提供统一访问接入,实现一个最简化的反向代理和负载均衡服务。但是,受限于实验条件, 我们这里主要在一台计算机上进行反向代理、IIS集群的模拟,具体的实验环境如下图所示:我们将nginx服务和web网站都部署在一台计算机 上,nginx监听http80端口,而web网站分别以不同的端口号(这里是8050及8060)部署在同一个IIS服务器上,用户访问 localhost时,nginx作为反向代理将请求均衡地转发给两个IIS中不同端口的Web应用程序进行处理。虽然实验环境很简单而且有限,但是对于 一个简单的负载均衡效果而言,本文是可以达到并且展示的。

Nginx搭建反向代理服务器过程详解

3.1 准备一个ASP.NET网站部署到IIS服务器集群中(1)在VS中新建一个ASP.NET Web应用程序,但是为了在一台计算机上展示效果,我们将这个Web程序复制一份,并修改两个Web程序的Default.aspx,让其的首页显示不同 的一点信息。这里Web1展示的是“The First Web:”,而Web2展示的则是“The Second Web”。

Nginx搭建反向代理服务器过程详解

(2)调试运行,看看两个网站的效果如何?

①Web1的展示效果:

Nginx搭建反向代理服务器过程详解

②Web2的展示效果:

Nginx搭建反向代理服务器过程详解

③部署到IIS中,分配不同的端口号:这里我选择了Web1:8050,Web2:8060Nginx搭建反向代理服务器过程详解

(3)总结:在真实环境中,构建Web应用服务器集群的实现是将同一个Web应用程序部署到Web服务器集群中的多个Web服务器上。

3.2 下载Nginx并部署到服务器中作为自启动的Windows服务(1)到Nginx官网下载Nginx的Windows版本:(这里我们使用nginx/Windows-1.4.7版本进行实验,本文底部有下载地址)(2)解压到磁盘任意目录,例如这里我解压到了:D:\Servers\nginx-1.4.7(3)启动、停止和重新加载服务:通过cmd以守护进程方式启动nginx.exe:start nginx.exe,停止服务:nginx -s stop,重新加载配置:nginx -s reload;Nginx搭建反向代理服务器过程详解

(4)每次以cmd方式启动Nginx服务不符合实际要求,于是我们想到将其注册为Windows服务,并设置为自动启动模式。这里,我们使用一个 不错的小程序:“Windows Service Wrapper”,将nginx.exe注册为Windows服务,具体的步凑如下:

①下载最新版的 Windows Service Wrapper 程序,比如我下载的名称是 “winsw-1.8-bin.exe”(本文底部有下载地址),然后把它命名成你想要的名字(比如: “nginx-service.exe”,当然,你也可以不改名)②将重命名后的 nginx-service.exe 复制到 nginx 的安装目录(比如,我这里是 “D:\Servers\nginx-1.4.7″)③在同一个目录下创建一个Windows Service Wrapper 的XML配置文件,名称必须与第一步重命名时使用的名称一致(比如我这里是 “nginx-service.xml”, 如果,你没有重命名,则应该是 “winsw-1.8-bin.xml”),这个XML的内容如下:

?xml version="1.0" encoding="UTF-8" ?

service

idnginx/id

nameNginx Service/name

descriptionHigh Performance Nginx Service/description

executableD:\Servers\nginx-1.4.7\nginx.exe/executable

logpathD:\Servers\nginx-1.4.7\/logpath

logmoderoll/logmode

depend/depend

startargument-p D:\Servers\nginx-1.4.7/startargument

stopargument-p D:\Servers\nginx-1.4.7 -s stop/stopargument

/service

④在命令行下执行以下命令,以便将其注册成Windows服务:nginx-service.exe installNginx搭建反向代理服务器过程详解

⑤接下来就可以在Windows服务列表看到Nginx服务了,这里我们可以将其设置为自动启动了:

Nginx搭建反向代理服务器过程详解

(5)总结:在Windows环境中,要对外提供的Windows服务一般都要将其启动类型设置为自动。

3.3 修改Nginx核心配置文件nginx.conf

(1)进程数与每个进程的最大连接数:

?nginx进程数,建议设置为等于CPU总核心数

?单个进程最大连接数,那么该服务器的最大连接数=连接数*进程数Nginx搭建反向代理服务器过程详解

(2)Nginx的基本配置:

?监听端口一般都为http端口:80;

?域名可以有多个,用空格隔开:例如 server_name ha97.com;Nginx搭建反向代理服务器过程详解

(3)负载均衡列表基本配置:

?location / {}:对aspx后缀的进行负载均衡请求,假如我们要对所有的aspx后缀的文件进行负载均衡时,可以这样写:location ~ .*\.aspx$ {}

?proxy_pass:请求转向自定义的服务器列表,这里我们将请求都转向标识为的负载均衡服务器列表;Nginx搭建反向代理服务器过程详解

?在负载均衡服务器列表的配置中,weight是权重,可以根据机器配置定义权重(如果某台服务器的硬件配置十分好,可以处理更多的请求,那么可以 为其设置一个比较高的weight;而有一台的服务器的硬件配置比较差,那么可以将前一台的weight配置为weight=2,后一台差的配置为 weight=1)。weigth参数表示权值,权值越高被分配到的几率越大;Nginx搭建反向代理服务器过程详解

(4)总结:最基本的Nginx配置差不多就是上面这些内容,当然仅仅是最基础的配置。(详细的配置内容请下载底部的nginx-1.4.7详细查看)3.4 添加Nginx对于静态文件的缓存配置

为了提高响应速度,减轻真实服务器的负载,对于静态资源我们可以在反向代理服务器中进行缓存,这也是反向代理服务器的一个重要的作用。

(1)缓存静态资源之图片文件

root /nginx-1.4.7/staticresources/image:对于配置中提到的jpg/png等文件均定为到/nginx-1.4.7/staticresources/image文件夹中进行寻找匹配并将文件返回;expires 7d:过期时效为7天,静态文件不怎么更新,过期时效可以设大一点,如果频繁更新,则可以设置得小一点;TIPS:下面的样式、脚本缓存配置同这里一样,只是定位的文件夹不一样而已,不再赘述。

Nginx搭建反向代理服务器过程详解

(2)缓存静态资源之样式文件

Nginx搭建反向代理服务器过程详解

(3)缓存静态资源之脚本文件

Nginx搭建反向代理服务器过程详解

(4)在nginx服务文件夹中创建静态资源文件夹,并要缓存的静态文件拷贝进去:这里我主要将Web程序中用到的image、css以及js文件拷贝了进去;Nginx搭建反向代理服务器过程详解

(5)总结:通过配置静态文件的缓存设置,对于这些静态文件的请求可以直接从反向代理服务器中直接返回,而无需再将这些静态资源请求转发到具体的Web服务器进行处理了,可以提高响应速度,减轻真实Web服务器的负载压力。

3.5 简单测试Nginx反向代理实现负载均衡效果(1)第一次访问时从127.0.0.1:8050处理响应返回结果(2)第二次访问时从127.0.0.1:8060处理响应返回结果(3)多次访问时的截屏:

Nginx搭建反向代理服务器过程详解

学习小结

在本文中,借助了Nginx这个神器简单地在Windows环境下搭建了一个反向代理服务,并模拟了一个IIS服务器集群的负载均衡效果。从这个 DEMO中,我们可以简单地感受到反向代理为我们所做的事情,并体会负载均衡是怎么一回事。但是,在目前大多数的应用中,都会将Nginx部署在 Linux服务器中,并且会做一些针对负载均衡的优化配置,这里我们所做的仅仅就是一个小小的使用而已(just修改一下配置文件)。不过,万丈高楼平地 起,前期的小小体会,也会帮助我们向后期的深入学习奠定一点点的基础。

突然在QQ空间里看到了朋友送的礼物,猛然发现今天居然是我的阳历生日,好吧,我祝我自己生日快乐,希望自己在未来的日子中能够做更多的实践,分享更多的内容。当然,如果你觉得本文还可以,那也麻烦点个赞,不要吝啬你的鼠标左键哟。

nginx-tengine health_check报错

很多人都知道nginx可以做反向代理和负载均衡,但是关于nginx的健康检查(health_check)机制了解的不多。其实社区版nginx提供的health_check机制其实很薄弱,主要是通过在upstream中配置max_fails和fail_timeout来实现,这边文章主要是深入分析社区版的health_check机制,当然还有更好的一些建议,比如商业版的nginx plus或者阿里的tengine,他们包含的健康检查机制更加完善和高效,如果你坚持使用nginx社区版,当然还可以自己写或者找第三方模块来编译了。

首先说下我的测试环境,CentOS release 6.4 (Final) + nginx_1.6.0 + 2台tomcat8.0.15作为后端服务器。(声明:以下所有配置仅仅为测试所用,不代表线上环境真实所用,真正的线上环境需要更多配置和优化。)

nginx配置如下:

#user nobody;worker_processes 1;#pid logs/nginx.pid;events {worker_connections 1024;

}http {include mime.types;default_type application/octet-stream;log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for"';access_log logs/access.log main;sendfile on;keepalive_timeout 65;upstream backend { server localhost:9090 max_fails=1 fail_timeout=40s; server localhost:9191 max_fails=1 fail_timeout=40s;

}server { listen 80; server_name localhost; location / { proxy_pass ; proxy_connect_timeout 1; proxy_read_timeout 1;

} error_page 500 502 503 504 /50x.html; location = /50x.html { root html;

}

}

}

关于nginx和tomcat的配置的基本配置不再说明,大家可以去看官方文档。

我们可以看到我在upstream 指令中配置了两台server,每台server都设置了max_fails和fail_timeout值。

现在开始启动nginx,然后启动后台的2台server, 故意把在Tomcat Listener中Sleep 10分钟,也就是tomcat启动要花费10分钟左右,端口已开,但是没有接收请求,然后我们访问 (response这个接口是我在tomcat中写的一个servlet接口,功能很简单,如果是9090的server接收请求则返回9090,如果是9191端口的server则返回9191.),现在观察nginx的表现。

我们查看nginx中

access.log

192.168.42.254 - - [29/Dec/2014:11:24:23 +0800] "GET /response/ HTTP/1.1" 504 537 720 380 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 2.004 host:health.iflytek.com192.168.42.254 - - [29/Dec/2014:11:24:24 +0800] "GET /favicon.ico HTTP/1.1" 502 537 715 311 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 0.000 host:health.iflytek.com

error.log

2014/12/29 11:24:22 [error] 6318#0: *4785892017 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.42.254, server: health.iflytek.com, request: "GET /response/ HTTP/1.1", upstream: "", host: "health.iflytek.com"2014/12/29 11:24:23 [error] 6318#0: *4785892017 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.42.254, server: health.iflytek.com, request: "GET /response/ HTTP/1.1", upstream: "", host: "health.iflytek.com"2014/12/29 11:24:24 [error] 6318#0: *4785892017 no live upstreams while connecting to upstream, client: 192.168.42.254, server: health.iflytek.com, request: "GET /favicon.ico HTTP/1.1", upstream: "", host: "health.iflytek.com"

(为什么要在listener中设置睡眠10分钟,这是因为我们的业务中需要做缓存预热,所以这10分钟就是模拟服务器启动过程中有10分钟的不可用。)

观察日志发现在两台tomcat启动过程中,发送一次请求,nginx会自动帮我们进行重试所有的后端服务器,最后会报 no live upstreams while connecting to upstream错误。这也算是nginx做health_check的一种方式。这里需要特别强调一点,我们设置了proxy_read_timeout 为 1秒。后面再重点讲解这个参数,很重要。

等待40s,现在把9090这台服务器启动完成,但是9191这台服务器仍然是正在启动,观察nginx日志表现。

access.log

192.168.42.254 - - [29/Dec/2014:11:54:18 +0800] "GET /response/ HTTP/1.1" 200 19 194 423 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 0.210 host:health.iflytek.com192.168.42.254 - - [29/Dec/2014:11:54:18 +0800] "GET /favicon.ico HTTP/1.1" 404 453 674 311 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 0.212 host:health.iflytek.com

error.log

没有打印任何错误

浏览器返回9090,说明nginx正常接收请求。

我们再次请求一次。

access.log

192.168.42.254 - - [29/Dec/2014:13:43:13 +0800] "GET /response/ HTTP/1.1" 200 19 194 423 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36" 1.005 host:health.iflytek.com

说明正常返回,同时返回9090

error.log

2014/12/29 13:43:13 [error] 6323#0: *4801368618 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.42.254, server: health.iflytek.com, request: "GET /response/ HTTP/1.1", upstream: "", host: "health.iflytek.com"

发现nginx error.log 增加了一行upstream time out的错误。但是客户端仍然正常返回,upstream默认是轮训的负载,所以这个请求默认会转发到9191这台机器,但是因为9191正在启动,所以这次请求失败,然后有nginx重试转发到9090机器上面。

OK,但是fail_timeout=40s是什么意思呢?我们要不要重现一下这个参数的重要性?Let's go !

现在你只需要静静的做个美男子,等待9191机器启动完毕!多发送几次请求!然后咦,你发现9191机器返回9191响应了噢!fail_timeout=40s其实就是如果上次请求发现9191无法正常返回,那么有40s的时间该server会不可用,但是一旦超过40s请求也会再次转发到该server上的,不管该server到底有没有真正的恢复。所以可见nginx社区版的health_check机制有多么的薄弱啊,也就是一个延时屏蔽而已,如此周而复始!如果你用过nginx plus其实你会发现nginx plus 提供的health_check机制更加强大,说几个关键词,你们自己去查! zone slow_start health_check match ! 这个slow_start其实就很好的解决了缓存预热的问题,比如nginx发现一台机器重启了,那么会等待slow_starts设定的时间才会再次发送请求到该服务器上,这就给缓存预热提供了时间。

nginx udp 怎么健康检查

,Nginx比Haproxy的优势还在于Nginx能够提供HTTP/HTTPS服务,可以处理静态资源,或者把一些其他请求交给其他语言来处理,

比如可以把一些输出HTML页面的请求fastcgi_pass给PHP-FPM处理,总而言之,Nginx更像是在做一个可扩展的Web开发系统.另外,Nginx已经支持WebSocket反向代理,而移动浏览器对HTTP上的全双工通信WebSocket的支持还是不错的,只是还没有足够成熟.

nginx 是怎么对 后端服务器 做健康检查的

apache 相对于nginx 的优点:

rewrite ,比nginx 的rewrite 强大动态页面,nginx处理动态请求是鸡肋,一般动态请求要apache去做,nginx只适合静态和反向。

模块超多,基本想到的都可以找到少bug ,nginx 的bug 相对较多超稳定!

nginx不支持url检测是什么意思

主要是针对后端的RealServer服务器的健康检查来讲,nginx只能通过端口的方式来检测后端服务器的状态,而不能通过URL地址来检测后端服务器的状态。

发表评论

评论列表

  • 弦久望笑(2022-06-09 18:28:38)回复取消回复

    是权重,可以根据机器配置定义权重(如果某台服务器的硬件配置十分好,可以处理更多的请求,那么可以 为其设置一个比较高的weight;而有一台的服务器的硬件配置比较差,那么可以将前一台的weight配置为weight=2,后一台差

  • 断渊瑰颈(2022-06-09 13:12:49)回复取消回复

    加浏览器本地缓存的 Header 头。(9)稳定性高:用于反向代理,宕机的概率微乎其微。三、构建实战:Nginx+IIS构筑Web服务器集群的负载均衡这里我们主要在Windows环境