正反向代理与负载均衡

3、正反向代理与负载均衡

---

3.1正向代理（Forward Proxy）

工作原理：

1、正向代理位于客户端和原始服务器之间，为客户端发送请求到目标服务器进行代理。客户端不直接访问目标服务器，而是通过正向代理来访问。

2、客户端向正向代理发送请求，然后正向代理将这些请求转发给目标服务器，并将目标服务器的响应再返回给客户端。

用途：
1、访问控制与安全性：正向代理可以通过中间代理服务器隐藏客户端的真实 IP 地址，增加访问的安全性和隐私性。
2、访问限制：可以通过正向代理实现对某些特定资源的访问控制，例如内部网络资源或者受限访问的外部资源。
3、访问内容的控制：可以对客户端请求或者响应进行修改、过滤或者记录，以实现内容控制或者日志记录等功能。

配置示例：
http {
    # 定义正向代理服务器
    server {
        listen 8080;

        location / {
            resolver 8.8.8.8;
            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;
        }
    }
}
在上面的配置中，Nginx 监听在 8080 端口，作为正向代理服务器，将客户端的请求转发给目标服务器。
=========================================================================================================================================

 3.2 反向代理（Reverse Proxy）

工作原理：
1、反向代理位于客户端和原始服务器之间，为原始服务器接收到的请求进行代理。客户端不直接与原始服务器通信，而是与反向代理通信。
2、客户端向反向代理发送请求，反向代理根据请求的内容将其转发给内部的一组服务器（如 Web 服务器集群），然后将服务器的响应返回给客户端。

用途：
1、负载均衡：反向代理可以根据负载均衡策略将请求分发给多个服务器，以提高系统的整体性能和可用性。
2、安全性：反向代理可以作为安全屏障，隐藏了后端服务器的实际信息，有效防止直接暴露服务器的一些细节。
3、缓存：反向代理可以缓存静态内容，减轻后端服务器的负载，提高用户访问的响应速度。

配置示例：
http {
    # 定义反向代理服务器
    server {
        listen 80;

        location / {
            proxy_pass http://backend_servers;
            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;
        }
    }

    upstream backend_servers {
        server backend1.example.com;
        server backend2.example.com;
        # 可以添加更多的后端服务器
    }
}
在上面的配置中，Nginx 监听在 80 端口，作为反向代理服务器，将客户端的请求转发给 backend_servers 中定义的一组后端服务器。

总结
1、正向代理：代理客户端，隐藏真实客户端，帮助客户端访问其他服务器。
2、反向代理：代理服务器端，隐藏真实服务器，为客户端提供服务，并通过负载均衡、安全性等功能增强服务质量。
3、这两种代理方式在实际应用中有着不同的用途和优势，可以根据具体的需求来选择合适的代理方式配置 Nginx。

3.3反向代理与负载均衡搭建

创建三台nginx服务器，博主是先创建一台配置好yum源，安装好nginx服务后，克隆的另外两台。

服务器一和服务器二只需要启动nginx服务就行，无需修改其他配置

 服务器一的配置参数

服务器二的配置参数

服务器三的配置参数

这里我是把反向代理，负载均衡，基于端口的虚拟主机，把主服务器也加入到负载均衡后端服务器一起进行的配置。

1、可以实现一台主服务器做代理，另外两台做后端口负载服务器

2、可以实现一台服务器做代理，另外两个目录做虚拟主机

3、可以实现一台主服务器做转发，从服务器做负载，主服务器既做代理又启用另外端口做负载

#定义一组后端服务器实现负载均衡
    upstream backend {
       server 192.168.31.26:8080 weight=1;
       server 192.168.31.27:8080 weight=2;
       server 192.168.31.28:8080 weight=1;
       server localhost:9001;
       server localhost:9002;
}
#添加本机虚拟主机1
    server {
        listen 9001;
        server_name localhost; # 指定域名

        root /var/www/test8080;  # 指定目录
        index index.html index.htm;

        location / {
        #try_files $uri $uri/ =404; # 尝试提供文件，如果找不到则返回404错误
    }
}
#添加本机虚拟主机2 
 server {
        listen 9002;
        server_name localhost; # 指定域名

        root /var/www/test8081;  # 指定目录
        index index.html index.htm;

        location / {
        #try_files $uri $uri/ =404; # 尝试提供文件，如果找不到则返回404错误
    }
}
#本机也参与负载均衡队列，另外启用8080端口提供服务
    server {
        listen 8080;
        server_name localhost; # 指定域名

        #root /var/www/test8080;  # 指定目录
        #index index.html index.htm;

        location / {
        #try_files $uri $uri/ =404; # 尝试提供文件，如果找不到则返回404错误
            }
}
#负载均衡与反向代理
    server {
        listen       80;
        server_name  www.test.com;
       
        location / {
        proxy_pass   http://backend; #指示Nginx 将请求代理到定义在backend中的多个后端服务器上，根据负载均衡策略分发请求。

            root   html;
            index  index.html index.htm;
        }
}

测试结果：正常

以上实验测试正常：可以实现上述要求的负载均衡、主从负载、虚拟端口等功能的实现

3.4、负载均衡算法策略选择

Nginx 提供了几种主要的负载均衡策略，每种策略都可以根据具体的需求和场景进行选择和配置。这些策略包括：

  3.4.1、加权轮询：

• 描述：默认的负载均衡策略。按照服务器定义的顺序逐个分配请求，直到所有服务器都被轮询到，然后重新开始。

• 适用场景：适合后端服务器性能相对均衡，无特殊需求的情况。

示例配置：

upstream backend_servers {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

  3.4.2、最小连接数：

• 描述：将请求发送到当前连接数最少的服务器。

• 适用场景：适合处理长连接或者有长时间任务的场景，可以有效地减少等待队列和提高响应速度。

示例配置：

upstream backend_servers {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

  3.4.3、IP Hash：

• 描述：使用请求的客户端 IP 地址的哈希值来决定将请求发送到哪台服务器。同一 IP 的请求始终被发送到同一台服务器上，适合需要保持会话状态的应用。

• 适用场景：适合有状态的应用，如会话管理或登录状态需要保持的应用。

示例配置：

upstream backend_servers {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

  3.4.4、通用哈希：

• 描述：根据请求中的指定变量的哈希值来决定服务器的选择。可以使用自定义变量或者请求头来计算哈希值。

• 适用场景：需要更细粒度控制和定制的负载均衡需求，比如基于用户标识的负载均衡。

示例配置：

upstream backend_servers {
    hash $request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
}

这些负载均衡策略可以单独使用或者组合使用，根据具体的应用场景和性能需求来进行配置。通常，通过权衡不同策略的优劣，可以实现最佳的负载均衡效果，提升系统的稳定性和性能。