运维手册 Nginx代理服务的常见问题有哪些 nginx 代理服务器

1.什么是nginx？

Nginx （engine x） 是一个高性能的Web服务器和反向代理服务器，Nginx 特点是占有内存少，并发处理能力强，以高性能、低系统资源消耗而闻名，Nginx官方测试为5万并发请求。
Nginx 的并发处理能力在同类型的Web服务器中表现极好（Apache、Lighttpd），在全世界范围内大量的网站使用了Nginx，国内互联网中也大量使用了Nginx，比如：淘宝、新浪、搜狐、网易、美团等。
Nginx是免费开源的，同时Nginx也有收费的商业版本，商业版本提供了性能优化、宕机等紧急问题处理等技术支持和服务。

1.正向代理

正向代理类似一个跳板机，代理访问外部资源。比如：我是一个用户，我访问不了某网站，但是我能访问一个代理服务器，这个代理服务器，它能访问那个我不能访问的网站，于是我先连上代理服务器，告诉它我需要那个无法访问网站的内容，代理服务器去取回来,然后返回给我。

正向代理举例

比如你现在缺钱，想找马云爸爸去借钱，可想而知人家可能鸟都不鸟你，到最后碰一鼻子灰借不到钱。不过你认识你家隔壁老王，而老王认识马云同志，而且关系还很好。这时候你托老王去找马云借钱，当然这事最后成了，你从马云那里借到了500万！这时候马云并不知道钱是你借的，只知道这钱是老王借的。最后由老王把钱转交给你。在这里，老王就充当了一个重要的角色：代理。

2.反向代理

反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。
而nginx就是一个反向代理器：当用户发送请求，nginx会接收请求但是不会去处理，而是利用自身的负载均衡机制将请求合理的分配到处理请求的服务器(比如tomcat)，然后tomcat服务器处理请求，将结果返回给nginx，nginx就会把返回结果给用户。

反向代理举例

比如你现在很无聊，想找人聊天，这时候你拨通了联通客服10010电话，联通的总机可能随机给你分配一个闲置的客服给你接通。这时候你如愿以偿的和客服聊了起来，问了问她目前有没有结婚、有没有对象、家住哪里、她的微信号、她的手机号。。。
此时联通总机充当的角色就是反向代理，你只知道和客服接通并聊了起来，具体为什么会接通这个客服MM，怎么接通的，你并不知道。
反向代理隐藏了真正的服务端，就像你每天使用百度的时候，只知道敲打www.baidu.com就可以打开百度搜索页面，但背后成千上万台百度服务器具体是哪一台为我们服务的，我们并不知道。我们只知道这个代理服务器，它会把我们的请求转发到真实为我们服务的那台服务器那里去。

综上所述：正向代理代理对象是客户端，反向代理代理对象是服务端。

软件层面一般常用Nginx来做反向代理服务器，它的性能非常好，用来做负载均衡。

2.Nginx环境搭建

2.1下载

免费开源版的官方网站：http://nginx.org
Nginx 有 Windows 版本和 Linux 版本，但更推荐在 Linux 下使用 Nginx；
下载nginx-1.14.2.tar.gz的源代码文件：wget http://nginx.org/download/nginx-1.14.2.tar.gz
我的习惯，将下载或者上传的安装文件放到/opt/softwares目录下

2.2安装(Linux系统)

安装前的准备

Nginx的安装需要确定Linux安装相关的几个库，否则配置和编译会出现错误， 具体的检查安装过程为：这里我们为了方便 ：
使用下面的命令一次性将安装所需要的库文件 全部下载下来

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

2.3正式安装

• 1.解压下载下来的nginx文件，执行命令：tar -zxvf nginx-1.14.2.tar.gz
• 2.切换至解压后的nginx主目录，执行命令：cd nginx-1.14.2
• 3.在nginx主目录nginx-1.14.2下执行命令：./configure --prefix=/usr/local/nginx （其中–prefix是指定nginx安装路径） 注意:等号左右不要有空格
• 4.执行命令进行编译：make
• 5.执行命令进行安装：make install

安装成功后，可以切换到/usr/local/nginx目录下，查看内容

2.4启动

第一种启动方式—普通启动

切换到nginx安装目录的sbin目录下，执行：./nginx

第二种启动方式—配置文件启动

任意目录下：输入命令

/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf

其中-c是指定配置文件,而且配置文件路径必须指定绝对路径

检查Nginx是否启动

输入命令：ps -ef | grep nginx

nginx 体系结构由 master 进程和其 worker 进程组成

master 进程读取配置文件，并维护 worker 进程，而 worker 进程则对请求进行实际处理

Nginx启动后，安装目录下会出现一些_tmp结尾的文件，这些是临时文件，不用管。

在浏览器中输入http://192.168.235.128:80/访问Nginx服务器，出现以下界面：

2.5关闭nginx

第一种关闭—优雅的关闭

找出nginx的进程号：ps -ef | grep nginx
执行命令：kill -QUIT 主pid

1. 其中pid是主进程号的pid（master process），其他为子进程pid（worker process）
2. 这种关闭方式会处理完请求后再关闭，所以称之为优雅的关闭
   弊端就是：要一直等待处理完所有的请求才会关闭，如果有的请求需要时间很长，我们就需要一直等待，才能关闭。

第二种关闭—快速的关闭

找出nginx的进程号：ps -ef | grep nginx
kill -TERM 主pid
注意：

1. 其中pid是主进程号的pid（master process），其他为子进程pid（worker process）
2. 这种关闭方式不管请求是否处理完成，直接关闭，比较暴力，称之为快速的关闭

重启Nginx

当我们修改了配置文件之后，我们需要重新启动nginx：

./nginx -s reload

或者我们只启动了一个nginx的情况，我们可以使用/usr/local/nginx/sbin/nginx -s reload

2.6检查配置是否正确

当修改Nginx配置文件后，可以使用Nginx命令进行配置文件语法检查，用于检查Nginx配置文件是否正确：

/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf -t

如果配置没有错误，就会出现下面的successful

2.7查看Nginx的版本

Linux上查看nginx版本：/usr/local/nginx/sbin/nginx -V -v （小写的v）显示 nginx 的版本
-V （大写的V）显示 nginx 的版本、编译器版本和配置参数

3.Nginx配置文件说明及Nginx主要应用

3.1Nginx的核心配置文件

学习Nginx首先需要对它的核心配置文件有一定的认识，这个文件位于Nginx的安装目录/usr/local/nginx/conf目录下，名字为nginx.conf
Nginx的核心配置文件主要由三个部分构成:

3.1.1基本配置 #为注释

#配置worker进程运行用户，nobady也是一个Linux用户，一般用于启动程序，无密码
user nobody ；
#配置工作进程worker数目，根据硬件调整，同城等于CPU数量或者2倍于CPU数量
worker_processes 1；
#配置全局错误日志及类型，[ denug | info | notice | warn | error | crit ]，默认是error
error_log logs/error.log；
#error_log logs/error.log notice；
#error_log logs/error.log info；

pid logs/nginx.pid; #配置进程pid文件

3.1.2events配置

#配置工作模式和连接数
events {
worker_connections 1024; #配置每个worker进程连接数上限
#nginx支持的总连接数就等于worker_processes * worker_connections
}

3.1.3http配置

#配置http服务器,利用它的反向代理功能提供负载均衡支持
http {
#配置nginx支持哪些多媒体类型，可以在conf/mime.types查看支持哪些多媒体类型
include mime.types;
#默认文件类型 流类型，可以理解为支持任意类型
default_type application/octet-stream;
#配置日志格式
#log_format main ’ ’

#配置access.log日志及存放路径，并使用上面定义的main日志格式
#access_log logs/access.log main;

sendfile on; #开启高效文件传输模式
#tcp_nopush on; #防止网络阻塞

#keepalive_timeout 0;
keepalive_timeout 65; #长连接超时时间，单位是秒

#gzip on; #开启gzip压缩输出

server配置，可以有多个

#配置虚拟主机
server {
listen 80; #配置监听端口
server_name localhost; #配置服务名
#charset koi8-r; #配置字符集
#access_log logs/host.access.log main; #配置本虚拟主机的访问日志
#默认的匹配斜杠/的请求，当访问路径中有斜杠/，会被该location匹配到并进行处理

location / {
#root是配置服务器的默认网站根目录位置，默认为nginx安装主目录下的html目录
root html;
#配置首页文件的名称
index index.html index.htm;
}

#error_page 404 /404.html; #配置404页面
# redirect server error pages to the static page /50x.html
#error_page 500 502 503 504 /50x.html; #配置50x错误页面

#精确匹配
location = /50x.html {
root html;

4.Nginx主要应用

4.1静态网站部署

Nginx是一个HTTP的web服务器，可以将服务器上的静态文件（如HTML、图片等）通过HTTP协议返回给浏览器客户端

4.1.1案例：将ace-master这个静态网站部署到Nginx服务器上

1，通过Xftp将ace-master到linux服务器/opt/static目录下，为了演示方便，将名字改为ace

2，修改nginx.conf配置文件

在server中，通过location匹配访问的路径，然后转发给静态资源

我这里的静态资源是一个网站的登录界面 静态资源的根路径的位置在/opt/static/ace下

3，重启nginx服务器(每修改一次nginx.conf配置，我们都需要重启一下服务器

)

4，在浏览器中输入http://ip/ace进行访问 出现登录界面 静态网站部署成功

注意：location中配置路径讲解

我们可能会遇见404找不到页面的错误，主要还是配置路径的问题：
规则：ip + port 或ip等于 root，假设server的配置如下：
server {
listen 80; #端口号
location / {
root /opt/static /ace; #静态文件路径
}
}

上面就等于：http://192.168.92.128:80/ = root = /opt/static/ace
最后结果就是访问到http://192.168.92.128:80/opt/static/ace

如果设置为：
location / ace{
root /opt/static/ace; #静态文件路径
}
上面就等于：http://192.168.92.128:80/ = root = /opt/static/ace/ace
这样就会出现404的错误
所以我们这样改：
ocation / ace{
root /opt/static; #静态文件路径
}

上面就等于：http://192.168.92.128:80/ = root = /opt/static/ace
成功访问到：http://192.168.92.128:80/ opt/static/ace下的静态资源

4.2负载均衡

4.2.1概述

在网站创立初期，我们一般都使用单台机器对外提供集中式服务。随着业务量的增大，我们一台服务器不够用，此时就会把多台机器组成一个集群对外提供服务，但是，我们网站对外提供的访问入口通常只有一个，比如 www.web.com。那么当用户在浏览器输入www.web.com进行访问的时候，如何将用户的请求分发到集群中不同的机器上呢，这就是负载均衡要做的事情。

负载均衡通常是指将请求"均匀"分摊到集群中多个服务器节点上执行，这里的均匀是指在一个比较大的统计范围内是基本均匀的，并不是完全均匀。

这就是nginx自有的功能，通过负载均衡的方式来分配请求给tomcat服务器，以求达到均匀的目的。

4.2.2负载均衡实现方式

1.硬件负载均衡
比如 F5、深信服、Array 等
优点是有厂商专业的技术服务团队提供支持，性能稳定
缺点是费用昂贵，对于规模较小的网络应用成本太高

2.软件负载均衡
比如 Nginx、LVS、HAProxy 等
优点是免费开源，成本低廉

4.2.2.1Nginx负载均衡

Nginx通过在nginx.conf文件进行配置即可实现负载均衡

启动tamoct，我有两个tomact，8.5 和 9.0，现在分别在其bin目录下启动 ./startup.sh 8.5的 端口是8080 ---------------9.0端口是8007

myweb是我们放入两个tomact里面webapps下面的war项目包。

浏览器输入192.168.64.128：8007/myweb 启动项目 测试

浏览器输入192.168.64.128：8080/myweb 启动项目 测试

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

现在我们配置nginx配置文件 用nginx来分配那个tomact来执行请求

在http模块加上upstream配置，在server模块里添加location，并配置proxy_pass

其中 www.zymyweb.com中的zymyweb可以写为任意的都可以 只要保持和上面的upstearm一致就可以了

访问：192.168.64.128/myweb

nginx默认就是轮询模式，即发送请求，会交替的给我的8.5和9.0的tomcat服务器。

轮询：如果两台机器性能不一致 还是不要使用轮询的方式

Nginx常用负载均衡策略

1.轮询（默认）
upstream backserver {
server 127.0.0.1:8080;
server 127.0.0.1:9090;
}
++++++++++++++++++++++++++++++++++++++++++++++++++++++
2.权重
每个请求按一定比例分发到不同的后端服务器，weight值越大访问的比例越大，用于后端服务器性能不均的情况
upstream backserver {
server 192.168.0.14 weight=5;
server 192.168.0.15 weight=2;
}
也就是说 0.14这个机器处理5个请求的时间 和 0.15这个机器处理2个请求的时间是一致的 也就是说 0.14这个机器的性能更好。
但是并不是说 我先连续给14发5个请求 然后给15发两个
而是这样的 比如说有7个请求 会先给14机器2个请求 然后给15机器1个，再然后给14机器两个 再给15一个 再给14机器一个 最终还是14机器处理5个 15机器处理2个。

++++++++++++++++++++++++++++++++++++++++++++++++++++++

3.最少连接

web请求会被转发到连接数最少的服务器上

upstream backserver {

least_conn;

server 127.0.0.1:8080;

server 127.0.0.1:9090;

}

++++++++++++++++++++++++++++++++++++++++++++++++++++++

4.ip_hash

ip_hash也叫IP绑定，每个请求按访问ip的hash值分配，这样每个访问客户端会固定访问一个后端服务器，可以解决会话Session丢失的问题。(这样有一个缺陷就是 当我们从一个地方到另外一个地方 IP就会发生变化 )

算法：hash(“124.207.55.82”) % 2 = 0, 1

upstream backserver {

ip_hash;

server 127.0.0.1:8080;

server 127.0.0.1:9090;

}

但是也有弊端

虽然每个ip的哈希值不同 但是哈希值取模后的值可能是一样的 所以 这种情况会导致一直在一个Tomact上面处理请求

backup服务器 (备用)

upstream backserver {

server 127.0.0.1:9100;

#其它所有的非backup机器down的时候，才请求backup机器

server 127.0.0.1:9200 backup;

}

Backup 备份服务器(tomact)

比如 现在有四个普通的服务器 一个 备份服务器
现在要进行更新代码：
普通1 普通2 普通3普通4 备份
现在先给备份服务器进行更新服务 然后我们停掉普通1和2 对1和2也进行更新代码 更新完毕之后 现在对普通 3和4进行更新，对3和4 进行更新的时候，我们需要先停止3和4 服务器，(在停止3和4 的同时，我们尝试启动1和2 ，就在启动1和2的时候，四个服务器都是宕机状态)此时 1 2 3 4都停止了，就这一小会时间，备份服务器进行启动，然后紧接启动更新好1和2 然后就备份 服务器 就自动关掉了 (所以说 请求量并不会使得备份 负荷 一方面更新都在晚上 访问量小 另一方面 并不是同时停止普通的服务器 是先停止一部分 )

down服务器 (宕机)

upstream backserver {
server 127.0.0.1:9100;
#down表示当前的server是down状态，不参与负载均衡
server 127.0.0.1:9200 down;
}
Down就相当于宕机状态 不参与 负载均衡 不处理请求

4.3静态代理

把所有静态资源的访问改为访问nginx，而不是访问tomcat，这种方式叫静态代理。因为nginx更擅长于静态资源的处理，性能更好，效率更高。
所以在实际应用中，我们将静态资源比如图片、css、html、js等交给nginx处理，而不是由tomcat处理。

我们选择nginx处理静态资源 是因为 它的处理能力比tomact好 是可选的 也可以使用tomact 。

4.3.1Nginx静态代理实现方式

有两种 但是我只写一种，因为另一种不常用，用起来很麻烦。

实现方式：在nginx.conf的location中配置静态资源所在目录实现

例如：当访问静态资源，则从linux服务器/opt/static目录下获取（举例）
location ~ .*/(css|js|img|images) {
root /opt/static;
}
xxx/css
xxx/js
xxx/img
xxx/images
~ 表示正则匹配，也就是说后面的内容可以是正则表达式匹配
第一个点 . 表示任意字符
*表示一个或多个字符
. 是转移字符，是后面这个点的转移字符
| 表示或者
$ 表示结尾

我们将静态资源放入 /opt/static 目录下，然后用户访问时由nginx返回这些静态资源。

修改nginx.conf文件，在location中配置对静态资源的拦截，如果是静态资源，就交给nginx处理。

现在我们还是访问myweb项目 只不过我们把8.5和9.0 tomact里面的image静态资源删除，现在就像上面的配置一样 我们还是利用nginx的负载均衡方法 访问项目myweb 那么我们的地址就是 192.168.64.128/myweb

（上面的配置）因为我们访问的是myweb 而根路径是 opt/static下面的 所以我们需要把静态资源放在myweb文件夹里面 这样我们才能访问到 所以我们要在/opt/static下面建立一个文件夹myweb，文件夹myweb里面就是我们利用nginx访问的静态资源。

只能在用负载均衡 也就是用nginx访问 才会出现图片(访问到静态资源)
而直接用tomact访问就不可以出现图片(不能访问到静态资源)。

4.4动静分离

Nginx的负载均衡和静态代理结合在一起，我们可以实现动静分离，这是实际应用中常见的一种场景。

动态资源，如jsp由tomcat或其他web服务器完成

静态资源，如图片、css、js等由nginx服务器完成

它们各司其职，专注于做自己擅长的事情

动静分离充分利用了它们各自的优势，从而达到更高效合理的架构

我们使用动静分离 并不是必须的 只不过是因为nginx处理静态资源 效率高！！！！！！

现在我们需要 3个nginx
整个架构中，一个nginx负责负载均衡，两个nginx负责静态代理。Nginx在一台Linux上安装一个就可以，然后我们通过配置文件不同来启动多个Nginx，每个Nginx。

1.拷贝两份nginx配置文件（静态代理）

nginx81.conf

nginx82.conf

2.接下来配置的是负责负载均衡的nginx

Nginx.conf

上面配置结束后：启动三台nginx服务器，启动两台tomcat服务器
我们可以成功的访问到页面图片

当我们关闭一台放静态资源的nginx服务器的时候 我们能再次访问还是成功的
因为 我们在两个nginx里面放的静态资源是相同的
当我们关掉其中一台tomact的时候 我们访问页面还是成功的 只不过只能是另外一台tomcat来处理请求了

当我们把两个放静态资源的nginx的服务器都关掉的时候 此时 图片不会被加载出来
因为 静态资源存储的服务器都关闭了 我们去哪里访问呢

也即是说 总的nginx只是来分配请求的 负载均衡决定谁先执行 (轮询 最小链接 等)