Nginx代理服务

  1. Nginx代理服务概述
    • Nginx代理配置语法
    • Nginx正向代理示例
    • Nginx反向代理示例
  2. Nginx负载均衡
    • Nginx负载均衡配置场景
    • Nginx负载均衡状态配置
    • Nginx负载均衡调度策略
    • Nginx负载均衡TCP配置
  3. Nginx动静分离
    • Nginx动静分离应⽤案例
    • Nginx⼿机电脑应⽤案例

总结

  • 按照范围划分 : gslb和slb(调度节点和应用节点在同内网段 ,常用)
  • 按照层级划分 : 4层(代理端口)和7层(http,应用层转发)
  • 调度算法 : 轮询 , 加权轮询 , ip_hash , url_hash
  • 节点状态 : 提供支持 , 提供备份 , 不使用
  • 负载均衡 : 动静分离 , 按浏览器类型划分 , 按手机类型划分

代理复习

Nginx 作为代理服务可以实现很多的协议代理, 我们主要以 http 代理为主

1575705252430

正向代理(内部上⽹)

客户端<–>代理->服务端

1575705307271

反向代理

客户端->代理<–>服务端

1575705331731

代理区别 , 区别在于代理的对象不⼀样:

  • 正向代理代理的对象是客户端
  • 反向代理代理的对象是服务端

Nginx代理配置语法

1
2
3
Syntax: proxy_pass URL;
Default: —
Context: location, if in location, limit_except

url举例 :

类似于 nopush 缓冲区

1
2
3
4
5
# 尽可能收集所有头请求,	
Syntax: proxy_buffering on | off;
Default:	
proxy_buffering on;
Context: http, server, location
1
2
3
4
# 扩展:
proxy_buffer_size	
proxy_buffers	
proxy_busy_buffer_size

跳转重定向

在代理之后 ,去拿资源的时候,资源做一个301的跳转 , 此配置基本不用

1
2
3
4
Syntax: proxy_redirect default;
proxy_redirect off;proxy_redirect redirect replacement;
Default: proxy_redirect default;
Context: http, server, location

头信息

  • 客户端通过代理 , 访问服务端
  • 那么服务端如何知道服务端的真实地址呢 ? 使用头信息
1
2
3
4
Syntax: proxy_set_header field value;
Default: proxy_set_header Host $proxy_host;
	proxy_set_header Connection close;
Context: http, server, location
1
2
3
# 扩展:	
proxy_hide_header
proxy_set_body

代理到后端的 TCP 连接超时

1
2
3
Syntax: proxy_connect_timeout time;
Default: proxy_connect_timeout 60s;
Context: http, server, location
1
2
3
# 扩展
proxy_read_timeout # 以及建⽴
proxy_send_timeout # 服务端请求完, 发送给客户端时间

Proxy 常⻅配置项具体配置

1
2
3
4
5
6
7
8
9
10
11
12
13
# vim /etc/nginx/proxy_params
proxy_redirect	default;
proxy_set_header	Host	$http_host;
proxy_set_header	X-Real-IP	$remote_addr;
proxy_set_header	X-Forwarded-For	$proxy_add_x_forwarded_for;
proxy_connect_timeout	30;
proxy_send_timeout	60;
proxy_read_timeout	60;
proxy_buffer_size	32k;
proxy_buffering	on;
proxy_buffers	4	128k;
proxy_busy_buffers_size	256k;
proxy_max_temp_file_size	256k;

具体location实现

1
2
3
4
location / {
	proxy_pass http://127.0.0.1:8080;
	include proxy_params;
}

Nginx正向代理

Nginx 正向代理配置实例 :

  • 服务端只允许112访问
  • 客户端要想访问服务端 , 那么就要想办法让112为我代理

1575706383176

  1. 配置69.113访问限制,仅允许同⽹段访问

    1
    2
    3
    4
    5
    location ~ .*\.(jpg|gif|png)$ {
    	allow 192.168.69.0/24;
    	deny all;
    	root /soft/code/images;
    }

  2. 112配置正向代理

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    server	{
    	listen 80;
    	resolver 233.5.5.5;
    	location / {
    		# 当有人访问112的时候,就将其转发给http://$http_host$request_uri
    		proxy_pass http://$http_host$request_uri;
    		proxy_set_header Host $http_host;
    		proxy_set_header X-Real-IP $remote_addr;
    		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    	}
    }
    • $http_host : 等于 request 中 header的值 , 客户端使用代理的时候 , 需要在header里告诉代理服务器需要代理的网站 , 就放在$http_host
    • $request_uri : 就是请求url

Nginx反向代理示例

1575711501885

proxy代理 :

1
2
3
4
5
6
7
8
server	{
	listen 80;
	server_name nginx.bjstack.com;
	location / {
		proxy_pass http://192.168.56.100;
		include proxy_params;
	}
}

WEB站点 :

1
2
3
4
5
6
7
8
9
10
11
12
13
server	{
	listen 80;
	server_name nginx.bjstack.com;
	root /soft/code;
	location / {
		root /soft/code;
		index index.html;
	}
	location ~ .*\.(png|jpg|gif)$ {
		gzip on;
		root /soft/code/images;
	}
}

Nginx负载均衡

提升吞吐率, 提升请求性能, 提⾼容灾

1575711742181

负载均衡按范围划分

  • GSLB全局负载均衡
  • SLB

1575711798447

1575711812895

GSLB和SLB最大区别就是:

  • SLB的调度节点和服务节点在同一个机房,用同一个网络
  • GSLB调度节点和服务节点不在同一个网络中 , G 即global , 在不同地区设立了多个数据中心

Nginx 是⼀个典型的 SLB

负载均衡按层级划分

  • 四层负载均衡
  • 七层负载均衡

1575712179822

1575712190187

  • 这里的四层和七层就是ISO网络模型
  • 因为Nginx一般处理的HTTP转发,HTTP是应用层 , 所以 Nginx 是⼀个典型的七层 SLB
  • 同理 , 为什么Nginx还可以转发邮件 , 因为邮件协议SMTP就是在第七层
  • 第四层就是传输层 , 因此只能转发端口,ip之类的

Nginx负载均衡配置场景

Nginx 实现负载均衡⽤到了 proxy_pass 代理模块核⼼配置, 将客户端请求代理转发⾄⼀组 upstream 虚拟服务池

1575712572955

代理和负载均衡的区别

  • 代理 是Nginx将请求转发给具体的IP
  • 负载均衡 是Nginx将请求转发给虚拟服务池

举例说明就是

  • 代理 是将任务交给指定的人去做
  • 负载均衡 是将任务交给一个部门去做 , 而不去管是这个部门的哪个人去做

Nginx upstream 虚拟配置语法

1
2
3
Syntax: upstream name { ... }
Default: -
Context: http

upstream例⼦

1
2
3
4
5
6
7
8
9
10
11
upstream my_upstream {
	server backend1.example.com weight=5;
	server backend2.example.com:8080;
	server unix:/tmp/backend3;
	server backup1.example.com:8080 backup;
}
server {
	location / {
		proxy_pass http://my_upstream;
	}
}

这样 ,就会负载均衡到backend1.example.com,backend2.example.com:8080,unix:/tmp/backend3,backup1.example.com:8080 backup

Nginx负载均衡状态配置

后端服务器在负载均衡调度中的状态

状态 概述
down 当前的server暂时不参与负载均衡
backup 预留的备份服务器(当其他的都down之后才使用这个服务器)
max_fails 允许请求失败的次数(绑定fail_timeout使用)
fail_timeout 经过max_fails失败后, 服务暂停时间(绑定max_fails使用)
max_conns 限制最⼤的接收连接数 
1
2
3
4
5
6
upstream my_upstream {
	server backend1.example.com weight=5;
	server backend2.example.com:8080 down ;
	server unix:/tmp/backend3 max_fails=2 fail_timeout=5;
	server backup1.example.com:8080 backup;
}

Nginx负载均衡调度策略

调度算法 概述
轮询 按时间顺序逐⼀分配到不同的后端服务器(默认)
weight 加权轮询,weight值越⼤,分配到的访问⼏率越⾼
ip_hash 每个请求按访问IP的hash结果分配,这样来⾃同⼀IP的固定访问⼀个后端服务器
url_hash 按照访问URL的hash结果来分配请求,是每个URL定向到同⼀个后端服务器
least_conn 最少链接数,那个机器链接数少就分发
hash关键数值 hash⾃定义的key

Nginx负载均衡权重轮询具体配置 :

1
2
3
4
5
upstream load_pass {
	server 192.168.56.11:8001;
	server 192.168.56.12:8002 weight=5;
	server 192.168.56.13:8003;
}

Nginx负载均衡 ip_hash 具体配置 :

1
2
3
4
5
6
upstream load_pass {
	ip_hash;
	server 192.168.56.11:8001;
	server 192.168.56.12:8002;
	server 192.168.56.13:8003;
}

Nginx负载均衡url_hash具体配置 :

1
2
3
4
5
6
upstream load_pass {
	hash $request_uri;
	server 192.168.56.11:8001;
	server 192.168.56.12:8002;
	server 192.168.56.13:8003;
}

Nginx负载均衡TCP配置

Nginx 四层代理仅能存在于 main 段

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
# stream需定义在http外层
stream {
	upstream ssh_proxy {
		# 代理ssh
		hash $remote_addr consistent;
		server 192.168.56.103:22;
	}
	upstream mysql_proxy {
		# 代理mysql
		hash $remote_addr consistent;
		server 192.168.56.103:3306;
	}
	server {
		# 有人访问6666端口,就代理到192.168.56.103的22端口(ssh)
		listen 6666;
		proxy_connect_timeout  1s;
		proxy_timeout 300s;
		proxy_pass ssh_proxy;
	}
	server {
		# 有人访问5555端口,就代理到192.168.56.103:3306(mysql)
		listen  5555;
		proxy_connect_timeout  1s;
		proxy_timeout 300s;
		proxy_pass mysql_proxy;
	}
}

Nginx动静分离

  • 动静分离,通过中间件将动态请求和静态请求进⾏分离, 分离资源, 减少不必要的请求消耗, 减少请求延时。
  • 好处: 动静分离后, 即使动态服务不可⽤, 但静态资源不会受到影响
  • 通过中间件将动态请求和静态请求分离

1575723809932

  • 对于动态请求 , 中间件就直接将这个请求交给程序框架
  • 对于静态请求 , Nginx直接响应 , 返回数据包 . 根本没有经过程序框架
1
2
3
4
5
6
7
8
9
server{
	listen 80;
	root /soft/code;
	index index.html;
	location ~ .*\.(png|jpg|gif)$ {
		gzip on;
		root /soft/code/images;
	}
}

配置负载均衡代理调度, 实现访问 jsp 和 png

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
upstream static {
	server 192.168.69.113:80;
}
upstream java {
	server 192.168.69.113:8080;
}
server {
	listen  80;
	server_name 192.168.69.112;
	location / {
		root /soft/code;
		index index.html;
	}
	location ~ .*\.(png|jpg|gif)$ {
		proxy_pass  http://static;
		include proxy_params;
	}
	location ~ .*\.jsp$ {
		proxy_pass http://java;
		include proxy_params;
	}
}

Nginx⼿机电脑应⽤案例

根据不同的浏览器, 以及不同的⼿机, 访问的效果都将不⼀样。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 通过浏览器来分别连接不同的浏览器访问不同的效果。
http {
	...
	upstream firefox {
		server 172.31.57.133:80;
	}
	upstream chrome {
		server 172.31.57.133:8080;
	}
	upstream iphone {
		server 172.31.57.134:8080;
	}
	upstream android {
		server 172.31.57.134:8081;
	}
	upstream default {
		server 172.31.57.134:80;
	}
	...
}		
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
# server根据判断来访问不同的⻚⾯
server {
	listen 80;
	server_name www.xuliangwei.com;
	#safari浏览器访问的效果
	location / {
		if ($http_user_agent ~* "Safari"){
			proxy_pass http://dynamic_pools;
		}		
		#firefox浏览器访问效果
		if ($http_user_agent ~* "Firefox"){
			proxy_pass http://static_pools;
		}
		#chrome浏览器访问效果
		if ($http_user_agent ~* "Chrome"){
			proxy_pass http://chrome;
		}
		#iphone⼿机访问效果
		if ($http_user_agent ~* "iphone"){
			proxy_pass http://iphone;
		}
		#android⼿机访问效果
		if ($http_user_agent ~* "android"){
			proxy_pass http://and;
		}
		#其他浏览器访问默认规则
		proxy_pass http://dynamic_pools;
		include proxy.conf;
		}
	}
}