Nginx反向代理与负载均衡

时间  2019-11-21
标签 nginx 反向 代理 负载 均衡 栏目 Nginx 繁體版
原文   原文链接

Nginx反向代理与负载均衡

 

集群简介

简单地说，集群就是指一组（若干个）相互独立的计算机，利用高速通讯网络组成的一个较大的计算机服务系统，每一个集群节点（即集群中的每台计算机）都是运行各自服务的独立服务器。这些服务器之间能够彼此通讯，协同向用户提供应用程序，系统资源和数据，并以单一系统的模式加以管理。当用户客户机请求集群系统时，集群给用户的感受就是一个单一独立的服务器，而实际上用户请求的是一组集群服务器。php

打开谷歌，百度的页面，看起来好简单，也许你以为用几分钟就能够制做出类似的网页，而实际上，这个页面的背后是由成千上万台服务器集群协同工做的结果。而这么多的服务器维护和管理，以及相互协调工做也许就是同窗们将来的工做职责了。html

若要用一句话描述集群，即一堆服务器合做作同一件事，这些机器可能须要整个技术团队架构，设计和统一协调管理，这些机器能够分布在一个机房，也能够分布在全国全球各个地区的多个机房。前端

 

为何要使用集群

（1）高性能nginx

一些国家重要的计算密集型应用（如天气预报，核试验模拟等），须要计算机有很强的运算处理能力。以全世界现有的技术，即便是大型机，其计算能力也是有限的，很难单独完成此任务。由于计算时间可能会至关长，也许几天，甚至几年或更久。所以，对于这类复杂的计算业务，便使用了计算机集群技术，集中几十上百台，甚至成千上万台计算机进行计算。web

假如你配一个LNMP环境，每次只须要服务10个并发请求，那么单台服务器必定会比多个服务器集群要快。只有当并发或总请求数量超过单台服务器的承受能力时，服务器集群才会体现出优点。算法

集群高性能。.png-273.6kB

（2）价格有效性数据库

一般一套系统集群架构，只须要几台或数十台服务器主机便可。与动辄价值上百万元的专用超级计算机相比便宜了不少。在达到一样性能需求的条件下，采用计算机集群架构比采用同等运算能力的大型计算机具备更高的性价比。编程

早期的淘宝，支付宝的数据库等核心系统就是使用上百万元的小型机服务器。后因使用维护成本过高以及扩展设备费用成几何级数翻倍，甚至成为扩展瓶颈，人员维护也十分困难，最终使用PC服务器集群替换之，好比，把数据库系统从小机结合Oracle数据库迁移到MySQL开源数据库结合PC服务器上来。不但成本降低了，扩展和维护也更容易了。vim

（3）可伸缩性windows

当服务负载，压力增加时，针对集群系统进行较简单的扩展便可知足需求，且不会下降服务质量。

一般状况下，硬件设备若想扩展性能，不得不增长新的CPU和存储器设备，若是加不上去了，就不得不够买更高性能的服务器，就拿咱们如今的服务器来说，能够增长的设备老是有限的。若是采用集群技术，则只须要将新的单个服务器加入现有集群架构中便可，从访问的客户角度来看，系统服务不管是连续性仍是性能上都几乎没有变化，系统在不知不觉中完成了升级，加大了访问能力，轻松地实现了扩展。集群系统中的节点数目能够增加到几千乃至上万个，其伸缩性远超过单台超级计算机。

（4）高可用性

单一的计算机系统总会面临设备损毁的问题，如CPU，内存，主板，电源，硬盘等，只要一个部件坏掉，这个计算机系统就可能会宕机，没法正常提供服务。在集群系统中，尽管部分硬件和软件也仍是会发生故障，但整个系统的服务能够是7*24小时可用的。

集群架构技术可使得系统在若干硬件设备故障发生时仍能够继续工做，这样就将系统的停机时间减小到了最小。集群系统在提升系统可靠性的同时，也大大减少了系统故障带来的业务损失，目前几乎100%的互联网网站都要求7*24小时提供服务。

（5）透明性

多个独立计算机组成的松耦合集群系统构成一个虚拟服务器。用户或客户端程序访问集群系统时，就像访问一台高性能，高可用的服务器同样，集群中一部分服务器的上线，下线不会中断整个系统服务，这对用户也是透明的。

（6）可管理性

整个系统可能在物理上很大，但其实容易管理，就像管理一个单一映像系统同样。在理想情况下，软硬件模块的插入能作到即插即用。

（7）可编程性

在集群系统上，容易开发及修改各种应用程序。

 

集群的常见分类

负载均衡集群，简称LBC或者LB

高可用性集群，简称HAC --->预防单点也就是高可用

高性能计算集群，简称HPC

网格计算集群

负载均衡集群和高可用性集群是互联网行业经常使用的集群架构模式，也是咱们要学习的重点。

 

负载均衡集群的做用

分摊用户访问请求及数据流量（负载均衡）

保持业务连续性，即7*24小时服务（高可用性）

应用于Web业务及数据库从库等服务器的业务

负载均衡集群典型的开源软件包括LVS，Nginx，Haproxy等，以下图所示

负载均衡集群。.png-200.1kB

 

负载均衡集群介绍

负载均衡集群为企业提供了更为实用，性价比更高的系统架构解决方案。负载均衡集群能够把不少客户集中的访问请求负载压力尽量平均地分摊在计算机集群中处理。客户访问请求负载一般包括应用程序处理负载和网络流量负载。这样的系统很是适合使用同一组应用程序为大量用户提供服务的模式，每一个节点均可以承担必定的访问请求负载压力，而且能够实现访问请求在各节点之间动态分配，以实现负载均衡。

负载均衡集群运行时，通常是经过一个或多个前端负载均衡器将客户访问请求分发到后端的一组服务器上，从而达到整个系统的高性能和高可用性。通常高可用性集群和负载均衡集群会使用相似的技术，或同时具备高可用性与负载均衡的特色。

 

高可用性集群的做用

当一台机器宕机时，另一台机器接管宕机的机器的IP资源和服务资源，提供服务。

经常使用于不易实现负载均衡的应用，好比负载均衡器，主数据库，主存储对之间。

高可用性集群经常使用的开源软件包括Keepalived，Heartbeat等，其架构图以下图所示

高可用性集群。.png-205.4kB

 

高可用性集群介绍

通常是指在集群中任意一个节点失效的状况下，该节点上的全部任务会自动转移到其余正常的节点上。此过程并不影响整个集群的运行。

当集群中的一个节点系统发生故障时，运行着的集群服务会迅速做出反应，将该系统的服务分配到集群中其余正在工做的系统上运行。考虑到计算机硬件和软件的容错性，高可用性集群的主要目的是使集群的总体服务尽量可用。若是高可用性集群中的主节点发生了故障，那么这段时间内将由备节点代替它。备节点一般是主节点的镜像。当它代替主节点时，它能够彻底接管主节点（包括IP地址及其余资源）提供服务，所以，使集群系统环境对于用户来讲是一致的，既不会影响用户的访问。

高可用性集群使服务器系统的运行速度和响应速度会尽量的快。他们常常利用在多台机器上运行的冗余节点和服务来相互跟踪。若是某个节点失败，它的替补者将在几秒钟或更短期内接管它的职责。所以，对于用户而言，集群里的任意一台机器宕机，业务都不会受影响（理论状况下）。

 

Nginx负载均衡集群介绍

 

搭建负载均衡服务的需求

负载均衡集群提供了一种廉价，有效，透明的方法，来扩展网络设备和服务器的负载，带宽和吞吐量，同时增强了网络数据处理能力，提升了网络的灵活性和可用性。

搭建负载均衡服务的需求以下

（1）把单台计算机没法承受的大规模并发访问或数据流量分担到多台节点设备上，分别进行处理，减小用户等待响应的时间，提高用户体验。

（2）单个重负载的运算分担到多台节点设备上作并行处理，每一个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力获得大幅度提升。

（3）7*24小时的服务保证，任意一个或多个有限后面节点设备宕机，不能影响业务。

在负载均衡集群中，同组集群的全部计算机节点都应该提供相同的服务。集群负载均衡器会截获全部对该服务的入站请求。而后将这些请求尽量地平均地分配在全部集群节点上。

 

反向代理与负载均衡概念简介

 

反向代理与负载均衡概念简介

严格地说，Nginx仅仅是做为Nginx Proxy反向代理使用的，由于这个反向代理功能表现的效果是负载均衡集群的效果，因此本文称之为Nginx负载均衡。那么，反向代理和负载均衡有什么区别呢？

普通负载均衡软件，例如大名鼎鼎的LVS，其实功能只是对请求数据包的转发（也可能会改写数据包），传递，其中DR模式明显的特征是从负载均衡下面的节点服务器来看，接收到的请求仍是来自访问负载均衡器的客户端的真实用户，而反向代理就不同了，反向代理接收访问用户的请求后，会代理用户从新发起请求代理下的节点服务器，最后把数据返回给客户端用户，在节点服务器看来，访问的节点服务器的客户端用户就是反向代理服务器了，而非真实的网站访问用户。

一句话，LVS等的负载均衡是转发用户请求的数据包，而Nginx反向代理是接收用户的请求而后从新发起请求去请求其后面的节点。

Nginx是七层结构的,经过nginx自己来转发,能够有多种方式进行负载均衡,实现的功能多,nginx能够分业务

LVS是四层结构的,经过转发数据包mac或ip头部,不能对数据进行修改,来实现的负载均衡,实现的功能少但效率高,LVS的WEB内容都给是同样的

 

实现Nginx负载均衡的组件主要有两个，以下表

负债均衡组件。.png-45.9kB

 

反向代理与负载均衡搭建

 

硬件准备

准备3台VM虚拟机（有物理服务器更佳）都须要安装Nginx服务

Nginx反向代理

NginxWebA

NginxWebB

image_1crp57ne91mjek0c1q9v1js41iahs.png-6.8kB

 

安装依赖软件包

yum -y install openssl openssl-devel pcre pcre-devel

rpm -qa openssl openssl-devel pcre pcre-devel

三台都须要安装支持包

image_1crp58vobfo7pno7v71usl9pq19.png-20.2kB

 

软件包准备

nginx-1.10.2.tar.gz

image_1crp5ad1rtscc221q9v1hm51j9v1m.png-10.5kB

 

安装Nginx服务

useradd -M -s /sbin/nologin nginx

tar xf nginx-1.10.2.tar.gz -C /usr/src

cd /usr/src/nginx-1.10.2

./configure --user=nginx --group=nginx --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module && make && make install

ln -s /usr/local/nginx/sbin/* /usr/local/sbin/ --->软连接可作可不作

egrep -v "#|^$" nginx.conf.default > nginx.conf --->把配置文件多余的东西过滤掉

这里只编译了一个截图,三台虚拟机的步骤都是同样的

image_1crp6k368e75d611ho2oud9mm9.png-51.9kB

 

简单的Nginx反向代理配置文件

 
  1. worker_processes 1;
  2. events {
  3. worker_connections 1024;
  4. }
  5. http {
  6. include mime.types;
  7. default_type application/octet-stream;
  8. sendfile on;
  9. keepalive_timeout 65;
  10. upstream www_server {
  11. server 192.168.200.68:80 weight=1;
  12. server 192.168.200.69:80 weight=1;
  13. }
  14. server {
  15. listen 80;
  16. server_name sl.yunjisuan.com;
  17. location / {
  18. proxy_pass http://www_server;
  19. }
  20. }
  21. }
 

配置文件详解

 
  1. #这里定义Web服务器池，包含了68，69两个Web节点
  3. upstream --->服务器池
  5. www_server --->是服务器池的名字
  7. server --->就是一个RS节点
  9. weight --->权重,负载均衡是按照权重比分配的
  11. #这里定义代理的负载均衡域名虚拟主机
  13. proxy_pass --->访问sl.yunjisuan.com,请求发送给www_server里面的
 

WEBA配置文件

 
  1. worker_processes 1;
  2. events {
  3. worker_connections 1024;
  4. }
  5. http {
  6. include mime.types;
  7. default_type application/octet-stream;
  8. sendfile on;
  9. keepalive_timeout 65;
  10. server_tokens off;
  11. server {
  12. listen 80;
  13. server_name bbs.yunjisuan.com;
  14. location / {
  15. root html/bbs;
  16. index index.html index.htm;
  17. }
  18. }
  19. server {
  20. listen 80;
  21. server_name sl.yunjisuan.com;
  22. location / {
  23. root html/sl;
  24. index index.html index.htm;
  25. }
  26. }
  27. }

WEBB跟WEBA配置文件是同样的

 

填充测试文件

 
  1. mkdir /usr/local/nginx/html/{sl,bbs}
  3. echo "`hostname -I ` sl" >> /usr/local/nginx/html/sl/index.html
  5. echo "`hostname -I ` bbs" >> /usr/local/nginx/html/bbs/index.html

WEBB跟WEBA测试文件是同样的

 

添加WEB-A和B虚拟机本地映射

vim /etc/hosts

cat /etc/hosts

image_1crrauh48kkq1ke212k313vu1ftc1p.png-19.5kB

image_1crrauu0c19j9mhh16q4q083h726.png-19.6kB

 

配置完两台WEB服务器用curl测试一下

curl sl.yunjisuan.com

curl bbs.yunjisuan.com

image_1crrb5917g3d14li1hhk1k9065l2j.png-16.3kB

image_1crrb5n6nf1b1bh4jj1bqj22m3g.png-16.9kB

 

检查两台WEB简单的负载均衡测试结果

curl sl.yunjisuan.com

测试结果能够看出来。两个Web节点按照1：1的比例被访问

image_1crrbvs7i1lm79udopc1ti81p553t.png-32.8kB

 

Nginx upstream模块介绍

Nginx的负载均衡功能依赖于ngx_http_upsteam_module模块，所支持的代理方式包括proxy_pass,fastcgi_pass,memcached_pass等,新版Nginx软件支持的方式有所增长。本文主要讲解proxy_pass代理方式。

ngx_http_upstream_module模块容许Nginx定义一组或多组节点服务器组，使用时能够经过proxy_pass代理方式把网站的请求发送到事先定义好的对应Upstream组的名字上，具体写法为“proxy_pass http:// www_server_pools”,其中www_server_pools就是一个Upstream节点服务器组名字。ngx_http_upstream_module模块官方地址为：http://nginx.org/en/docs/http/ngx_http_upstream_module.html

 

基本的upstream配置案例

 
  1. upstream www_server_pools {
  2. # upstream是关键字必须有，后面的www_server_pools为一个Upstream集群组的名字，能够本身起名，调用时就用这个名字
  4. server 192.168.0.223:80 weight=5;
  5. server 192.168.0.224:80 weight=10;
  6. server 192.168.0.225:80 weight=15;
  7. # server关键字是固定的，后面能够接域名（门户会用）或IP。若是不指定端口，默认是80端口。weight表明权重，数值越大被分配的请求越多，结尾有分号，别忘了。
  8. }
 

较完整的upstream配置案例

 
  1. upstream blog_server_pool {
  2. server 192.168.0.223; #这行标签和下行是等价的
  3. server 192.168.0.224:80 weight=1 max_fails=1 fail_timeout=10s; #这行标签和上一行是等价的，此行多余的部分就是默认配置，不写也能够。
  4. server 192.168.0.225:80 weight=1 max_fails=2 fail_timeout=20s backup;
  5. # server最后面能够加不少参数，具体参数做用看下文的表格
  6. }
 

使用域名及socket的upstream配置案例

 
  1. upstream backend {
  3. server backend1.example.com weight=5;
  4. server backend2.example.com:8080; #域名加端口。转发到后端的指定端口上
  5. server unix:/tmp/backend3; #指定socket文件
  6. #提示：server后面若是接域名，须要内网有DNS服务器或者在负载均衡器的hosts文件作域名解析。
  8. server 192.168.0.223;
  9. server 192.168.0.224:8080;
  10. server backup1.example.com:8080 backup;
  12. #备份服务器，等上面指定的服务器都不可访问的时候会启动，backup的用法和Haproxy中用法同样
  13. server backup2.example.com:8080 backup;
  14. }
 

权重比测试

 
  1. worker_processes 1;
  2. events {
  3. worker_connections 1024;
  4. }
  5. http {
  6. include mime.types;
  7. default_type application/octet-stream;
  8. sendfile on;
  9. keepalive_timeout 65;
  10. upstream www_server {
  11. server 192.168.200.68:80 weight=5;
  12. server 192.168.200.69:80 weight=1;
  13. }
  14. server {
  15. listen 80;
  16. server_name sl.yunjisuan.com;
  17. location / {
  18. proxy_pass http://www_server;
  19. }
  20. }
  21. }

测试阶段多少会有点延迟,全部显示的会不太准确

image_1crrid56v1apt15b861qrg6dtc8k.png-64.5kB

 

backup备份测试

 
  1. worker_processes 1;
  2. events {
  3. worker_connections 1024;
  4. }
  5. http {
  6. include mime.types;
  7. default_type application/octet-stream;
  8. sendfile on;
  9. keepalive_timeout 65;
  10. upstream www_server {
  11. server 192.168.200.68:80 weight=1 backup;
  12. server 192.168.200.69:80 weight=1;
  13. }
  14. server {
  15. listen 80;
  16. server_name sl.yunjisuan.com;
  17. location / {
  18. proxy_pass http://www_server;
  19. }
  20. }
  21. }

image_1crriptk41a25150i3lm834ba9h.png-40.7kB

image_1crriq7ua4ig1pped9rg7j1brs9u.png-14.5kB

 

特别提示

若是是两台Web服务器作高可用，常规方案就须要keepalived配合，那么这里使用Nginx的backup参数经过负载均衡功能就能够实现Web服务器集群了，对于企业应用来讲，能作集群就不作高可用。

 

upstream模块相关说明

upstream模块的内容应放于nginx.conf配置的http{}标签内，其默认调度节点算法是wrr(weighted round-robin，即权重轮询)。下图为upstream模块内部server标签部分参数说明

image_1crrd4dae1loa19ok1h1el1815cm4a.png-433.8kB

提示： 
以上参数与专业的Haproxy参数很相似，但不如Haproxy的参数易懂。

 

示例，以下

 
  1. upstream backend {
  3. server backend1.example.com weight=5; #若是就是单个Server，不必设置权重
  4. server 127.0.0.1:8080 max_fail=5 fail_timeout=10s;
  5. #当检测次数等于5的时候，5次连续检测失败后，间隔10s再从新检测。
  6. server unix:/tmp/backend3;
  7. server backup1.example.com:8080 backup; #热备机器设置
  8. }
 

hash算法访问

 
  1. upstream backend {
  2. ip_hash;
  3. server backend1.example.com;
  4. server backend2.example.com;
  5. server backend3.example.com down;
  6. server backend4.example.com;
  7. }

须要特别说明的是，若是是Nginx代理Cache服务，可能须要使用hash算法，此时若宕机，可经过设置down参数确保客户端用户按照当前的hash算法访问，这一点很重要

 

开启对后端服务器的健康检测

 
  1. #开启对后端服务器的健康检测，经过GET /test/index.php来判断后端服务器的健康状况
  2. server php_server_1 192.168.0.223:80 cookie 1 check inter 2000 rise 3 fall 3 weight 2
  3. server php_server_2 192.168.0.224:80 cookie 2 check inter 2000 rise 3 fall 3 weight 1
  4. server php_server_bak 192.168.0.225:80 cookie 3 check inter 1500 rise 3 fall 3 backup
 

健康检测命令详解

 
  1. weight:调节服务器的请求分配权重。
  3. check：开启对该服务器健康检查。
  5. inter：设置连续两次的健康检查间隔时间，单位毫秒，默认值2000
  7. rise：指定多少次连续成功的健康检查后，便可认定该服务器处于可用状态。
  9. fall:指定多少次不成功的健康检查后，即认为服务器为宕机状态，默认值3.
  11. maxconn：指定可被发送到该服务器的最大并发链接数。
 

upstream模块调度算法

调度算法通常分为两类： 
第一类为静态调度算法，即负载均衡器根据自身设定的规则进行分配，不须要考虑后端节点服务器的状况，例如：rr,wrr,ip_hash等都属于静态调度算法。 
第二类为动态调度算法，即负载均衡器会根据后端节点的当前状态来决定是否分发请求，例如：链接数少的优先得到请求，响应时间短的优先得到请求。例如：least_conn,fair等都属于动态调度算法。

（1） rr轮询（默认调度算法，静态调度算法）

按客户端请求顺序把客户端的请求逐一分配到不一样的后端节点服务器，这至关于LVS中的rr算法，若是后端节点服务器宕机（默认状况下Nginx只检测80端口），宕机的服务器会被自动从节点服务器池中剔除，以使客户端的用户访问不受影响。新的请求会分配给正常的服务器。

（2）wrr（权重轮询，静态调度算法）

在rr轮询算法的基础上加上权重，即为权重轮询算法，当使用该算法时，权重和用户访问成正比，权重值越大，被转发的请求也就越多。能够根据服务器的配置和性能指定权重值大小，有效解决新旧服务器性能不均带来的请求分配问题。

（3）ip_hash（静态调度算法）（会话保持）

每一个请求按客户端IP的hash结果分配，当新的请求到达时，先将其客户端IP经过哈希算法哈希出一个值，在随后的客户端请求中，客户IP的哈希值只要相同，就会被分配至同一台服务器，该调度算法能够解决动态网页的session共享问题，但有时会致使请求分配不均，即没法保证1：1的负载均衡，由于在国内大多数公司都是NAT上网模式，多个客户端会对应一个外部IP，因此，这些客户端都会被分配到同一节点服务器，从而致使请求分配不均。LVS负载均衡的-p参数，Keepalived配置里的persistence_timeout 50参数都相似这个Nginx里的ip_hash参数，其功能均可以解决动态网页的session共享问题。

当负载调度算法为ip_hash时，后端服务器在负载均衡调度中的状态不能有weight和backup，即便有也不会生效。

 
  1. upstream yunjisuan_lb{
  2. ip_hash;
  3. server 192.168.0.223:80;
  4. server 192.168.0.224:8080;
  5. }
  6. upstream backend{
  7. ip_hash;
  8. server backend1.example.com;
  9. server backend2.example.com;
  10. server backend3.example.com down;
  11. server backend4.example.com;
  12. }

（4）fair（动态调度算法）

此算法会根据后端节点服务器的响应时间来分配请求，响应时间短的优先分配。这是更加智能的调度算法。此种算法能够根据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。Nginx自己不支持fair调度算法，若是须要使用这种调度算法，必须下载Nginx相关模块upstream_fair。

 
  1. upstream yunjisuan_lb{
  2. server 192.168.0.223;
  3. server 192.168.0.224;
  4. fair;
  5. }

（5）least_conn(最小链接)

least_conn算法会根据后端节点的链接数来决定分配状况，哪一个机器链接数少就分发。 
除了上面介绍的这些算法外，还有一些第三方调度算法，例如：url_hash,一致性hash算法等，介绍以下。

（6）url_hash算法(web缓存节点)

与ip_hash相似，这里是根据访问URL的hash结果来分配请求的，让每一个URL定向到同一个后端服务器，后端服务器为缓存服务器时效果显著。在upstream中加入hash语句，server语句中不能写入weight等其余的参数，hash_method使用的是hash算法。

url_hash按访问URL的hash结果来分配请求，使每一个URL定向到同一个后端服务器，能够进一步提升后端缓存服务器的效率命令率。Nginx自己是不支持url_hash的，若是须要使用这种调度算法，必须安装Nginx的hash模块软件包。

 
  1. upstream yunjisuan_lb {
  2. server squid1:3128;
  3. server squid2:3128;
  4. hash $request_uri;
  5. hash_method crc32;
  6. }

（7）一致性hash算法(Nginx没有)

一致性hash算法通常用于代理后端业务为缓存服务（如Squid，Memcached）的场景，经过将用户请求的URI或者指定字符串进行计算，而后调度到后端的服务器上，此后任何用户查找同一个URI或者指定字符串都会被调度到这一台服务器上，所以后端的每一个节点缓存的内容都是不一样的，一致性hash算法能够解决后端某个或几个节点宕机后，缓存的数据动荡最小，一致性hash算法知识比较复杂，详细内容能够参考百度上的相关资料，这里仅仅给出配置示例

 
  1. http {
  2. upstream test {
  3. consistent_hash $request_uri;
  4. server 127.0.0.1:9001 id=1001 weight=3;
  5. server 127.0.0.1:9002 id=1002 weight=10;
  6. server 127.0.0.1:9003 id=1003 weight=20;
  7. }
  8. }

虽然Nginx自己不支持一致性hash算法，但Nginx得分支Tengine支持。详细可参考http://tengine.taobao.org/document_cn/http_upstream_consistent_hash_cn.html

 

http_proxy_module模块

 

proxy_pass指令介绍

proxy_pass指令属于ngx_http_proxy_module模块，此模块能够将请求转发到另外一台服务器，在实际的反向代理工做中，会经过location功能匹配指定的URI，而后把接收到的符合匹配URI的请求经过proxy_pass抛给定义好的upstream节点池。该指令官方地址1见：http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

 

proxy_pass的使用案例

（1）将匹配URI为name的请求抛给http://127.0.0.1/remote/

 
  1. location /name/ {
  2. proxy_pass http://127.0.0.1/remote/;
  3. }

（2）将匹配URI为some/path的请求抛给http://127.0.0.1

 
  1. location /some/path/ {
  2. proxy_pass http://127.0.0.1;
  3. }

（3）将匹配URI为name的请求应用指定的rewrite规则，而后抛给http://127.0.0.1

 
  1. location /name/ {
  2. rewrite /name/( [^/]+ ) /username=$1 break;
  3. proxy_pass http://127.0.0.1;
  4. }
 

http proxy模块参数详解

Nginx的代理功能是经过http proxy模块来实现的。默认在安装Nginx时已经安装了http proxy模块，所以可直接使用http proxy模块。下面详细解释模块1中每一个选项表明的含义，见下表

image_1crrhm9b11fmi1oe2gerr1mlah4n.png-368kB

 

反向代理多虚拟主机节点服务器测试

从测试结果能够看出，已经实现了反向代理，负载均衡功能，可是有一个特殊问题，出来的结果并非带有sl的字符串，而是bbs的字符串，根据访问结果，咱们推测是访问了Web节点下bbs的虚拟主机，明明代理的是sl虚拟主机，为何结果是访问了后端的bbs虚拟主机

image_1crrnbfkn530581163m4n8g9.png-19.9kB

缘由是当用户访问域名时确实是携带了sl.yunjisuan.com主机头请求Nginx反向代理服务器，可是反向代理向下面节点从新发起请求时，默认并无在请求头里告诉节点服务器要找哪台虚拟主机，因此，Web节点服务器接收到请求后发现没有主机头信息，所以，就把节点服务器的第一个虚拟主机发给了反向代理了（节点上第一个虚拟主机放置的是故意这样放置的bbs）。解决这个问题的方法，就是当反向代理向后从新发起请求时，要携带主机头信息，以明确告诉节点服务器要找哪一个虚拟主机。具体的配置很简单，就是在Nginx代理sl服务虚拟主机配置里增长以下一行配置便可：

proxy_set_header host $host;

 
  1. worker_processes 1;
  2. events {
  3. worker_connections 1024;
  4. }
  5. http {
  6. include mime.types;
  7. default_type application/octet-stream;
  8. sendfile on;
  9. keepalive_timeout 65;
  10. upstream www_server {
  11. server 192.168.200.68:80 weight=1;
  12. server 192.168.200.69:80 weight=1;
  13. }
  14. server {
  15. listen 80;
  16. server_name sl.yunjisuan.com;
  17. location / {
  18. proxy_pass http://www_server;
  19. proxy_set_header host $host;
  20. }
  21. }
  22. }

image_1crrnom2k1c6t1kp9q5krrf17ne16.png-26.6kB

 

反向代理后的节点服务器记录用户IP测试

测试会发现，节点服务器对应的sl虚拟主机的访问日志的第一个字段记录的并非客户端的IP，而是反向代理服务器的IP，最后一个字段也是“-”！

image_1crro073pbiq1j6opvtmru9pd1j.png-31.5kB

解决办法一样是在反向代理服务器增长以下一行参数：

proxy_set_header X-Forwarded-For $remote_addr;

这是反向代理时，节点服务器获取用户真实IP的必要功能配置

在反向代理请求后端节点服务器的请求头中增长获取的客户端IP的字段信息，而后节点后端能够经过程序或者相关的配置接收X-Forwarded-For传过来的用户真实IP的信息。

 
  1. worker_processes 1;
  2. events {
  3. worker_connections 1024;
  4. }
  5. http {
  6. include mime.types;
  7. default_type application/octet-stream;
  8. sendfile on;
  9. keepalive_timeout 65;
  10. upstream www_server {
  11. server 192.168.200.68:80 weight=1;
  12. server 192.168.200.69:80 weight=1;
  13. }
  14. server {
  15. listen 80;
  16. server_name sl.yunjisuan.com;
  17. location / {
  18. proxy_pass http://www_server;
  19. proxy_set_header host $host;
  20. proxy_set_header X-Forwarded-For $remote_addr;
  21. }
  22. }
  23. }

image_1crrp7d581kob2m3auqtl1kdc40.png-24.5kB

特别注意，虽然反向代理已经配好了，可是节点服务器(WEBA和B)须要的访问日志若是要记录用户的真实IP，还必须进行日志格式配置，这样才能把代理传过来的X-Forwarded-For头信息记录下来，具体配置为

WEBA和WEBA配置文件是同样的只是IP不一样

 
  1. worker_processes 1;
  2. events {
  3. worker_connections 1024;
  4. }
  5. http {
  6. include mime.types;
  7. default_type application/octet-stream;
  8. sendfile on;
  9. keepalive_timeout 65;
  10. server_tokens off;
  11. log_format main '$remote_addr-$remote_user[$time_local]"$request"'
  12. '$status $body_bytes_sent "$http_referer"'
  13. '"$http_user_agent""$http_x_forwarded_for"';
  14. server {
  15. listen 80;
  16. server_name bbs.yunjisuan.com;
  17. location / {
  18. root html/bbs;
  19. index index.html index.htm;
  20. }
  21. access_log logs/access_bbs.log main;
  22. }
  23. server {
  24. listen 80;
  25. server_name sl.yunjisuan.com;
  26. location / {
  27. root html/sl;
  28. index index.html index.htm;
  29. }
  30. access_log logs/access_sl.log main;
  31. }
  32. }
  34. 配置文件详解
  36. log_format --->记录字段顺序
  38. $remote_addr --->来源IP
  40. $remote_user --->来源用户
  42. [$time_local] --->来源时间
  44. $request --->请求
  46. $status --->状态码
  48. $body_bytes_sent --->主体,发送的大小
  50. $http_referer --->来源的浏览器
  52. $http_user_agent --->用户的客户端
  54. $http_x_forwarded_for --->这是反向代理时，节点服务器获取用户真实IP的必要功能配置
  55. 若是但愿在第一行显示，能够替换掉第一行的$remote_addr变量

image_1crrq5nj9iph1ue21e3o17lj170n4d.png-25.5kB

 

清空NginxWEBA和B日志文件并在浏览器输入域名测试

 
  1. cd /usr/local/nginx/logs
  3. > access_bbs.log
  5. > access_sl.log
  7. 没在WINDOWS作映射的话先去作一下
  9. 由于虚拟机是NAT模式,因此真实IP是网关IP

image_1crrrjrcptlm1nr2bphc7h1uk9ig.png-11.1kB

image_1crrqfg1rr4s10r2193b30v1n4d4q.png-63.3kB

 

反向代理相关重要基础参数的总结

image_1crrqlv1gqk5mbsu4m1r8h1qn757.png-202.4kB

 

配置文件用include方式包含到虚拟主机配置里

cd /usr/local/nginx/conf

touch proxy.conf

把下面的重要参数放到proxy.conf在反向代理配置文件用include方式调用

 
  1. proxy_set_header host $host;
  2. proxy_set_header x-forwarded-for $remote_addr;
  3. proxy_connect_timeout 60;
  4. proxy_send_timeout 60;
  5. proxy_read_timeout 60;
  6. proxy_buffer_size 4k;
  7. proxy_buffers 4 32k;
  8. proxy_busy_buffers_size 64k;
  9. proxy_temp_file_write_size 64k;
 
  1. worker_processes 1;
  2. events {
  3. worker_connections 1024;
  4. }
  5. http {
  6. include mime.types;
  7. default_type application/octet-stream;
  8. sendfile on;
  9. keepalive_timeout 65;
  10. upstream www_server {
  11. server 192.168.200.68:80 weight=1;
  12. server 192.168.200.69:80 weight=1;
  13. }
  14. server {
  15. listen 80;
  16. server_name sl.yunjisuan.com;
  17. location / {
  18. proxy_pass http://www_server;
  19. include proxy.conf;
  20. }
  21. }
  22. }

image_1crrr9ve81cpc4lt1r401qkl1iol5k.png-49kB

 

include方式在windows浏览器测试

image_1crrrhevo1r1sokc9sj155krl9e5.png-13kB

image_1crrrgchr16g01dem5m0u461ei4b5.png-61.2kB

 

根据URL中的目录地址实现代理转发

经过Nginx实现动静分离，即经过Nginx反向代理配置规则实现让动态资源和静态资源及其余业务分别由不一样的服务器解析，以解决网站性能，安全，用户体验等重要问题。

下图为企业常见的动静分离集群架构图，此架构图适合网站前端只使用同一个域名提供服务的场景，例如，用户访问的域名是www.yunjisuan.com，而后，当用户请求www.yunjisuan.com/upload/xx地址时候，代理会分配请求到上传服务器池处理数据；当用户请求www.yunjisuan.com/static/xx地址的时候，代理会分配请求到静态服务器池请求数据；当用户请求www.yunjisuan.com/xx地址的时候，即不包含上述指定的目录地址路径时，代理会分配请求到默认的动态服务器池请求数据（注意：上面的xx表示任意路径）。

image_1crrrvrm0ilb1v2mivbr6k1jvqk9.png-197.1kB

 

根据URL方式测试反向代理服务器配置文件以下

WEBA请求sl.yunjisuan.com/static/xx地址时，实现由静态服务器池处理请求。(192.168.200.68)

WEBB请求sl.yunjisuan.com/upload/xx地址时，实现由upload上传服务器池处理请求。(192.168.200.69)

WEBC其余访问请求，全都由默认的动态服务器池处理请求。(192.168.200.75)

include方式调用的文件

 

以location方案实现

 
  1. worker_processes 1;
  2. events {
  3. worker_connections 1024;
  4. }
  5. http {
  6. include mime.types;
  7. default_type application/octet-stream;
  8. sendfile on;
  9. keepalive_timeout 65;
  10. upstream default {
  11. server 192.168.200.75:80 weight=1;
  12. }
  13. upstream static {
  14. server 192.168.200.68:80 weight=1;
  15. }
  16. upstream upload {
  17. server 192.168.200.69:80 weight=1;
  18. }
  19. server {
  20. listen 80;
  21. server_name sl.yunjisuan.com;
  22. location / {
  23. proxy_pass http://default;
  24. include proxy.conf;
  25. }
  26. location /static/ {
  27. proxy_pass http://static;
  28. include proxy.conf;
  29. }
  30. location /upload/ {
  31. proxy_pass http://upload;
  32. include proxy.conf;
  33. }
  34. }
  35. }
 

以if语句实现

 
  1. worker_processes 1;
  2. events {
  3. worker_connections 1024;
  4. }
  5. http {
  6. include mime.types;
  7. default_type application/octet-stream;
  8. sendfile on;
  9. keepalive_timeout 65;
  10. upstream default {
  11. server 192.168.200.75:80 weight=1;
  12. }
  13. upstream static {
  14. server 192.168.200.68:80 weight=1;
  15. }
  16. upstream upload {
  17. server 192.168.200.69:80 weight=1;
  18. }
  19. server {
  20. listen 80;
  21. server_name sl.yunjisuan.com;
  22. location / {
  23. proxy_pass http://default;
  24. include proxy.conf;
  25. if ($request_uri ~* "^/static/(.*)$"){
  26. proxy_pass http://static/$1;
  27. }
  28. if ($request_uri ~* "^/upload/(.*)$"){
  29. proxy_pass http://upload/$1;
  30. }
  31. }
  32. }
  33. }

image_1crrvudmd1cqo9v41stst1e2a01g.png-50.9kB

 

WEBA静态测试结果(curl方式)

cd /usr/local/nginx/html

cd sl

mkdir static

echo "static" > static/index.html

curl http://sl.yunjisuan.com/static/

image_1crs07hf3s9n2mo1lvl4lf74s1t.png-39.3kB

 

WEBB上传测试结果(curl方式)

cd /usr/local/nginx/html

cd sl

mkdir upload

echo "upload" > upload/index.html

curl http://sl.yunjisuan.com/upload/

image_1crs0gcdf11dg1r9qdh112bhiev2a.png-40.2kB

 

WEBC默认测试结果(curl方式)

cd /usr/local/nginx/html

echo "default" > default/index.html

curl http://sl.yunjisuan.com

image_1crs16hjl1n83ktp1j2b19tfpek34.png-35.2kB

 

windows全部网页测试结果

http://sl.yunjisuan.com

http://sl.yunjisuan.com/static/index.html

http://sl.yunjisuan.com/upload/index.html

image_1crs1d37812ngvpu3abmpr17rg4b.png-11kB

image_1crs1djt81aggvqmqdtg1u1atq4o.png-14.1kB

image_1crs1eam71t7i1ombvoa1lou32555.png-13.4kB

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程