遇到的问题: 如何使用nginx代理ws或是wss的请求

起因是,为了降本增效要做服务器合并的需求,但两个服务器之间的进程存在对外连接的端口冲突,如果我们改了端口,客户端也会涉及到修改,但客户端的版本太旧了,想改变和重新发版流程会拉的很长,所以我们尝试别的方法来解决端口修改的问题

因为服务器的时间比较旧了,所以客户端并没有先连负载均衡再连服务器 针对这个问题我们提供了下面两个方案

• 多网卡,比如之前A服务器的启动的监听端口都在IPA的,原B服务器迁移进来后监听的端口都在IPB上,这样就实现了一台服务器上,监听了多个重复端口的问题,我们只要将IPA和IPB分别绑定到不同的域名上即可实现客户端无感的服务器迁移
• 使用nginx做端口映射

最终我们选择了成本更低的nginx端口映射的做法 具体的代码如下:

powershell
 代码解读
复制代码
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实现的负载均衡