当前位置： 首页 > news >正文

Nginx 反向代理与负载均衡架构

news 2025/8/10 5:30:08

一、反向代理基础

实验目的：通过 Nginx 反向代理，将客户端请求按类型（静态页面 / 动态 PHP 页面）转发到不同的后端服务器（RS1 处理静态资源，RS2 处理动态请求），实现 “客户端只与代理服务器交互，无需知道后端实际服务器” 的架构，提升服务安全性、可扩展性和资源处理效率。

反向代理的核心价值

反向代理是指 代理服务器接收客户端所有请求，再根据规则转发到后端不同服务器，客户端仅感知代理服务器的存在，对后端服务器的 IP、架构等信息完全透明。其核心作用：

  • 隐藏后端架构：保护后端服务器不直接暴露在公网，降低被攻击风险；

  • 请求分流：将静态资源（HTML、图片等）和动态请求（PHP、JSP 等）分配到不同服务器处理，发挥各自优势（如静态服务器可优化缓存，动态服务器专注计算）；

  • 扩展性强：后续可轻松添加更多后端服务器（如增加 RS3 处理图片），只需修改代理配置，无需改动客户端。

实验架构与准备

  • 代理服务器：Nginx 所在主机（192.168.67.100），接收客户端请求并转发；

  • RS1（后端静态服务器）：192.168.67.10，处理静态页面（HTML 等）；

  • RS2（后端动态服务器）：192.168.67.20，处理动态请求（PHP 等）；

  • 本地解析：客户端（如 Windows）需在 hosts 文件中添加 www.haha.org 到代理服务器 IP（192.168.67.100）的映射，确保通过域名访问时指向代理服务器。

RS1 配置静态页面

echo rs1 - 192.168.67.10 > /usr/share/nginx/html/index.html 
systemctl restart nginx

RS2 配置 php 动态页面

yum install php -y
mkdir  /usr/share/nginx/html/php/
vim /usr/share/nginx/html/php/index.php
###########
<?phpphpinfo();
?>
###########   
systemctl restart nginx

nginx 代理服务器配置代理

vim /usr/local/nginx/conf.d/haha.conf 
##########
server {listen  80;server_name www.haha.org;
​location / {                                # 规则 1：普通路径请求（如 /）转发到 RS1（静态服务器）proxy_pass http://192.168.67.10;        # 转发请求到 RS1 的 IP}
​location ~ \.(php|jsp|js)$ {                # 规则 2：.php/.jsp/.js 后缀的动态请求转发到 RS2（动态服务器）proxy_pass http://192.168.67.20;        # 转发请求到 RS2 的 IP}
}
##########
systemctl restart nginx

测试：

测试静态请求转发：

客户端访问 www.haha.org，代理服务器匹配 location /，转发到 RS1，页面显示 “rs1 - 192.168.67.10”，验证静态请求正确转发。

测试动态请求转发：

客户端访问 www.haha.org/php/index.php，代理服务器匹配 ~ .(php)$，转发到 RS2，页面显示 PHP 环境信息（phpinfo() 输出），验证动态请求正确转发。

为什么这样配置？核心逻辑

  1. 资源分流，提升效率：静态资源（HTML）无需计算，由 RS1 专注处理；动态资源（PHP）需要解析执行，由 RS2 处理，避免单服务器同时处理两类请求导致的性能瓶颈。

  2. 隐藏后端，增强安全：客户端仅知道代理服务器（192.168.67.100），无法直接访问 RS1/RS2，减少后端服务器被直接攻击的风险。

  3. 灵活扩展，便于维护：若后续静态资源增多，可添加 RS3 作为新静态服务器，只需修改 location / 的 proxy_pass 为负载均衡组（如 http://static_servers）；动态服务同理，扩展性极强。

适用场景

反向代理广泛用于：

  • 大型网站的请求分流（静态资源 CDN 转发、动态请求到应用服务器）；

  • 负载均衡（多台后端服务器分担请求压力）；

  • 安全隔离（代理服务器作为入口，过滤恶意请求后再转发到后端）。

二、反向代理 - 负载均衡

实验目的：通过 Nginx 负载均衡功能，将客户端请求按规则分配到多个后端服务器（RS），实现 “请求分流” 以分担单服务器压力；同时配置健康检查和备用服务器（sorry server），确保后端服务器故障时自动切换，提升服务可用性（避免单点故障导致服务中断）。

负载均衡的核心价值

在高并发场景下，单台后端服务器（RS）可能因请求量过大导致响应缓慢或宕机。负载均衡通过 “多服务器协同工作” 解决这一问题：

  • 请求分流：将客户端请求均匀分配到多台后端服务器，避免单服务器过载；

  • 高可用：通过健康检查自动剔除故障服务器，请求仅转发到正常服务器；

  • 容灾备份：当所有主服务器故障时，自动切换到备用服务器（sorry server），避免返回错误页面，提升用户体验。

实验架构与准备

  • 代理服务器：Nginx 所在主机（假设 IP 为代理服务器 IP），负责负载均衡调度；

  • 后端主服务器（RS）：

    • RS1：192.168.67.10，提供静态页面服务；

    • RS2：192.168.67.20，提供静态页面服务；

  • 备用服务器（sorry server）：代理服务器本地的 Apache 服务（端口 8888），当所有主服务器故障时提供兜底响应。

RS 主机配置默认访问页面。

echo rs1 - 192.168.67.10 > /usr/share/nginx/html/index.html 
systemctl restart nginx

修改 nginx 子配置文件

vim /usr/local/nginx/conf.d/haha.conf 
##########
upstream webserver {server 192.168.67.10:80 weight=1 fail_timeout=15s max_fails=3;      # RS1：权重 1，失败 3 次后标记为不可用，15 秒后重试检测server 192.168.67.20:80 weight=1 fail_timeout=15s max_fails=3;server 192.168.67.100:8888 backup;                                  # 备用服务器：仅当所有主服务器故障时启用，端口 8888
}
server {listen  80;server_name www.haha.org;
​location / {proxy_pass http://webserver;            # 所有请求转发到定义的 webserver 服务器组}
}
##########
​
systemctl restart nginx

配置 nginx 代理服务器的 sorry server 功能。运用 apache 服务器，修改端口作为 sorry server。

yum install httpd
vim /etc/httpd/conf/httpd.conf 
########
Listen 8888                     # 修改端口
########
​
echo sorry > /var/www/html/index.html
​
systemctl start httpd
systemctl enable --now httpd
netstat -antlupe | grep http

测试负载均衡效果

  • 正常轮询：客户端多次访问 www.haha.org，页面会交替显示 “rs1 - 192.168.67.10” 和 “rs2 - 192.168.67.20”，验证请求被均匀分配到两台主服务器。

  • 故障自动剔除：手动停止 RS1 的 Nginx 服务（systemctl stop nginx），再次访问时，请求仅转发到 RS2（页面稳定显示 RS2 内容），验证故障服务器被自动剔除。

  • 备用服务器激活：同时停止 RS1 和 RS2 的服务，访问时页面显示 “sorry”，验证备用服务器生效，提供兜底响应。

为什么这样配置？核心设计逻辑

  1. 请求分流，降负载：通过 weight 配置实现请求均匀分配（或按权重分配），避免单服务器因高并发过载，提升整体响应速度。

  2. 健康检查，保可用：max_fails 和 fail_timeout 确保故障服务器被及时剔除，请求不浪费在无效节点上，减少用户等待。

  3. 多级备份，防极端：backup 备用服务器解决 “全故障” 场景，将 “服务中断” 转化为 “降级可用”，最大限度减少用户流失。

  4. 灵活扩展，易维护：新增后端服务器时，只需在 upstream 中添加 server 配置，无需修改客户端或代理入口，扩展性极强。

适用场景

负载均衡广泛用于：

  • 高并发网站（如电商平台、资讯门户），通过多服务器分担流量；

  • 核心业务系统，通过冗余服务器避免单点故障；

  • 混合架构服务（如部分服务器处理静态资源，部分处理动态请求）。

三、四层代理 - 负载均衡

实验目的：通过 Nginx 的 stream 模块实现四层（传输层）负载均衡，针对非 HTTP 协议的服务（如 DNS、MySQL）进行请求分流，将客户端连接按规则分配到多台后端服务器，同时通过健康检查确保服务可用性，适用于数据库、DNS 等底层服务的负载均衡场景。

核心原理：四层代理与 stream 模块

四层代理工作在 TCP/UDP 传输层，仅根据 “源端口、目标端口、IP 地址” 转发数据，不解析应用层协议（如 HTTP 头部、DNS 报文内容），因此适用于所有基于 TCP/UDP 的服务（如 DNS、MySQL、SSH 等）。

Nginx 通过 stream 模块实现四层代理，功能类似硬件负载均衡器的 “四层转发”，核心优势：

  • 通用性：支持所有 TCP/UDP 服务，不受应用层协议限制；

  • 高性能：转发逻辑简单（仅处理传输层数据），性能接近硬件级；

  • 高可用：结合健康检查（max_fails、fail_timeout）自动剔除故障节点。

3.1.DNS 负载

实验背景

DNS 服务是网络基础服务，负责将域名解析为 IP 地址，通常使用 UDP 53 端口（普通查询）和 TCP 53 端口（区域传输等）。通过四层代理实现 DNS 负载均衡，可分担单台 DNS 服务器的查询压力，同时避免单点故障。

RS 安装 bind 软件，配置 DNS 服务。

yum install bind -y             # 安装 BIND（DNS 服务软件）
​
vim /etc/named.conf 
############
options {
...listen-on port 53 { any; };     # 确保 DNS 服务可被远程客户端访问（不仅限于本地）allow-query     { any; };       # 允许所有 IP 地址查询该 DNS 服务器，适合作为公共解析服务dnssec-validation no;           # 关闭 DNS 记录的数字签名验证（测试场景简化，生产环境需开启）
...
}
############

禁用 DNSSEC 验证后，系统在处理 DNS 解析结果时，不会对记录的数字签名进行验证，直接接受并使用解析结果（无论其是否被篡改、是否来自真实域名所有者）。

dnssec-validation no; 是为了 “可用性” 牺牲 “安全性” 的配置，让系统 “不较真” DNS 记录的真实性，直接使用解析结果。

vim /etc/named.rfc1912.zones 
########### 
zone "haha.org" IN {                    # 添加以下内容type master;                    # 作为主 DNS 服务器  file "haha.org.zone";           # 解析记录文件路径 allow-update { none; };         # 禁止动态更新（安全加固）
};
###########
​
cd /var/named/
cp -p named.localhost haha.org.zone
​
vim haha.org.zone 
###########
$TTL 1D
@       IN SOA  dns.haha.org.  root.haha.org. (0       ; serial1D      ; refresh1H      ; retry1W      ; expire3H )    ; minimumNS      dns.haha.org.
dns     A       192.168.67.10               # 为了查看效果 20 主机写本机 IP
###########
​
systemctl start named
systemctl enable --now named

nginx 代理服务器配置。

# 主配置文件添加
vim /usr/local/nginx/conf/nginx.conf    
##########
...
include "/usr/local/nginx/tcp.d/*.conf";        # 引入四层代理配置文件（不可放在 http 或 server 块内）
...
##########
mkdir /usr/local/nginx/tcp.d/
vim /usr/local/nginx/tcp.d/xixi.conf
#########
stream {upstream dns {server 192.168.67.10:53 max_fails=3 fail_timeout=5;     # RS1 的 DNS 服务（53 端口），3 次失败后标记不可用，5 秒后重试server 192.168.67.20:53 max_fails=3 fail_timeout=5;}
​server {listen 53 udp;      # 监听代理服务器的 UDP 53 端口proxy_pass dns;     # 转发到 dns 服务器组 }server {listen 53;          # 默认 TCP 协议，监听 53 端口proxy_pass dns;}
}
#########
​
systemctl restart nginx
netstat -antlupe | grep nginx

预期结果：多次查询会交替返回 RS1（192.168.67.10）和 RS2（192.168.67.20）的 IP，验证请求被轮询分配到两台后端 DNS 服务器。

dig @192.168.67.100 dns.haha.org

3.2.Mysql 负载

实验背景

MySQL（或 MariaDB）是常用的关系型数据库，使用 TCP 3306 端口通信。通过四层代理实现 MySQL 负载均衡，可将客户端连接分配到多台数据库服务器，分担读写压力（需配合数据库主从复制等策略确保数据一致性）。

后端 RS 下载 mariadb，配置 server_id，授权用户。

# 安装 mariadb
yum install mariadb-server  -y
​
vim /etc/my.cnf.d/mariadb-server.cnf
[mysqld]
...
server-id=10        # RS1 设为 10，RS2 设为 20（唯一标识，便于区分实例）
...
​
systemctl enable --now mariadb
​
mysql -e "grant all on *.* to zyz@'%' identified by 'zyz'"      # 进入MySQL# 添加可远程登录的用户
​
# 测试：远程登录 mysql
mysql -uzyz -pzyz -h192.168.13.10
mysql -uzyz -pzyz -h192.168.13.20

nginx 主机配置

vim /usr/local/nginx/tcp.d/xixi.conf
########
stream {upstream mariadb {server 192.168.67.10:3306 max_fails=3 fail_timeout=4;       # RS1 的 MySQL 服务（3306 端口），3 次失败后标记不可用，4 秒后重试server 192.168.67.20:3306 max_fails=3 fail_timeout=4;}server {listen 3306;            # 监听代理服务器的 3306 端口  proxy_pass mariadb;     # 转发到 mariadb 服务器组}
}
########
netstat -antlupe | grep nginx

测试：

预期结果：多次连接会交替返回 server_id=10（RS1）和 server_id=20（RS2），验证请求被轮询分配到两台后端数据库服务器。

四层代理的核心价值与配置解析

  • 关键参数作用

    • stream 块：Nginx 处理四层代理的核心模块，与 http 块平级，专门用于配置 TCP/UDP 服务的转发规则。

    • upstream 服务器组：定义后端服务节点，支持 max_fails（最大失败次数）和 fail_timeout（失败检测周期）实现健康检查 —— 超过失败次数后自动剔除故障节点，超时后重新检测。

    • listen 指令：指定代理服务器监听的端口和协议（udp 需显式声明，默认 TCP），如 listen 53 udp 对应 DNS 的 UDP 服务，listen 3306 对应 MySQL 的 TCP 服务。

    • proxy_pass：将监听端口的请求转发到定义的 upstream 服务器组，实现负载均衡。

  • 适用场景与优势

    • 通用性：支持所有 TCP/UDP 服务（DNS、MySQL、SSH、Redis 等），解决七层代理（仅 HTTP）的局限性；

    • 高性能：转发逻辑简单（不解析应用层数据），资源消耗低，可支撑高并发场景；

    • 高可用：通过健康检查自动剔除故障节点，结合备用服务器可实现服务无感知切换；

    • 易扩展：新增后端服务器只需在 upstream 中添加节点，无需修改客户端配置。

通过四层代理配置，Nginx 突破了仅处理 HTTP 服务的限制，成为通用的传输层负载均衡器，为底层服务（如数据库、DNS）提供分流与高可用保障，是构建企业级分布式架构的重要组件。

http://www.dtcms.com/a/322414.html

相关文章：

  • 基于开源AI大模型、AI智能名片与S2B2C商城小程序的学习型社群构建与运营模式创新研究
  • 深度学习中基于响应的模型知识蒸馏实现示例
  • 开发手札：UnrealEngine和Unity3d坐标系问题
  • K-means聚类学习：原理、实践与API解析
  • AI大语言模型在生活场景中的应用日益广泛，主要包括四大类需求：文本处理、信息获取、决策支持和创意生成。
  • 《Learning To Count Everything》论文阅读
  • 动态路由菜单：根据用户角色动态生成菜单栏的实践（包含子菜单）
  • 使用加密技术实现个人密码本保护
  • try/catch/throw 简明指南
  • orcad的操作（1）
  • 写 SPSS文件系统
  • Docker容器
  • 多级缓存详解
  • RAG-大模型课程《李宏毅 2025》作业1笔记
  • 从“人拉肩扛”到“智能协同”——AGV重构消防智能仓储价值链
  • 我用C++和零拷贝重构了文件服务器，性能飙升3倍，CPU占用降低80%
  • 202506 电子学会青少年等级考试机器人二级理论综合真题
  • Spark02 - SparkContext介绍
  • 304 引发的 SEO 难题：缓存策略与内容更新如何两全？
  • 【ref、toRef、toRefs、reactive】ai
  • 比较useCallback、useMemo 和 React.memo
  • kafka架构原理快速入门
  • Opencv[七]——补充
  • 基于HTML的政策问答
  • java组件安全vulhub靶场
  • HTML金色流星雨
  • 服务器硬件电路设计之I2C问答（二）：I2C总线的传输速率与上拉电阻有什么关系？
  • ELK常见的问题
  • 华为实验：DHCP 典型配置
  • 《汇编语言：基于X86处理器》第12章 复习题和练习