遇到的问题: 如何使用nginx代理ws或是wss的请求
起因是,为了降本增效要做服务器合并的需求,但两个服务器之间的进程存在对外连接的端口冲突,如果我们改了端口,客户端也会涉及到修改,但客户端的版本太旧了,想改变和重新发版流程会拉的很长,所以我们尝试别的方法来解决端口修改的问题
因为服务器的时间比较旧了,所以客户端并没有先连负载均衡再连服务器 针对这个问题我们提供了下面两个方案
- 多网卡,比如之前A服务器的启动的监听端口都在IPA的,原B服务器迁移进来后监听的端口都在IPB上,这样就实现了一台服务器上,监听了多个重复端口的问题,我们只要将IPA和IPB分别绑定到不同的域名上即可实现客户端无感的服务器迁移
- 使用nginx做端口映射
最终我们选择了成本更低的nginx端口映射的做法 具体的代码如下:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
server { listen 7865 ssl; #监听的端口(客户端连接的原端口) server_name a.b.com; #监听的域名,非必须 ssl_certificate /etc/nginx/a.pem; #证书 ssl_certificate_key /etc/nginx/a.key; #证书 ssl_session_timeout 20m; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_verify_client off; location / { proxy_pass https://127.0.0.1:7899; # 新的端口,这里有一个关键点,如果我们是ssl的,这里使用https的连接,如果没有ssl,这里需要设置为http proxy_http_version 1.1; # 必须使用 HTTP 1.1 proxy_redirect off; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } |
这里我们可以把nginx的这层反向代理看着是透明的,因为客户端和nginx建立长连接,而nginx和后端服务器也会建立长连接,一旦我们的后端进程重启了,客户端还是会感知到.
拓展1: 负载均衡分类
我们按照起作用的ISO7层模式的层来区分的话,可以分为4层负载均衡和7层负载均衡
4层负载均衡
例如LVS或是AWS的NLB就是4层负载均衡 它的原理: 分别获取包中的源IP地址和端口和目标IP地址和端口,对后端做负载均衡(算法可能是轮询或是权重等)后修改包中的目标IP地址和端口,使其流量能得到转发
请求的路径是:
- 客户端发出情况,数据包被送到负载均衡器
- 负载均衡通过源IP地址+端口和目标IP+端口确定请求最后转发到哪一台后端服务器
- 负载均衡器通过修改目标IP和端口
- 数据包被转发到指定的后端服务器
响应的路径是:
- 后端程序进行业务处理
- 如果负载均衡器做了NAT(为了让后端进程透明,目的是隐藏后端服务器,原理就是将源IP地址和源端口修改成负载均衡器的IP地址和端口),数据包会回到负载均衡器中
- 返回给客户端
如果负载均衡器没有NAT功能,或是配置为直连的方式,则响应的数据包是不会经过负载均衡器的,这个可以通过分析流量包的源IP地址和端口来确认
4层负载均衡器的好处 4层负载均衡器不会解传输数据包,只会解header包从而获取IP地址和端口,所以相对来说速度更快 什么时候我们需要使用4层负载均衡呢
- 非HTTP的时候
- 需要较高的性能
- 场景简单
7层负载均衡
例如nginx IIS就是7层的负载均衡
主要用于处理HTTP/HTTPS等应用层协议。它不仅可以基于传输层信息（如IP地址和端口）进行负载均衡，还可以深入解析应用层数据，提供更灵活和高级的流量管理。
原理: 7层负载均衡器可以解析和检查HTTP头、URL、cookie、SSL信息等应用层数据。这使得它能根据这些内容做出智能的流量路由决策。 因为比较上层,所以可以做的事情比较多
- 基于内容转发: 可以根据特定的URL路径、域名、HTTP方法或其他应用层数据，将请求定向到不同的服务器池。例如，将所有以"/images"结尾的请求路由到图片服务器
- session保持: 通过使用cookie或其他机制，确保来自同一客户端的所有请求都被转发到同一个后端服务器，从而维护用户会话的连续性
- 请求重定向: 能够修改请求内容或路径，或将请求重定向到其他资源或服务器
- 数据压缩和缓存: 处理请求时，可以对响应内容进行压缩，减少传输的数据量。同时，还能缓存常见请求的响应，降低后端服务器负担
请求路径:
- 客户端发送请求到负载均衡器
- 负载均衡器通过分析内容进行转发
- 请求达到具体的后端进程
响应路径:
- 后端处理业务逻辑
- 响应经过负载均衡器
- 负载均衡器做一些优化处理 例如缓存/压缩等
- 响应给客户端
可以发现,响应是会经过负载均衡器的,实际上客户端和nginx建立了连接,nginx和后端进程建立了连接实现了请求的转发和请求的响应
拓展2: 还有哪些负载均衡
使用rabbitMQ多个消费者也可以实现负载均衡的作用
grpc+etcd实现的负载均衡
