一、背景
以往使用Nginx分流后台服务的,大多使用http模块配合serve_name进行分流,大多适用于http/https场景。今天发现还有种使用stream模块的分流方式,这里做个简单记录。
二、方案
1. 使用http模块
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
| http { server { listen 443 ssl; listen [::]:443 ssl;
server_name a.example.com;
...
location / { proxy_pass http://127.0.0.1:8001; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } server { listen 443 ssl; listen [::]:443 ssl;
server_name b.example.com;
...
location / { proxy_pass http://127.0.0.1:8002; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } }
|
特点:
- 协议层是7层网络模型的第7层(HTTP/HTTPS)
- 分流依据是请求的Host字段
- 适用的场景是日常的Web请求,例如HTTP/HTTPS
- 配置相对复杂,但功能更丰富
- 性能开销相对较高,需要解析请求内容,涉及更多处理逻辑
2. 使用stream模块
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
| stream { map $ssl_preread_server_name $backend { default ""; a.example.com 127.0.0.1:8001; b.example.com 127.0.0.1:8002; }
server { listen 443; listen [::]:443; ssl_preread on;
proxy_pass $backend; } }
|
特点:
- 协议层是7层网络模型的第4层(TCP)
- 分流依据是请求的SNI信息
- 适用的场景是有SSL/TLS协议的场景和,例如HTTPS
- 配置简单,适合转发和分流,但不适合更复杂的场景
- 性能开销相对较低,不需要关心应用层的协议
三、总结
有时候多了解一些技术,就会发现解决问题的方式往往不是单一的,横向扩展下知识面,可能在解决问题时有不同的思路和解决方案。