跟我学Nginx(五)--Ngin实战

上一篇介绍Nginx的常用命令以及配置文件的讲解,这一篇我带领大家用Nginx进行实战,教教大家如何使用Nginx配置反向代理和负载均衡。

实验环境:我用的是一台支持公网IP访问腾讯云Centos服务器,已经安装上Nginx,将域名xdp.itgacl.com解析到公网服务器的IP上

一、nginx配置反向代理

1.1、反向代理实例一

实现效果:使用 nginx 反向代理,访问 xdp.itgacl.com直接跳转到magic4j.itgacl.com

在 nginx.conf 配置文件中增加如下配置

server { listen 80; server_namexdp.itgacl.com; location / { #配置反向代理 proxy_pass ; indexindex.html index.htm; } }

在浏览器中输入:xdp.itgacl.com,结果如下图所示:

1.2、反向代理实例二

实现效果:使用 nginx 反向代理,根据访问的路径前缀跳转到不同端口的服务中

访问 直接跳转到:8090

访问 直接跳转到:8888

server { listen 80; server_namexdp.itgacl.com; location / { #配置反向代理 proxy_pass ; indexindex.html index.htm; } location /blog/ { proxy_pass :8090; } location /magic4j/ { proxy_pass :8888; } }

location 指令说明

该指令用于匹配 URL。

语法如下:

location [= | ~ | ~* |^~] uri { }

1、= :用于不含正则表达式的 uri 前,要求请求字符串与 uri 严格匹配,如果匹配成功,就停止继续向下搜索并立即处理该请求。

2、~:用于表示 uri 包含正则表达式,并且区分大小写。

3、~*:用于表示 uri 包含正则表达式,并且不区分大小写。

4、^~:用于不含正则表达式的 uri 前,要求 Nginx 服务器找到标识 uri 和请求字符串匹配度最高的 location 后,立即使用此 location 处理请求,而不再使用 location块中的正则 uri 和请求字符串做匹配。

注意:如果 uri 包含正则表达式,则必须要有 ~ 或者 ~* 标识。

二、nginx配置负载均衡

2.1、负载均衡基本概念

顾名思义,负载均衡即是将负载分摊到不同的服务单元,既保证服务的可用性,又保证响应足够快,给用户很好的体验。

2.2、负载均衡的由来

早期的系统架构,基本上都是单体架构的,如下图所示:

客户端发送多个请求到服务器,服务器处理请求,有一些可能要与数据库进行交互,服务器处理完毕后,再将结果返回给客户端。

这种架构模式对于早期的系统相对单一,并发请求相对较少的情况下是比较适合的,成本也低。但是随着信息数量的不断增长,访问量和数据量的飞速增长,以及系统业务的复杂度增加,这种架构会造成服务器响应客户端的请求日益缓慢,并发量特别大的时候,还容易造成服务器直接崩溃。很明显这是由于服务器性能的瓶颈造成的问题,那么如何解决这种情况呢?

我们首先想到的可能是升级服务器的配置,比如提高CPU执行频率,加大内存等提高机器的物理性能来解决此问题,但是我们知道摩尔定律的日益失效,硬件的性能提升已经不能满足日益提升的需求了。最明显的一个例子,天猫双十一当天,某个热销商品的瞬时访问量是极其庞大的,那么类似上面的系统架构,将机器都增加到现有的顶级物理配置,都是不能够满足需求的。那么怎么办呢?

上面的分析我们去掉了增加服务器物理配置来解决问题的办法,也就是说纵向提高机器的物理性能解决问题的办法行不通了,那么横向增加服务器的数量呢?这时候集群的概念产生了,单个服务器解决不了,我们增加服务器的数量,然后将请求分发到各个服务器上,将原先请求集中到单个服务器上的情况改为将请求分发到多个服务器上,将负载分发到不同的服务器,这就是我们所说的负载均衡。

负载均衡完美地解决了单个服务器硬件性能瓶颈的问题,但是随着而来的如何实现负载均衡呢?客户端怎么知道要将请求发送到那个服务器去处理呢?

快速增长的访问量和数据流量催生了各式各样的负载均衡产品,很多专业的负载均衡硬件(如F5)提供了很好的功能,但却价格不菲,这使得负载均衡软件大受欢迎,nginx 就是其中的一个,在 linux 下有 Nginx、LVS、Haproxy 等等服务可以提供负载均衡服务。

2.3、Nginx实现负载均衡

Nginx 服务器是充当客户端和服务器之间的中介,通过反向代理的功能,客户端发送的请求先经过 Nginx ,然后通过 Nginx 将请求根据相应的规则分发到相应的服务器。

nginx实现负载均衡的主要配置指令为 pass_proxy 指令以及 upstream 指令。我们来看一个具体的配置案例,在nginx.conf中进行配置

http { include mime.types; default_typeapplication/octet-stream; sendfileon; keepalive_timeout65; #API服务端地址 upstream dddappServer { server 172.18.108.27:8888 weight=1; server 172.18.185.222:8888 weight=1; } server { server_name dddapp.jielongbuy.com; #访问域名 listen 80; #端口号设置80,这样通过域名访问时就不再需要再域名后面加上:端口号了 indexindex.html; #网站首页页面名称 access_log logs/dddapp.jielongbuy.com.access.log; #配置记录访问日志的文件 error_loglogs/dddapp.jielongbuy.com.error.log; #配置记录错误日志的文件 #配置访问路径 location / { proxy_pass ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } }

2.4、Nginx的负载均衡算法

负载均衡主要通过专门的硬件设备或者软件算法实现。通过硬件设备实现的负载均衡效果好、效率高、性能稳定,但是成本较高。而通过软件实现的负载均衡主要依赖于均衡算法的选择和程序的健壮性。均衡算法又主要分为两大类:

  静态负载均衡算法:主要包括轮询算法、基于比率的加权轮询算法或者基于优先级的加权轮询算法。

  动态负载均衡算法:主要包括基于任务量的最少连接优化算法、基于性能的最快响应优先算法、预测算法及动态性能分配算法等。

①、普通轮询算法(默认)

  每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器 down 掉,能自动剔除,Nginx默认是用轮询算法。

upstream dddappServer { server 172.18.108.27:8888; server 172.18.185.222:8888; }

②、基于比例加权轮询

upstream dddappServer { server 172.18.108.27:8888 weight=1; server 172.18.185.222:8888 weight=2; }

weight 代表权重,用来指定轮询几率,用于后端服务器性能不均的情况,weight 和访问比率成正比,默认为 1,权重越高被分配的客户端越多。

③、ip_hash算法

每个请求按访问 ip 的 hash 结果分配,这样每个访客固定访问一个后端服务器

upstream dddappServer { ip_hash; server 172.18.108.27:8888; server 172.18.185.222:8888; }

在 upstream 指令块中增加了 ip_hash 指令。该指令就是告诉 nginx 服务器,同一个 IP 地址客户端发送的请求都将分发到同一个服务器进行处理

④、fair (第三方)

按后端服务器的响应时间来分配请求,响应时间短的优先分配

upstream dddappServer { server 172.18.108.27:8888; server 172.18.185.222:8888; fair; }

⑤、对不同请求后缀实现负载均衡

通过 location 指定不同的后缀名实现不同的请求转发,实现负载均衡。

http { include mime.types; default_typeapplication/octet-stream; sendfileon; keepalive_timeout65; #App API服务端生产地址 upstream swjappApiProdServer { server 11.195.170.98:8399 weight=1; server 11.195.170.99:8399 weight=1; } #App API服务端测试地址 upstream swjappApiTestServer { server 11.196.170.92:8299 weight=1; server 11.196.170.93:8299 weight=1; } #IOT平台API服务端生产环境地址 upstream swjIotApiProdServer { server 11.197.170.95:9999 weight=1; server 11.197.170.96:9999 weight=1; } server { listen 8099; server_name12.198.170.92; error_loglogs/swjapp.error.log; #配置记录错误日志的文件 #配置appAPI接口生产环境访问路径 location /swapp/prod/ { proxy_pass ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } #配置IOT平台接口生产环境访问路径 location /iot/prod/ { proxy_pass ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } #配置appAPI接口测试环境访问路径 location /swapp/test/ { proxy_pass ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } #配置app测试环境上传静态文件访问目录 location /swapp/test/uploadFile/ { alias/home/augur/swapp/test/uploadFilesManager/; # 开启允许跨域访问 add_header Access-Control-Allow-Origin *; } #配置app生产环境上传静态文件访问目录 location /swapp/prod/uploadFile/ { alias/home/augur/swapp/prod/uploadFilesManager/; # 开启允许跨域访问 add_header Access-Control-Allow-Origin *; } #配置IOT平台生产环境上传静态文件访问目录 location /swjiot/prod/uploadFile/ { alias/home/augur/swjiot/prod/uploadFilesManager/; # 开启允许跨域访问 add_header Access-Control-Allow-Origin *; } #配置IOT平台测试环境上传静态文件访问目录 location /swjiot/test/uploadFile/ { alias/home/augur/swjiot/test/uploadFilesManager/; # 开启允许跨域访问 add_header Access-Control-Allow-Origin *; } #物联网平台UI location / { root /home/augur/htdocs/swjiot-ui; try_files $uri $uri/ /index.html; index index.html index.htm; } } }

三、文末小结

这一篇的内容讲的的是Nginx的具体使用,重点介绍了工作中用得最多的配置负载均衡,都是在实际工作中实战出来的经验,希望对每一个读者都有帮助。