Nginx在web开发中使用
Nginx实现服务器端集群搭建
Nginx与Tomcat部署
明明直接通过tomcat就能访问,为什么还需要多加一个nginx?
- 第一个使用Nginx实现动静分离
- 第二个使用Nginx搭建Tomcat的集群
Nginx实现动静分离
什么是动静分离?
动:后台应用程序的业务处理
静:网站的静态资源(html,javaScript,css,images等文件)
分离:将两者进行分开部署访问,提供用户进行访问。举例说明就是以后所有和静态资源相关的内容都交给Nginx来部署访问,非静态内容则交个类似于Tomcat的服务器来部署访问。
为什么要动静分离?
- Nginx在处理静态资源的时候,效率是非常高的,而且Nginx的并发访问量也是名列前茅,而Tomcat则相对比较弱一些,所以把静态资源交个Nginx后,可以减轻Tomcat服务器的访问压力并提高静态资源的访问速度
- 动静分离以后,降低了动态资源和静态资源的耦合度。如动态资源宕机了也不影响静态资源的展示
如何实现动静分离?
注意几个点:
将.war项目中的静态资源都删除掉,重新打包生成一个war包
将war包部署到tomcat中,把之前部署的内容删除掉
在Nginx所在服务器创建对应的静态资源位置
在路径选择上,要考虑用户权限。要不就放home目录下,要不就chmod赋权限!!不然浏览器访问易报403 Forbidden.
配置Nginx的静态资源与动态资源的访问
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23upstream webservice{
server 192.168.200.146:8080;
}
server {
listen 80;
server_name 你的ip或域名;
#动态资源
location /demo {
proxy_pass http://webservice;
}
#静态资源
location ~/.*\.(png|jpg|gif|js){
root html/web;
gzip on;
}
location / {
root html/web;
index index.html index.htm;
}
}
Nginx实现Tomcat集群搭建
一台服务器容易宕机,那就多搭建几台Tomcat服务器,这样的话就提升了后的服务器的可用性。这也就是我们常说的集群
Nginx对应的配置文件
1 | upstream webservice{ |
Nginx核心配置文件结构
我们知道Nginx的核心配置文件默认是放在/usr/local/nginx/conf/nginx.conf
修改配置文件前一定要copy一份!!1
1 | worker_processes 1; |
1 | 指令名 指令值; #全局块,主要设置Nginx服务器整体运行的配置指令 |
简单小结下:
nginx.conf配置文件中默认有三大块:全局块、events块、http块
http块中可以配置多个server块,每个server块又可以配置多个location块。
全局块
user指令
(1)user:用于配置运行Nginx服务器的worker进程的用户和用户组。
语法 | user user [group] |
---|---|
默认值 | nobody |
位置 | 全局块 |
该属性也可以在编译的时候指定,语法如下./configure --user=user --group=group
,如果两个地方都进行了设置,最终生效的是配置文件中的配置。
该指令的使用步骤:
(1)设置一个用户信息”www”
1 | user www; |
(2)修改nginx.conf
1 | location / { |
(3)测试启动访问
1 | 页面会报403拒绝访问的错误 |
(4)分析原因
1 | 因为当前用户没有访问/root/html目录的权限 |
(5)将文件创建到 /home/www/html/index.html
,修改配置
1 | location / { |
(6)再次测试启动访问
1 | 能正常访问。 |
综上所述,使用user指令可以指定启动运行工作进程的用户及用户组,这样对于系统的权限访问控制的更加精细,也更加安全。
work process指令
master_process:用来指定是否开启工作进程。
语法 | master_process on|off; |
---|---|
默认值 | master_process on; |
位置 | 全局块 |
worker_processes:用于配置Nginx生成工作进程的数量,这个是Nginx服务器实现并发处理服务的关键所在。理论上来说workder process的值越大,可以支持的并发处理量也越多,但事实上这个值的设定是需要受到来自服务器自身的限制,建议将该值和服务器CPU的内核数保存一致。
语法 | worker_processes num/auto; |
---|---|
默认值 | 1 |
位置 | 全局块 |
如果将worker_processes设置成2,则会看到如下内容:
其他指令
daemon:设定Nginx是否以守护进程的方式启动。
守护式进程是linux后台执行的一种服务进程,特点是独立于控制终端,不会随着终端关闭而停止。
语法 | daemon on|off; |
---|---|
默认值 | daemon on; |
位置 | 全局块 |
pid:用来配置Nginx当前master进程的进程号ID存储的文件路径。
语法 | pid file; |
---|---|
默认值 | 默认为:/usr/local/nginx/logs/nginx.pid |
位置 | 全局块 |
该属性可以通过./configure --pid-path=PATH
来指定
error_log:用来配置Nginx的错误日志存放路径
语法 | error_log file [日志级别]; |
---|---|
默认值 | error_log logs/error.log error; |
位置 | 全局块、http、server、location |
该属性可以通过./configure --error-log-path=PATH
来指定
其中日志级别的值有:debug|info|notice|warn|error|crit|alert|emerg,翻译过来为试|信息|通知|警告|错误|临界|警报|紧急,这块建议大家设置的时候不要设置成info以下的等级,因为会带来大量的磁盘I/O消耗,影响Nginx的性能。
(5)include:用来引入其他配置文件,使Nginx的配置更加灵活(重点)
语法 | include file; |
---|---|
默认值 | 无 |
位置 | any |
events块
(1)accept_mutex:用来设置Nginx网络连接序列化
语法 | accept_mutex on|off; |
---|---|
默认值 | accept_mutex on; |
位置 | events |
这个配置主要可以用来解决常说的”惊群”问题。大致意思是在某一个时刻,客户端发来一个请求连接,Nginx后台是以多进程的工作模式,也就是说有多个worker进程会被同时唤醒,但是最终只会有一个进程可以获取到连接,如果每次唤醒的进程数目太多,就会影响Nginx的整体性能。如果将上述值设置为on(开启状态),将会对多个Nginx进程接收连接进行序列号,一个个来唤醒接收,就防止了多个进程对连接的争抢。
(2)multi_accept:用来设置是否允许同时接收多个网络连接
语法 | multi_accept on|off; |
---|---|
默认值 | multi_accept off; |
位置 | events |
如果multi_accept被禁止了,nginx一个工作进程只能同时接受一个新的连接。否则,一个工作进程可以同时接受所有的新连接
(3)worker_connections:用来配置单个worker进程最大的连接数
语法 | worker_connections number; |
---|---|
默认值 | worker_commections 512; |
位置 | events |
这里的连接数不仅仅包括和前端用户建立的连接数,而是包括所有可能的连接数。另外,number值不能大于操作系统支持打开的最大文件句柄数量。
(4)use:用来设置Nginx服务器选择哪种事件驱动来处理网络消息。
语法 | use method; |
---|---|
默认值 | 根据操作系统定 |
位置 | events |
注意:此处所选择事件处理模型是Nginx优化部分的一个重要内容,method的可选值有select/poll/epoll/kqueue等,之前在准备centos环境的时候,我们强调过要使用linux内核在2.6以上,就是为了能使用epoll函数来优化Nginx。
另外这些值的选择,我们也可以在编译的时候使用
--with-select_module
、--without-select_module
、
--with-poll_module
、 --without-poll_module
来设置是否需要将对应的事件驱动模块编译到Nginx的内核。
events指令配置实例
打开Nginx的配置文件 nginx.conf,添加如下配置
1 | events{ |
启动测试
1 | ./nginx -t |
http块
定义MIME-Type
我们都知道浏览器中可以显示的内容有HTML、XML、GIF等种类繁多的文件、媒体等资源,浏览器为了区分这些资源,就需要使用MIME Type。所以说MIME Type是网络资源的媒体类型。Nginx作为web服务器,也需要能够识别前端请求的资源类型。
在Nginx的配置文件中,默认有两行配置
1 | include mime.types; |
(1)default_type:用来配置Nginx响应前端请求默认的MIME类型。
语法 | default_type mime-type; |
---|---|
默认值 | default_type text/plain; |
位置 | http、server、location |
在default_type之前还有一句include mime.types
,include之前我们已经介绍过,相当于把mime.types文件中MIMT类型与相关类型文件的文件后缀名的对应关系加入到当前的配置文件中。
举例来说明:
有些时候请求某些接口的时候需要返回指定的文本字符串或者json字符串,如果逻辑非常简单或者干脆是固定的字符串,那么可以使用nginx快速实现,这样就不用编写程序响应请求了,可以减少服务器资源占用并且响应性能非常快。
如何实现:
1 | location /get_text { |
自定义服务日志
Nginx中日志的类型分access.log、error.log。
access.log:用来记录用户所有的访问请求。
error.log:记录nginx本身运行时的错误信息,不会记录用户的访问请求。
Nginx服务器支持对服务日志的格式、大小、输出等进行设置,需要使用到两个指令,分别是access_log和log_format指令。
(1)access_log:用来设置用户访问日志的相关属性。
语法 | access_log path[format[buffer=size]] |
---|---|
默认值 | access_log logs/access.log combined; |
位置 | http , server , location |
(2)log_format:用来指定日志的输出格式。
语法 | log_format name [escape=default|json|none] string….; |
---|---|
默认值 | log_format combined “…”; |
位置 | http |
其他配置指令
(1)sendfile:用来设置Nginx服务器是否使用sendfile()传输文件,该属性可以大大提高Nginx处理静态资源的性能
语法 | sendfile on|off; |
---|---|
默认值 | sendfile off; |
位置 | http、server、location |
(2)keepalive_timeout:用来设置长连接的超时时间。
》为什么要使用keepalive?
1 | 我们都知道HTTP是一种无状态协议,客户端向服务端发送一个TCP请求,服务端响应完毕后断开连接。 |
语法 | keepalive_timeout time; |
---|---|
默认值 | keepalive_timeout 75s; |
位置 | http、server、location |
(3)keepalive_requests:用来设置一个keep-alive连接使用的次数。
语法 | keepalive_requests number; |
---|---|
默认值 | keepalive_requests 100; |
位置 | http、server、location |
server块和location块
server块和location块都是我们要重点讲解和学习的内容,因为我们后面会对Nginx的功能进行详细讲解,所以这块内容就放到静态资源部署的地方给大家详细说明。
本节我们主要来认识下Nginx默认给的nginx.conf中的相关内容,以及server块与location块在使用的时候需要注意的一些内容。
1 | server { |
Nginx服务器基础配置实例
需求如下:
1 | (1)有如下访问: |
配置的内容如下:
1 |
|
server1.conf
1 | server{ |
server2.conf
1 | server{ |
优点在于:对于每个站点都独立的配置文件,修改后不用重启nginx.conf核心配置文件。
Nginx静态资源部署
Nginx静态资源概述
上网去搜索访问资源对于我们来说并不陌生,通过浏览器发送一个HTTP请求实现从客户端发送请求到服务器端获取所需要内容后并把内容回显展示在页面的一个过程。这个时候,我们所请 求的内容就分为两种类型,一类是静态资源、一类是动态资源。
静态资源即指在服务器端真实存在并且能直接拿来展示的一些文件,比如常见的html页面、css文件、js文件、图 片、视频等资源;
动态资源即指在服务器端真实存在但是要想获取需要经过一定的业务逻辑处理,根据不同的条件展示在页面不同这 一部分内容,比如说报表数据展示、根据当前登录用户展示相关具体数据等资源;
Nginx静态资源的配置指令
listen指令
listen:用来配置监听端口。
语法 | listen address[:port] [default_server]…; listen port [default_server]…; |
---|---|
默认值 | listen *:80 | *:8000 |
位置 | server |
listen的设置比较灵活,我们通过几个例子来把常用的设置方式熟悉下:
1 | listen 127.0.0.1:8000; // listen localhost:8000 监听指定的IP和端口 |
default_server属性是标识符,用来将此虚拟主机设置成默认主机。所谓的默认主机指的是如果没有匹配到对应的address:port,则会默认执行的。如果不指定默认使用的是第一个server。
1 | server{ |
server_name指令
server_name:用来设置虚拟主机服务名称。
127.0.0.1 、 localhost 、域名[www.baidu.com | www.jd.com]
语法 | server_name name …; name可以提供多个中间用空格分隔 |
---|---|
默认值 | server_name “”; |
位置 | server |
关于server_name的配置方式有三种,分别是:
1 | 精确匹配 |
配置方式一:精确匹配
如:
1 | server { |
补充小知识点:
hosts是一个没有扩展名的系统文件,可以用记事本等工具打开,其作用就是将一些常用的网址域名与其对应的IP地址建立一个关联“数据库”,当用户在浏览器中输入一个需要登录的网址时,系统会首先自动从hosts文件中寻找对应的IP地址,一旦找到,系统会立即打开对应网页,如果没有找到,则系统会再将网址提交DNS域名解析服务器进行IP地址的解析。
windows:C:\Windows\System32\drivers\etc
centos:/etc/hosts
因为域名是要收取一定的费用,所以我们可以使用修改hosts文件来制作一些虚拟域名来使用。需要修改 /etc/hosts
文件来添加
1 | vim /etc/hosts |
配置方式二:使用通配符配置
server_name中支持通配符”*”,但需要注意的是通配符不能出现在域名的中间,只能出现在首段或尾段,如:
1 | server { |
下面的配置就会报错
1 | server { |
配置三:使用正则表达式配置
server_name中可以使用正则表达式,并且使用~
作为正则表达式字符串的开始标记。
配置如下:
1 | server{ |
匹配执行顺序
由于server_name指令支持通配符和正则表达式,因此在包含多个虚拟主机的配置文件中,可能会出现一个名称被多个虚拟主机的server_name匹配成功,当遇到这种情况,当前的请求交给谁来处理呢?
1 | server{ |
结论:
1 | exact_success |
1 | No1:准确匹配server_name |
location指令
1 | server{ |
location:用来设置请求的URI
语法 | location [ = | ~ | |
---|---|
默认值 | — |
位置 | server,location |
uri变量是待匹配的请求字符串,可以不包含正则表达式,也可以包含正则表达式,那么nginx服务器在搜索匹配location的时候,是先使用不包含正则表达式进行匹配,找到一个匹配度最高的一个,然后在通过包含正则表达式的进行匹配,如果能匹配到直接访问,匹配不到,就使用刚才匹配度最高的那个location来处理请求。
设置请求资源的目录root / alias
root:设置请求的根目录
语法 | root path; |
---|---|
默认值 | root html; |
位置 | http、server、location |
path为Nginx服务器接收到请求以后查找资源的根目录路径。
alias:用来更改location的URI
语法 | alias path; |
---|---|
默认值 | — |
位置 | location |
path为修改后的根路径。
以上两个指令都可以来指定访问资源的路径,那么这两者之间的区别是什么?
举例说明:
(1)在/usr/local/nginx/html
目录下创建一个 images目录,并在目录下放入一张图片mv.png
图片
1 | location /images { |
访问图片的路径为:
1 | http://192.168.200.133/images/mv.png |
(2)如果把root改为alias
1 | location /images { |
再次访问上述地址,页面会出现404的错误,查看错误日志会发现是因为地址不对,所以验证了:
1 | root的处理结果是: root路径+location路径 |
需要在alias后面路径改为
1 | location /images { |
(3)如果location路径是以/结尾,则alias也必须是以/结尾,root没有要求
将上述配置修改为
1 | location /images/ { |
访问就会出问题,查看错误日志还是路径不对,所以需要把alias后面加上 /
小结:
1 | root的处理结果是: root路径+location路径 |
index指令
index:设置网站的默认首页
语法 | index file …; |
---|---|
默认值 | index index.html; |
位置 | http、server、location |
index后面可以跟多个设置,如果访问的时候没有指定具体访问的资源,则会依次进行查找,找到第一个为止。
举例说明:
1 | location / { |
error_page指令
error_page:设置网站的错误页面
语法 | error_page code … [=[response]] uri; |
---|---|
默认值 | — |
位置 | http、server、location…… |
当出现对应的响应code后,如何来处理。
举例说明:
(1)可以指定具体跳转的地址
1 | server { |
(2)可以指定重定向地址
1 | server{ |
(3)使用location的@符合完成错误信息展示
1 | server{ |
可选项=[response]
的作用是用来将相应代码更改为另外一个
1 | server{ |
Nginx反向代理(重要!)
Nginx反向代理概述
正向代理代理的对象是客户端,反向代理代理的是服务端,这是两者之间最大的区别
Nginx即可以实现正向代理,也可以实现反向代理。
虽然我们是客户端访问服务端,但是如何使用了代理,那么服务端能看到的只是代理发送过去的请求,这样的化,就使用Nginx实现了正向代理的设置。
Nginx反向代理的配置语法
Nginx反向代理模块的指令是由ngx_http_proxy_module
模块进行解析,该模块在安装Nginx的时候已经自己加装到Nginx中
1 | proxy_pass |
proxy_pass
该指令用来设置被代理服务器地址,可以是主机名称、IP地址加端口号形式。
语法 | proxy_pass URL; |
---|---|
默认值 | — |
位置 | location |
URL:为要设置的被代理服务器地址,包含传输协议(http
,https://
)、主机名称或IP地址加端口号、URI等要素。
举例:
1 | proxy_pass http://www.baidu.com; |
后面的值要不要加”/“?
接下来通过例子来说明刚才我们提到的问题:
1 | server { |
建议不要加”/“.
proxy_set_header
该指令可以更改Nginx服务器接收到的客户端请求的请求头信息,然后将新的请求头发送给代理的服务器
语法 | proxy_set_header field value; |
---|---|
默认值 | proxy_set_header Host $proxy_host; proxy_set_header Connection close; |
位置 | http、server、location |
需要注意的是,如果想要看到结果,必须在被代理的服务器上来获取添加的头信息。
被代理服务器: [192.168.200.146]
1 | server { |
代理服务器: [192.168.200.133]
1 | server { |
访问测试
proxy_redirect
该指令是用来重置头信息中的”Location”和”Refresh”的值。
语法 | proxy_redirect redirect replacement; proxy_redirect default; proxy_redirect off; |
---|---|
默认值 | proxy_redirect default; |
位置 | http、server、location |
》为什么要用该指令?
服务端[192.168.200.146]
1 | server { |
代理服务端[192.168.200.133]
1 | server { |
》该指令的几组选项
proxy_redirect redirect replacement;
1 | redirect:目标,Location的值 |
proxy_redirect default;
1 | default; |
proxy_redirect off;
1 | 关闭proxy_redirect的功能 |
Nginx负载均衡(重要!!)
负载均衡概述
台服务器的性能及单点故障问题就凸显出来了,因此需要多台服务器进行性能的水平扩展及避免单点故障出现。那么如何将不同用户的请求流量分发到不同的服务器上呢?
负载均衡的原理及处理流程
系统的扩展可以分为纵向扩展和横向扩展。
纵向扩展是从单机的角度出发,通过增加系统的硬件处理能力来提升服务器的处理能力
横向扩展是通过添加机器来满足大型网站服务的处理能力。
这里面涉及到两个重要的角色分别是”应用集群”和”负载均衡器”。
应用集群:将同一应用部署到多台机器上,组成处理集群,接收负载均衡设备分发的请求,进行处理并返回响应的数据。
负载均衡器:将用户访问的请求根据对应的负载均衡算法,分发到集群中的一台服务器进行处理。
负载均衡的作用
1、解决服务器的高并发压力,提高应用程序的处理性能。
2、提供故障转移,实现高可用。
3、通过添加或减少服务器数量,增强网站的可扩展性。
4、在负载均衡器上进行过滤,可以提高系统的安全性。
负载均衡常用的处理方式
方式一:用户手动选择
这种方式比较原始,只要实现的方式就是在网站主页上面提供不同线路、不同服务器链接方式,让用户来选择自己访问的具体服务器,来实现负载均衡。
方式二:DNS轮询方式
DNS
1 | 域名系统(服务)协议(DNS)是一种分布式网络目录服务,主要用于域名与 IP 地址的相互转换。 |
大多域名注册商都支持对同一个主机名添加多条A记录,这就是DNS轮询,DNS服务器将解析请求按照A记录的顺序,随机分配到不同的IP上,这样就能完成简单的负载均衡。DNS轮询的成本非常低,在一些不重要的服务器,被经常使用。
DNS来实现轮询,不需要投入过多的成本,虽然DNS轮询成本低廉,但是DNS负载均衡存在明显的缺点
1.可靠性低
假设一个域名DNS轮询多台服务器,如果其中的一台服务器发生故障,那么所有的访问该服务器的请求将不会有所回应,即使你将该服务器的IP从DNS中去掉,但是由于各大宽带接入商将众多的DNS存放在缓存中,以节省访问时间,导致DNS不会实时更新。所以DNS轮流上一定程度上解决了负载均衡问题,但是却存在可靠性不高的缺点。
2.负载均衡不均衡
DNS负载均衡采用的是简单的轮询负载算法,不能区分服务器的差异,不能反映服务器的当前运行状态,不能做到为性能好的服务器多分配请求,另外本地计算机也会缓存已经解析的域名到IP地址的映射,这也会导致使用该DNS服务器的用户在一定时间内访问的是同一台Web服务器,从而引发Web服务器减的负载不均衡。
负载不均衡则会导致某几台服务器负荷很低,而另外几台服务器负荷确很高,处理请求的速度慢,配置高的服务器分配到的请求少,而配置低的服务器分配到的请求多。
负载均衡策略
我们已经能实现将用户的请求分发到不同的服务器上,那么除了采用默认的分配方式以外,我们还能采用什么样的负载算法?
Nginx的upstream支持如下六种方式的分配算法,分别是:
算法名称 | 说明 |
---|---|
轮询 | 默认方式 |
weight | 权重方式 |
ip_hash | 依据ip分配方式 |
least_conn | 依据最少连接方式 |
url_hash | 依据URL分配方式 |
fair | 依据响应时间方式 |
轮询
是upstream模块负载均衡默认的策略。每个请求会按时间顺序逐个分配到不同的后端服务器。轮询不需要额外的配置。
1 | upstream backend{ |
weight加权[加权轮询]
weight=number:用来设置服务器的权重,默认为1,权重数据越大,被分配到请求的几率越大;该权重值,主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的,所有此策略比较适合服务器的硬件配置差别比较大的情况。
1 | upstream backend{ |
ip_hash
0
当对后端的多台动态应用服务器做负载均衡时,ip_hash指令能够将某个客户端IP的请求通过哈希算法定位到同一台后端服务器上。这样,当来自某一个IP的用户在后端Web服务器A上登录后,在访问该站点的其他URL,能保证其访问的还是后端web服务器A。
语法 | ip_hash; |
---|---|
默认值 | — |
位置 | upstream |
1 | upstream backend{ |
需要额外多说一点的是使用ip_hash指令无法保证后端服务器的负载均衡,可能导致有些后端服务器接收到的请求多,有些后端服务器接收的请求少,而且设置后端服务器权重等方法将不起作用。
以上两种比较常用,其他自行查找