一、Nginx的安装
关于Nginx的基本概念,在之前的博文中:
有详细的介绍,这篇博文就直接从安装开始谈起。
环境准备:
.
注(实现效果如下):
上面提到的 2 个模块都属于第三方扩展模块,需要提前下好源码(我在前面的下载链接中包含着这几个模块),然后编译时通过--add-moudle=src_path 一起安装。
1、安装Nginx
关于上述的编译选项解释如下:
2、启动Nginx服务
二、Nginx服务实现反向代理
在实现这个反向代理之前,这里还是要说一下,什么是反向代理?什么是正向代理?
1、正向代理
用于代理内部网络对 Internet 的连接请求(如 NAT),客户端指定代理服务器,并将本来要直接发送给目标Web服务器的HTTP请求先发送到代理服务器上, 然后由代理服务器去访问 Web 服务器, 并将 Web 服务器返回的信息的回传给客户端,此时,这个代理服务器就是正向代理。
2、反向代理
与正向代理相反,如果局域网向Internet提供资源,并让Internet上的其他用户可以访问局域网内资源, 也可以设置一个代理服务器, 它提供的服务就是反向代理. 反向代理服务器接受来自 Internet 的连接,然后将请求转发给内部网络上的服务器,并将 web服务器的返回信息回传给
Internet 上请求连接的客户端。
总而言之:正向代理的对象是客户端,代替客户端去访问web服务器;反向代理的对象是web服务器,代理web服务器去回应客户端。
3、Nginx配置反向代理
可以配置 nginx 作为反向代理和负载均衡,同时利用其缓存功能,将静态页面在 nginx 缓存,以达到降低后端服务器连接数的目的并检查后端 web 服务器的健康状况。
环境如下:
开始配置Nginx服务器:
上述web服务器池的配置中有一个“sticky”的配置项,其实就是加载了nginx-sticky模块,这个模块的作用是通过 cookie 黏贴的方式将来自同一个客户端(浏览器)的请求发送到同一个后端服务器上处理,这样一定程度上可以解决多个 backend servers 的会话同步的问题(所谓会话同步,就好比访问页面时,登录一次即可,在一定时间段内无需再次登录,这就是会话的概念),而 RR 轮询模式必须要运维人员自己考虑 session 同步的实现。另外内置的 ip_hash 也可以实现根据客户端 IP 来分发请求,但它很容易造成负载不均衡的情况,而如果 nginx 前面有来自同一局域网的访问,它接收的客户端 IP 是一样的,容易造成负载不均衡现象。nginx-sticky-module 的 cookie 过期时间,默认浏览器关闭就过期。
这个模块并不合适不支持 cookie 或手动禁用了 cookie 的浏览器,此时默认 sticky 就会切换成 RR。它不能与 ip_hash 同时使用。
sticky只是Nginx支持的其中一种调度算法,下面是Nginx的负载均衡模块支持的其他调度算法:
web服务器池中的服务器配置如下(仅供参考,这里为了测试,只是简便的搭建了一下httpd服务):
第二台web服务器进行以上相同的操作即可,只是注意要准备不同的网页文件,以便测试负载均衡的效果。
现在就可以进行客户端访问验证了,但是需要注意的是,nginx代理服务器必须可以和两台wbe服务器进行通信。
在nginx代理服务器上访问自己本身测试(可以看到是在对web服务器池中的web服务器进行轮询):
若使用Windows客户端进行访问测试,由于配置文件中有“sticky”配置,所以会将每次的刷新请求还是转交给同一台web服务器,并无法测试出负载均衡的效果,只需将“sticky”那行注释掉,即可测试出负载均衡的效果。
三、Nginx服务优化
所谓优化,除了控制其工作线程以外,还有几个更重要的概念,也就是缓存及网页压缩,由于其涉及的配置项比较多,我将把完整的http{ }字段的配置文件写到下面,并注释,在博文的末尾会附上一个没有注释的http{ }字段。
在优化之前,我好像在编译安装Nginx时,故意漏掉一个模块没有加载,就是为了展示如果没有加载所需的模块,怎么进行加载?
配置如下:
至此,新的模块就添加完成了。
1、Nginx的proxy缓存使用
缓存也就是将 js、css、image 等静态文件从后端服务器缓存到 nginx 指定的缓存目录下,既可以减轻后端服务器负担,也可以加快访问速度,但这样缓存及时清理成为了一个问题,所以需要 ngx_cache_purge 这个模块来在过期时间未到之前,手动清理缓存。
proxy 模块中常用的指令时 proxy_pass 和 proxy_cache。
nginx 的 web 缓存功能的主要是由 proxy_cache、fastcgi_cache 指令集和相关指令集完成,proxy_cache 指令负责反向代理缓存后端服务器的静态内容,fastcgi_cache 主要用来处理FastCGI 动态进程缓存(生产环境中不建议对动态页面进行缓存)。
配置如下:
客户端访问测试(使用的是谷歌浏览器,访问前按F12):
按“F5”刷新一下:
MISS 表示未命中,请求被传送到后端;HIT 缓存命中(因为第一次访问,Nginx服务器并没有相应网页的缓存,所以会传送到后端web,第二次刷新时,Nginx本地就有缓存了,所以是“HIT”,缓存命中)。
查看Nginx的访问日志,也可以查看到记录的缓存相关信息:
客户端访问以下地址(客户端必须在 location ~/purge(/.*)允许的网段内),可以在缓存失效前,手动清除Nginx服务器上的缓存(若没有成功,先手动清除一下客户端浏览器的缓存):
我这里的图片截错了,不好意思,若需要手动清理缓存的话,如果访问时指定的URL是“192.168.20.5/index.html”,那么在清除缓存时,需要指定的URL就是“192.168.20.5/purge/index.html”,若访问时指定的URL是“192.168.20.5”,那么在手动清除缓存时,需要指定的URL是“ 192.168.20.5/purge/ ”
以上部分配置的相关解释如下:
2、优化Nginx服务的压缩功能
更改配置文件如下(相关解释请参考博文末尾):
验证:
1、访问以下地址,可以查看Nginx服务器的状态统计页:
2、查看GZIP功能是否开启:
3、测试br压缩功能是否开启(需要使用命令行的方式访问):