Nginx的使用
一:序言
Nginx是lgor Sysoev为俄罗斯访问量第二的rambler.ru站点设计开发的。从2004年发布至今,凭借开源的力量,已经接近成熟与完善。
二:Nginx常用功能
1. 正向代理、反向代理
正向代理是众多内网客户机上网访问互联网上的网站时,将所有的请求交给内网前面处于公网上的"管家"服务器,由"管家"服务器代为请求想要访问的web服务器,然后将得到的结果缓存下来并提供给客户端,这是正向代理。"管家"服务器称为正向代理服务器。
反向代理是客户端访问web服务器时,请求发送到真实的web服务器的前端"助手"服务器上,由"助手"服务器决定将此请求转发给哪个真实的web服务器,外界客户端以为"助手"服务器就是真实的web服务器,而实际上它不是,也不需要安装任何web程序。"助手"服务器称为反向代理服务器。
Nginx在做反向代理时,提供性能稳定,并且能够提供配置灵活的转发功能。Nginx可以根据不同的正则匹配,采取不同的转发策略,比如图片文件结尾的走文件服务器,动态页面走web服务器,只要你正则写的没问题,又有相对应的服务器解决方案,你就可以随心所欲的玩。并且Nginx对返回结果进行错误页跳转,异常判断等。如果被分发的服务器存在异常,他可以将请求重新转发给另外一台服务器,然后自动去除异常服务器。
2、负载均衡
Nginx提供的负载均衡策略有2种:内置策略和扩展策略。
内置策略为轮询,加权轮询,Ip hash。
扩展策略,就天马行空,只有你想不到的没有他做不到的啦,你可以参照所有的负载均衡算法,给他一一找出来做下实现。
以上3个图,理解这三种负载均衡算法的实现
Ip hash算法,对客户端请求的ip进行hash操作,然后根据hash结果将同一个客户端ip的请求分发给同一台服务器进行处理,可以解决session不共享的问题。
3、web缓存
Nginx可以对不同的文件做不同的缓存处理,配置灵活,并且支持FastCGI_Cache,主要用于对FastCGI的动态程序进行缓存。配合着第三方的ngx_cache_purge,对制定的URL缓存内容可以的进行增删管理。
4、Nginx相关地址
源码:https://trac.nginx.org/nginx/browser
官网:http://www.nginx.org/
Nginx 下载地址:http://nginx.org/en/download.html
三: Nginx的启动
1:可以直接双击nginx.exe 启动服务;
2:可以通过DOS命令启动服务:
启动服务:start nginx
退出服务:nginx -s quit
强制关闭服务:nginx -s stop
重载服务:nginx -s reload (重载服务配置文件,类似于重启,服务不会中止)
验证配置文件:nginx -t
使用配置文件:nginx -c "配置文件路径"
使用帮助:nginx –h
检nginx服务是否正常启动:tasklist /fi "imagename eq nginx.exe"
3:可以创建快捷启动方式:如果不想敲命令启动,可以直接创建快捷文件:starup.bat(保存在与nginx.exe执行文件同目录下),文件内容如下:
@echo off rem 如果启动前已经启动nginx并记录下pid文件,会kill指定进程 nginx.exe -s stop rem 测试配置文件语法正确性 nginx.exe -t -c conf/nginx.conf rem 显示版本信息 nginx.exe -v rem 按照指定配置去启动nginx nginx.exe -c conf/nginx.conf
服务启动之后:
开浏览器,输入地址:http://localhost,访问页面,出现如下页面表示访问成功。
注意:Nginx启动需要注意的为以下几点:
1:下载的Nginx不能放在带有中文的目录下面
2:启动时,要看一下Server中的listen监听的端口是否被占用
3:如果发现启动有问题,可以看根目录下logs下面的error.log日志
四、Nginx基本配置
我们可以看到nginx文件夹内有一个conf文件夹,其中有好几个文件,其他先不管,我们打开nginx.conf,可以看到一段:
这段代码在server里面,相当于一个代理服务器,当然可以配置多个。
下面我们仔细来分析一下:
listen:表示当前的代理服务器监听的端口,默认的是监听80端口。注意,如果我们配置了多个server,这个listen要配置不一样,不然就不能确定转到哪里去了。
server_name:表示监听到之后需要转到哪里去,这时我们直接转到本地,这时是直接到nginx文件夹内。
location:表示匹配的路径,这时配置了/表示所有请求都被匹配到这里
root:里面配置了root这时表示当匹配这个请求的路径时,将会在这个文件夹内寻找相应的文件,这里对我们之后的静态文件伺服很有用。
index:当没有指定主页时,默认会选择这个指定的文件,它可以有多个,并按顺序来加载,如果第一个不存在,则找第二个,依此类推。
注意:1:其实就是输入:server_name:listen会转发到对应的location节点下的proxy_pass的路径,如果使用了upstream 服务名(可以自定义),但是要与proxy_pass保持一致。
2:在nginx中配置proxy_pass时,当在后面的url加上了/,相当于是绝对根路径,则nginx不会把location中匹配的路径部分代理走;如果没有/,则会把匹配的路径部分也给代理走。
下面四种情况分别用http://192.168.1.4/proxy/test.html 进行访问。
第一种:
1 2 3 4 5 | location /proxy/ { proxy_pass http://127.0.0.1:81/; } |
会被代理到http://127.0.0.1:81/test.html 这个url
第二种(相对于第一种,最后少一个 /)
1 2 3 4 5 | location /proxy/ { proxy_pass http://127.0.0.1:81; } |
会被代理到http://127.0.0.1:81/proxy/test.html 这个url
第三种:
1 2 3 4 5 | location /proxy/ { proxy_pass http://127.0.0.1:81/ftlynx/; } |
会被代理到http://127.0.0.1:81/ftlynx/test.html 这个url。
第四种情况(相对于第三种,最后少一个 / ):
location /proxy/ { proxy_pass http://127.0.0.1:81/ftlynx; }
会被代理到http://127.0.0.1:81/ftlynxtest.html 这个url
五、实现负载均衡
负载均衡的作用
1、转发功能
按照一定的算法【权重、轮询、Ip_Hash】,将客户端请求转发到不同应用服务器上,减轻单个服务器压力,提高系统并发量。
2、故障移除
通过心跳检测的方式,判断应用服务器当前是否可以正常工作,如果服务器期宕掉,自动将请求发送到其他应用服务器。
3、恢复添加
如检测到发生故障的应用服务器恢复工作,自动将其添加到处理用户请求队伍中。
同样部署四台应用服务器,端口号分别为7010,7020,7030,7040
1、Nginx的负载分发策略, Nginx 的 upstream目前支持的分配算法:
A)、轮询 ——1:1 轮流处理请求(默认)
每个请求按时间顺序逐一分配到不同的应用服务器,如果应用服务器down掉,自动剔除,剩下的继续轮询。
B)、权重 ——you can you up
通过配置权重,指定轮询几率,权重和访问比率成正比,用于应用服务器性能不均的情况。
C)、ip_哈希算法
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个应用服务器,可以解决session共享的问题。
2、配置Nginx的负载均衡与分发策略, 通过在upstream参数中添加的应用服务器IP后添加指定参数即可实现,如:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | http { #设定负载均衡的服务器列表 支持多组的负载均衡,可以配置多个upstream 来服务于不同的Server. #nginx 的 upstream 支持 几 种方式的分配 #1)、轮询(默认) 每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除,如果恢复,则正常使用。 #2)、weight 指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。 跟上面样,指定了权重。 #3)、ip_hash 每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。 #4)、fair #5)、url_hash #Urlhash upstream mysvr { #mysvr是可以随便写的,在下面应用到 #1.down 表示单前的server暂时不参与负载 #2.weight 默认为1.weight越大,负载的权重就越大。 #3.backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。 ip_hash; #就表示使用ipHash策略 server 10.44.2.52:7040;# down; server 10.44.2.52:7030;# backup; server 10.44.2.52:7020;# weight=1; server 10.44.2.52:7010;# weight=2; } #HTTP服务器 server { listen 8888; server_name www.wss1.com; #不要添加Http,不然会发出对应的警告,运用的时候,需要在host增加10.44.2.52 www.wss1.com,然后访问:www.wss1.com:8888/test/就会跳转到proxy_pass路径下面。 #charset koi8-r; #access_log logs/host.access.log main; #反向代理的路径(和upstream绑定),location 后面设置映射的路径 location /test/ { proxy_pass http://mysvr/; } } } |
通过以上配置,便可以实现,在访问www.wss1.com:8888(如果域名不存在,则需要在host里面进行配置映射到本地ip)这个网站时,由于配置了proxy_pass地址,所有请求都会先通过nginx反向代理服务器,在服务器将请求转发给目的主机时,读取upstream为 mysvr的地址,读取分发策略。
3、nginx负载转发配置的具体解释如下:
1)down
表示单前的server暂时不参与负载
2)weight
默认为1.weight越大,负载的权重就越大。
3)max_fails
允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误
4)fail_timeout
max_fails 次失败后,暂停的时间。
5)backup
其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。
六、使用Nginx的高可用
除了要实现网站的高可用,也就是提供n多台服务器用于发布相同的服务,添加负载均衡服务器分发请求以保证在高并发下各台服务器能相对饱和的处理请求。同样,负载均衡服务器也需要高可用,以防如果负载均衡服务器挂掉了,后面的应用服务器也紊乱无法工作。实现高可用的方案:添加冗余。添加n台nginx服务器以避免发生上述单点故障。具体方案详见下文:keepalive+nginx实现负载均衡高可用
转载于:https://www.cnblogs.com/loverwangshan/p/11453361.html
七、常见应用场景配置
a.假设这样一个应用场景:将应用部署在 192.168.1.11:80、192.168.1.12:80、192.168.1.13:80 三台linux环境的服务器上。网站域名叫 www.legend.cn,公网IP为 192.168.1.11。在公网IP所在的服务器上部署 nginx,对所有请求做负载均衡处理。
http { #设定mime类型,类型由mime.type文件定义 include /etc/nginx/mime.types; default_type application/octet-stream; #设定日志格式 access_log /var/log/nginx/access.log; #设定负载均衡的服务器列表 upstream load_balance_server { #weigth参数表示权值,权值越高被分配到的几率越大 server 192.168.1.11:80 weight=5; server 192.168.1.12:80 weight=1; server 192.168.1.13:80 weight=6; } #HTTP服务器 server { #侦听80端口 listen 80; #定义使用www.xx.com访问 server_name www.legend.cn; #对所有请求进行负载均衡请求 location / { root /root; #定义服务器的默认网站根目录位置 index index.html index.htm; #定义首页索引文件的名称 proxy_pass http://load_balance_server ;#请求转向load_balance_server 定义的服务器列表 #以下是一些反向代理的配置(可选择性配置) #proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; #后端的Web服务器可以通过X-Forwarded-For获取用户真实IP proxy_set_header X-Forwarded-For $remote_addr; proxy_connect_timeout 90; #nginx跟后端服务器连接超时时间(代理连接超时) proxy_send_timeout 90; #后端服务器数据回传时间(代理发送超时) proxy_read_timeout 90; #连接成功后,后端服务器响应时间(代理接收超时) proxy_buffer_size 4k; #设置代理服务器(nginx)保存用户头信息的缓冲区大小 proxy_buffers 4 32k; #proxy_buffers缓冲区,网页平均在32k以下的话,这样设置 proxy_busy_buffers_size 64k; #高负荷下缓冲大小(proxy_buffers*2) proxy_temp_file_write_size 64k; #设定缓存文件夹大小,大于这个值,将从upstream服务器传 client_max_body_size 10m; #允许客户端请求的最大单文件字节数 client_body_buffer_size 128k; #缓冲区代理缓冲用户端请求的最大字节数 } } }
b.网站有多个webapp的配置
当一个网站功能越来越丰富时,往往需要将一些功能相对独立的模块剥离出来,独立维护。这样的话,通常,会有多个 webapp。
****
举个例子:假如 www.legend.cn 站点有好几个webapp,finance(金融)、product(产品)、admin(用户中心)。访问这些应用的方式通过上下文(context)来进行区分:
- www.legend.cn/finance/
- www.legend.cn/product/
- www.legend.cn/admin/
我们知道,http的默认端口号是80,如果在一台服务器上同时启动这3个 webapp 应用,都用80端口,肯定是不成的。所以,这三个应用需要分别绑定不同的端口号。
那么,问题来了,用户在实际访问 www.legend.cn 站点时,访问不同 webapp,总不会还带着对应的端口号去访问吧。所以,你再次需要用到反向代理来做处理。配置也不难,来看看怎么做吧:
http { #此处省略一些基本配置 upstream product_server{ server www.legend.cn:8081; } upstream admin_server{ server www.legend.cn:8082; } upstream finance_server{ server www.legend.cn:8083; } server { #此处省略一些基本配置 #默认指向product的server location / { proxy_pass http://product_server; } location /product/{ proxy_pass http://product_server; } location /admin/ { proxy_pass http://admin_server; } location /finance/ { proxy_pass http://finance_server; } } }
c.https反向代理配置
一些对安全性要求比较高的站点,可能会使用 HTTPS(一种使用ssl通信标准的安全HTTP协议)。
这里不科普 HTTP 协议和 SSL 标准。但是,使用 nginx 配置 https 需要知道几点:
HTTPS 的固定端口号是 443,不同于 HTTP 的 80 端口
SSL 标准需要引入安全证书,所以在 nginx.conf 中你需要指定证书和它对应的 key
其他和 http 反向代理基本一样,只是在 Server 部分配置有些不同。
#HTTP服务器 server { #监听443端口。443为知名端口号,主要用于HTTPS协议 listen 443 ssl; #定义使用www.xx.com访问 server_name www.legend.cn; #ssl证书文件位置(常见证书文件格式为:crt/pem) ssl_certificate cert.pem; #ssl证书key位置 ssl_certificate_key cert.key; #ssl配置参数(选择性配置) ssl_session_cache shared:SSL:1m; ssl_session_timeout 5m; #数字签名,此处使用MD5 ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; location / { root /root; index index.html index.htm; } }
d.静态站点配置
有时候,我们需要配置静态站点(即 html 文件和一堆静态资源)。
举例来说:如果所有的静态资源都放在了 /app/dist 目录下,我们只需要在 nginx.conf 中指定首页以及这个站点的 host 即可。
配置如下:
worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; gzip on; gzip_types text/plain application/x-javascript text/css application/xml text/javascript application/javascript image/jpeg image/gif image/png; gzip_vary on; server { listen 80; server_name static.zp.cn; location / { root /app/dist; index index.html; #转发任何请求到 index.html } } }
然后,添加 HOST:
127.0.0.1 static.zp.cn,此时,在本地浏览器访问 static.zp.cn ,就可以访问静态站点了。
3.跨域解决方案
web 领域开发中,经常采用前后端分离模式。这种模式下,前端和后端分别是独立的 web 应用程序,例如:后端是 Java 程序,前端是 React 或 Vue 应用,更多请看这篇文章《到底什么是跨域,及解决方案》。
各自独立的 web app 在互相访问时,势必存在跨域问题。解决跨域问题一般有两种思路:
解决跨域问题一般有两种思路:
- CORS
在后端服务器设置 HTTP 响应头,把你需要运行访问的域名加入加入 Access-Control-Allow-Origin 中。
- jsonp
把后端根据请求,构造json数据,并返回,前端用 jsonp 跨域。
这两种思路,本文不展开讨论。
需要说明的是,nginx 根据第一种思路,也提供了一种解决跨域的解决方案。
举例:www.legend.cn 网站是由一个前端 app ,一个后端 app 组成的。前端端口号为 9000, 后端端口号为 8080。
前端和后端如果使用 http 进行交互时,请求会被拒绝,因为存在跨域问题。来看看,nginx 是怎么解决的吧:
首先,在 enable-cors.conf 文件中设置 cors :
# allow origin list set $ACAO '*'; # set single origin if ($http_origin ~* (www.legend.cn)$) { set $ACAO $http_origin; } if ($cors = "trueget") { add_header 'Access-Control-Allow-Origin' "$http_origin"; add_header 'Access-Control-Allow-Credentials' 'true'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type'; } if ($request_method = 'OPTIONS') { set $cors "${cors}options"; } if ($request_method = 'GET') { set $cors "${cors}get"; } if ($request_method = 'POST') { set $cors "${cors}post"; }
接下来,在你的服务器中 include enable-cors.conf 来引入跨域配置:
# ---------------------------------------------------- # 此文件为项目 nginx 配置片段 # 可以直接在 nginx config 中 include(推荐) # 或者 copy 到现有 nginx 中,自行配置 # www.legend.com 域名需配合 dns hosts 进行配置 # 其中,api 开启了 cors,需配合本目录下另一份配置文件 # ---------------------------------------------------- upstream front_server{ server www.legend.cn:9000; } upstream api_server{ server www.legend.cn:8080; } server { listen 80; server_name www.legend.cn; location ~ ^/api/ { include enable-cors.conf; proxy_pass http://api_server; rewrite "^/api/(.*)$" /$1 break; } location ~ ^/ { proxy_pass http://front_server; } }
付费内容,请联系本人QQ:1002453261
本文来自博客园,作者:明志德道,转载请注明原文链接:https://www.cnblogs.com/for-easy-fast/articles/12500024.html
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 在鹅厂做java开发是什么体验
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
· 永远不要相信用户的输入:从 SQL 注入攻防看输入验证的重要性
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析