当我们打开手机访问点评客户端的时候，访问商户的请求是如何到达对应某台应用服务器的？
当有很多XX宽带的用户投诉说我大点评某某域名无法打开但是我们却找不出任何问题的时候，我们就想到会不会是宽带运营商的问题。
今天与大家分享的话题，主要是跟我们的软负载集群和Nginx这个强大的开源应用有关系。
当我们准备上线一个新的业务，或者新的功能时候，除了把代码发布的线上生产环境的应用服务器外，还需要做什么工作才能让我们的资深吃货的用户们可以访问到我们高端大气上档次的服务呢？
用户是不可能直接跑到我们的IDC机房插根网线就来访问我们的内部服务器的，我们答应，电信管理IDC的怪叔叔们也不会答应啊。
首先，我们很清楚用户是通过dianping.com的域名来访问我们的站点，同时通过我们对外开放的url链接来访问一些新站点或者新功能的页面。然后，用户访问的域名会通过DNS服务被替换为我们对外的IP地址，这样才能被网络设备识别，然后将用户的请求按照一个一个网络包发给我们的网络设备，最后网络设备收到这些网络数据包后，会将这些数据整理后转化为应用程序可以理解的数据。
数据到了我们的核心网络设备被转换为应用层的数据后，是如何到我们具体某一台应用服务器来处理呢，这就牵涉到我们要讲的负载均衡器了。负载均衡器如果是硬件设备的话，那就是我们经常提到的负载均衡设备，如果是linux服务器上运行的负载均衡软件，那就是软负载了，如果是集群而不是单机的话，那就是传说中的负载均衡集群了。
如下图是我们 线上生产环境的用户请求走向图：
当一个吃货通过浏览器或手机APP访问我们网站的时候，无论是访问商户，添加点评，购买团购，还是在社区通过私信功能与妹子聊天，所有请求都会经过我们的F5负载均衡设备按照设定的转发策略（随机，权重，最小连接等）转发到特定的某台应用服务器来处理，然后再将处理结果返回给用户。
好吧，当我们说了这个硬件设备时候，是不是要谈谈以软件实现的负载均衡功能呢，其实目前在我们PPE环境（xx机房，以后的双IDC运行后另一个生产环境）运行着这样一套软负载集群来处理用户的请求（当然，现在都是伪造的用户请求）。
网络设备和Nginx负载均衡集群中间的F5作为流量管理设备，做4层（连接层，tcp）流量分发。
软负载实质上是一组nginx集群以及允许用户管理nginx配置文件的一个web端。
Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器，也是一个 IMAP/POP3/SMTP 代理服务器。 Nginx因稳定性、丰富的功能集和低系统资源的消耗而闻名。
从中我们可以看出，nginx至少可以做web服务器，同时可以做反向代理服务器，同时又可以做邮件代理服务器，功能还是非常丰富的，稍后我们会对nginx的功能模块做简要的介绍。
作为web服务器，nginx由于自身的优势，在处理静态文件上有着绝对的优势，所以也是天然的优秀web服务器软件。
什么是反向代理服务器，和我们平时说的用代理服务器上国外网站又有什么区别？
有图有真相，看图说话
代理服务器呢，就是当我想访问某个网站的时候因为各种原因不能直接访问，我可以主动或者被动用一台可以访问目标站点的服务器做代理去访问我想要访问的站点。
当我主动去找代理服务器去访问是一种情况，还有一种比较悲催的情况，当我们使用了某些无良宽带运营商提供的物美价廉，缩水严重，还不断搞各种潜规则的宽带时候，就会碰到我们这些吃货去访问点评网站的时候，首先是去访问宽带运营商局域网的代理服务器，然后代理服务器去访问点评的网站。这样做对于宽带运营商来说，可以缓存一些数据，这样就能节省点带宽，但是对于我们这些使用宽带的用户而言，一则数据不安全，运营商的代理服务器上可能有我们的艳照也说不定，二则，当点评站点可正常访问，宽带运营商代理服务器出现问题的时候，就会收到各种用户投诉，点评又跪了，这让吃货怎么活？问题是点评活的好好的，用户却访问不到。
反向代理（Reverse Proxy）是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。
反向代理服务器可以看下面图，nginx就是反向代理的角色，用户的请求是先发到nginx，然后转发到后端的tomcat。
当然，代理服务器和反向代理服务器的类型不只web服务一种。
如下是一个简单的反向代理的配置：
<>server_name qunying.dianping.com;
<>location / {
<>proxy_pass test.qunying.liu.dianping.com; //反向代理站。
<>index index.html index.htm;
<>}
当用户访问qunying.dianping.com/helloword.jsp的时候，这台服务器上的nginx就会将用户的请求转发到qunying.liu.dianping.com/helloword.jsp,当然proxy_pass转向的地址也可以是内部地址，比如127.0.0.1：8080
当然对于我们线上的环境，nginx不是作为典型的反向代理在使用，目前点评java相关web业务服务器上采用的是 nginx （缓存和压缩，日志）+tomcat（java容器），充分利用了nginx低系统占用以及高并发处理的优势。
很多人会有疑问，tomcat也可以做web容器的啊，改个端口不就可以直接给用户提供服务了，而且tomcat也能记录日志，没必要再放一个nginx啊。
tomcat 前面有没有必要放一个nginx呢？
术业有专攻，tomcat做web服务器是兼职，做java容器是专职。nginx服务器是专职做web服务器，支持高并发，响应快，擅长处理静态内容，而且可以把动态内容交给tomcat处理。用tomcat做web容器响应用户请求，有可能1分钟只能处理10个请求，但是用nginx+tomcat一分钟就可能可以处理100个请求。
nginx为什么可以这么快处理用户的请求呢？
nginx的进程模型以及系统事件机制
nginx启动后的进程，如图所示：
我们可以看到master进程，是以root身份启动，执行内容为：/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
worker进程都是以我们指定的nobody身份运行，其中有一个worker进程是旧的worker进程奔溃后，自动重新创建的，你能找到他吗？
nginx在启动后，会有一个master进程和多个worker进程。master进程主要用来管理worker进程，包含：接收来自外界的信号，向各个worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。基本的网络事件，则是放在worker进程中来处理了。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致。
我们要控制nginx，只需要通过kill向master进程发送信号就行了。比如kill -HUP pid，则是告诉nginx，从容地重启nginx，我们一般用这个信号来重启nginx，或重新加载配置，因为是从容地重启，因此服务是不中断的。master进程在接收到HUP信号后是怎么做的呢？首先master进程在接到信号后，会先重新加载配置文件，然后再启动新的进程，并向所有老的进程发送信号，告诉他们可以光荣退休了。新的进程在启动后，就开始接收新的请求，而老的进程在收到来自master的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出。当然，直接给master进程发送信号，这是比较老的操作方式，nginx在0.8版本之后，引入了一系列命令行参数，来方便我们管理。比如，./nginx -s reload，就是来重启nginx，./nginx -s stop，就是来停止nginx的运行。如何做到的呢？我们还是拿reload来说，我们看到，执行命令时，我们是启动一个新的nginx进程，而新的nginx进程在解析到reload参数后，就知道我们的目的是控制nginx来重新加载配置文件了，它会向master进程发送信号，然后接下来的动作，就和我们直接向master进程发送信号一样了。
