我的架构梦：（十九）Nginx搭建、反向代理、负载均衡、动静分离以及底层进程机制详解

一、前言

1、什么是Nginx?

Nginx 是一个高性能的HTTP和反向代理web服务器，核心特点是占有内存少，并发能力强。

2、Nginx的应用场景

• Http服务器(Web服务器)

  性能非常高，非常注重效率，能够经受高负载的考验。
  支持50000个并发连接数，不仅如此，CPU和内存的占用也非常的低，10000个没有活动的连 接才占用2.5M的内存。

• 反向代理服务器

  正向代理
  在浏览器中配置代理服务器的相关信息，通过代理服务器访问目标网站，代理服务器收到目标网站的响应之后，会把响应信息返回给我们自己的浏览器客户端。

  反向代理
  浏览器客户端发送请求到反向代理服务器(比如Nginx)，由反向代理服务器选择原始服务器提供服务获取结果响应，最终再返回给客户端浏览器。

• 负载均衡服务器

  负载均衡，当一个请求到来的时候(结合上图)，Nginx反向代理服务器根据请求去找到一个 原始服务器来处理当前请求，那么这叫做反向代理。那么，如果目标服务器有多台，找哪一个目标服务器来处理当前请求呢，这样一 个寻找确定的过程就叫做负载均衡。

  生活中也有很多这样的例子，比如，我们去银行，可以处理业务的窗口有多个，那么我们会 被分配到哪个窗口呢到底，这样的一个过程就叫做负载均衡。

  负载均衡就是为了解决高负载的问题。

• 动静分离

3、Nginx的特点

• 跨平台:Nginx可以在大多数类unix操作系统上编译运行，而且也有windows版本。
• Nginx的上手非常容易，配置也比较简单。
• 高并发，性能好。
• 稳定性也特别好，宕机概率很低。

二、Nginx搭建

1、安装Nginx依赖，pcre、openssl、gcc、zlib(推荐使用yum源自动安装)

yum -y install gcc zlib zlib-devel pcre-devel openssl openssl-devel

2、下载Nginx

wget http://nginx.org/download/nginx-1.17.8.tar.gz

3、解包Nginx软件包

tar -zxvf nginx-1.17.8.tar.gz

4、进入解压之后的目录 nginx-1.17.8

cd nginx-1.17.8

5、命令行执行./configure

6、make

7、命令行执行 make install，完毕之后在/usr/local/下会产生一个nginx目录

8、进入sbin目录中，执行启动nginx命令

cd nginx/sbin 
./nginx

9、然后访问服务器的80端口(nginx默认监听80端口)

10、访问自己的云服务器不成功的话

阿里云服务器需要设置安全组规则，配置下面的http规则就行了。

11、Nginx主要命令

• ./nginx 启动nginx
• ./nginx -s stop 终止nginx(当然也可以找到nginx进程号，然后使用kill -9 杀掉nginx进程)
• ./nginx -s reload (重新加载nginx.conf配置文件)

三、Nginx核心配置文件解读

Nginx的核心配置文件conf/nginx.conf包含三块内容:全局块、events块、http块

1、全局块

从配置文件开始到events块之间的内容，此处的配置影响nginx服务器整体的运行，比如worker进程的数量、错误日志的位置等。

2、events块

events块主要影响nginx服务器与用户的网络连接，比如worker_connections 1024，标识每个
workderprocess支持的最大连接数为1024。

3、http块

http块是配置最频繁的部分，虚拟主机的配置，监听端口的配置，请求转发、反向代理、负载均衡等。

四、Nginx应用场景之反向代理

1、反向代理需求一

浏览器请求nginx（http://47.113.82.141:9003），nginx将请求转发给了目标服务器，我们看到的是目标服务器的响应页面。在整个过程中，目标服务器相当于对客户端是不可见的，服务端向外暴露的就是nginx的地址。

• 部署tomcat，保持默认监听8080端口
• 修改nginx配置
• 重新加载nginx配置
  ./nginx -s reload
• 测试，访问http://47.113.82.141:9003,返回tomcat的⻚面

2、反向代理需求二

在需求一的基础上，目标服务器有两个，分别是127.0.0.1:8080、127.0.0.1:8081。
当访问http://47.113.82.141/9003/abc的时候，实际访问目标服务器127.0.0.1:8080；
当访问http://47.113.82.141/9003/def的时候，实际访问目标服务器127.0.0.1:8081。

• 再部署一台tomcat，保持默认监听8081端口

• 修改nginx配置，并重新加载

• 里主要就是多location的使用，这里的nginx中server/location就好比tomcat中的Host/Context

  location 语法如下:
  location [=|~|~*|^~] /uri/ { ... }

在nginx配置文件中，location主要有这几种形式:

• 正则匹配 location ~ /riemann { }
• 不区分大小写的正则匹配 location ~* /riemann { }
• 匹配路径的前缀 location ^~ /riemann { }
• 精确匹配 location = /riemann { }
• 普通路径前缀匹配 location /riemann { }

优先级 4>3>2>1>5

五、Nginx应用场景之负载均衡

负载均衡需求：

新增一个tomcat监听8082端口，当访问http://47.113.82.141/9003/abc，使用Nginx作为负载均衡器，将请求分配到127.0.0.1:8080、127.0.0.1:8082。

1、轮询

默认策略，每个请求按时间顺序逐一分配到不同的服务器，如果某一个服务器下线，能自动剔除。

upstream riemannServer{
	server 47.113.82.141:8080; 
	server 47.113.82.141:8082;
}
location /abc {
	proxy_pass http://riemannServer/;
}

2、weight

weight代表权重，默认每一个负载的服务器都为1，权重越高那么被分配的请求越多(用于服务器
性能不均衡的场景)

upstream riemannServer{
	server 47.113.82.141:8080 weight=1; 
	server 47.113.82.141:8082 weight=2;
}

3、ip_hash

每个请求按照ip的hash结果分配，每一个客户端的请求会固定分配到同一个目标服务器处理，可
以解决session问题。

upstream riemannServer{ 
	ip_hash;
	server 47.113.82.141:8080;
	server 47.113.82.141:8082; 
}

六、Nginx应用场景之动静分离

动静分离就是讲动态资源和静态资源的请求处理分配到不同的服务器上，比较经典的组合就是 Nginx+Tomcat架构(Nginx处理静态资源请求，Tomcat处理动态资源请求)，那么其实之前的讲解 中，Nginx反向代理目标服务器Tomcat，我们能看到目标服务器ROOT项目的index.jsp，这本身就是 Tomcat在处理动态资源请求了。

所以，我们只需要配置静态资源访问即可。

动静分离需求

主要是静态资源的访问，因为我们之前Nginx反向代理到Tomcat能够看到Tomcat ROOT项目的index.jsp页面，这本身就是一个动态资源的请求过程。

我们希望在Nginx服务器上部署静态资源，然后浏览器请求http://47.113.82.141/9003/static/abc.html,Nginx直接读取的本地静态资源。

Nginx配置

七、Nginx底层进程机制剖析

Nginx启动后，以daemon多进程方式在后台运行，包括一个Master进程和多个Worker进程，Master
进程是领导，是老大，Worker进程是干活的小弟。

• master进程

  主要是管理worker进程，比如:
  接收外界信号向各worker进程发送信号(./nginx -s reload)
  监控worker进程的运行状态，当worker进程异常退出后Master进程会自动重新启动新的 worker进程等

• worker进程

  worker进程具体处理网络请求。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程， 不可能处理其它进程的请求。worker进程的个数是可以设置的，一般设置与机器cpu核数一致。

1、Nginx进程模型示意图如下

2、以 ./nginx -s reload 来说明nginx信号处理这部分

• master进程对配置文件进行语法检查
• 尝试配置(比如修改了监听端口，那就尝试分配新的监听端口)
• 尝试成功则使用新的配置，新建worker进程
• 新建成功，给旧的worker进程发送关闭消息
• 旧的worker进程收到信号会继续服务，直到把当前进程接收到的请求处理完毕后关闭

所以reload之后worker进程pid是发生了变化的

3、worker进程处理请求部分的说明

例如，我们监听9003端口，一个请求到来时，如果有多个worker进程，那么每个worker进程都有
可能处理这个链接。

• master进程创建之后，会建立好需要监听的的socket，然后从master进程再fork出多个
  worker进程。所以，所有worker进程的监听描述符listened在新连接到来时都变得可读。
• nginx使用互斥锁来保证只有一个worker进程能够处理请求，拿到互斥锁的那个进程注册 listenfd读事件，在读事件里调用accept接受该连接，然后解析、处理、返回客户端。

4、nginx多进程模型好处

• 每个worker进程都是独立的，不需要加锁，节省开销
• 每个worker进程都是独立的，互不影响，一个异常结束，其他的照样能提供服务
• 多进程模型为reload热部署机制提供了支撑