1. 负载均衡概念
负载均衡(Load Balancing)是将网络请求或计算任务分配到多个服务器上的技术,旨在优化资源使用、最大化吞吐量、最小化响应时间,并避免任何单一资源的过载。
主要作用:
- 提高可用性:当某台服务器故障时,自动将流量导向健康节点
- 增强扩展性:通过添加更多服务器水平扩展系统能力
- 优化性能:减少单台服务器压力,降低响应时间
- 提升安全性:作为第一道防线,隐藏后端服务器细节
2. 四层与七层负载均衡区别
- 工作层级与协议的区别
- 四层负载均衡(传输层,L4)
- 层级:OSI第4层(传输层)。
- 协议:基于TCP/UDP协议(如HTTP默认基于TCP 80端口)。
- 功能:仅解析IP和端口,通过修改数据包的源/目标地址和端口实现转发(如NAT)。
- 七层负载均衡(应用层,L7)
- 层级:OSI第7层(应用层)。
- 协议:支持HTTP、HTTPS、FTP、DNS等应用层协议。
- 功能:可解析URL、Header、Cookie等具体内容,实现更精细的路由。
- 四层负载均衡(传输层,L4)
- 数据处理能力的区别
- 四层
- 仅处理数据包的IP和端口,无法感知应用层内容。
- 转发效率高(接近物理层性能)。
- 七层
- 可解析HTTP报文内容,实现基于URL、用户身份(如Cookie)、请求类型的路由(如将
/api
请求分发到后端API服务器)。 - 支持内容优化(如压缩、加密)、安全防护(如WAF)。
- 可解析HTTP报文内容,实现基于URL、用户身份(如Cookie)、请求类型的路由(如将
- 四层
- 性能与复杂度的区别
- 四层
- 优点:转发速度快(硬件负载均衡如F5可达百万级TPS),延迟低。
- 缺点:无法应对复杂业务逻辑。
- 七层
- 优点:功能丰富(如A/B测试、蓝绿部署)。
- 缺点:处理开销大(需解析应用层数据),性能通常低于四层。
- 四层
- 典型应用场景
- 四层适用场景
- 需要高性能的TCP/UDP流量分发(如游戏服务器、视频流)。
- 对内容无感知需求(如简单的数据库读写分离)。
- 七层适用场景
- 需要智能路由的Web服务(如根据URL分发到不同微服务)。
- 四层适用场景
- 常见工具
- 硬件负载均衡 F5(支持四层和七层,通常在四层使用)。
- LVS(开源软件,只支持四层)。
- Haproxy(开源软件,支持四层和七层,通常在七层使用)。
- Nginx(开源软件,支持四层和七层,通常在七层使用)。
3. Nginx 代理四层与七层负载均衡
3.1. 四层负载均衡配置
Nginx 四层负载均衡配置在 stream 模块内。如下所示:
stream {
upstream my_servers {
least_conn; # 负载均衡算法,后面详细介绍
# 5s内出现3次错误,该服务器将被熔断5s
server <IP_SERVER_1>:3306 max_fails=3 fail_timeout=5s;
server <IP_SERVER_2>:3306 max_fails=3 fail_timeout=5s;
server <IP_SERVER_3>:3306 max_fails=3 fail_timeout=5s;
}
server {
listen 3306;
proxy_connect_timeout 5s; # 与被代理服务器建立连接的超时时间为5s
proxy_timeout 10s; # 获取被代理服务器的响应最大超时时间为10s
proxy_next_upstream on; # 当被代理的服务器返回错误或超时时,将未返回响应的客户端连接请求传递给upstream中的下一个服务器
proxy_next_upstream_tries 3; # 转发尝试请求最多3次
proxy_next_upstream_timeout 10s; # 总尝试超时时间为10s
proxy_socket_keepalive on; # 开启SO_KEEPALIVE选项进行心跳检测
proxy_pass my_servers;
}
}
# 注意:如果你配置 steam 模块无效,请检查一下你使用的版本是否支持 stream,如果未内置该模块,你需要在编译的时候指定参数 --with-stream 进行编译使其支持stream代理。
# 查看nginx安装了哪些模块
nginx -V # 注意用的是大写V,小写的v是查看nginx版本
# 或者更方便的命令
$ 2>&1 nginx -V | tr ' ' '\n'|grep stream
--with-stream
--with-stream_realip_module
--with-stream_ssl_module
--with-stream_ssl_preread_module
Bash为四层负载均衡添加日志:因为在 nginx.conf 的配置中,access 的日志格式是配置在 http 模块内的,而四层负载均衡配置是在 stream 模块内的,所以 Nginx 的默认日志文件不包含四层转发的日志。如果需要日志则需要在 stream 模块内配置。如下所示:
stream {
log_format proxy1 '$remote_addr $remote_port - [$time_local] $status $protocol '
'"$upstream_addr" "$upstream_bytes_sent" "$upstream_connect_time"'; # 定义日志格式件
access_log /var/log/nginx/proxy1.log proxy1; # 定义日志文件路径,并引用日志格式
upstream my_servers {
server 192.168.71.12:9090 max_fails=3 fail_timeout=5s;
server 192.168.71.13:9090 max_fails=3 fail_timeout=5s;
}
server {
listen 80;
proxy_pass my_servers;
}
}
# 上述日志格式各字段含义
$remote_addr:客户端IP地址。
$remote_port:客户端端口。
$time_local:请求时间。
$status:连接状态(如成功、失败)。
$protocol:使用的协议(TCP/UDP)。
$upstream_addr:后端服务器的地址。
$upstream_bytes_sent:发送到后端服务器的字节数。
$upstream_connect_time:与后端服务器建立连接的时间。
# 注意:Nginx 的流模块在处理 TCP 流量时,并不会在每个请求都写入一条日志。相反,它在 TCP 连接结束后(也就是说,当连接关闭时)才会记录一条日志。
Bash3.2. 七层负载均衡配置
Nginx 七层负载均衡配置在 http 模块内。如下所示:
http {
……
upstream testserver {
ip_hash; # 负载均衡算法,后面详细介绍
server 192.168.1.5:8080;
server 192.168.1.6:8080;
……
}
server {
……
location / {
……
proxy_pass http://testserver;
}
}
}
Bash3.3. Nginx 负载均衡算法
3.3.1. 轮询算法 (Round Robin)
默认算法,无需特别配置。
- 工作原理:按顺序将请求依次分配给后端服务器
- 特点:
- 简单公平,每个服务器轮流获得请求
- 不考虑服务器负载和性能差异
- 适合服务器性能相近的场景
配置示例:
upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
Bash3.3.2. 加权轮询 (Weighted Round Robin)
带权重的轮询算法。
- 工作原理:根据配置的权重分配请求,权重高的服务器获得更多请求
- 特点:
- 适合服务器性能不一致的环境
- 权重越高,分配的请求比例越大
- 权重越高,分配的请求比例越大
配置示例:
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com weight=3;
server backend3.example.com weight=2;
}
Bash3.3.3. IP哈希算法 (IP Hash)
基于客户端IP的哈希算法。
- 工作原理:根据客户端IP地址计算哈希值,相同IP的请求总是分配到同一台服务器
- 特点:
- 实现会话保持(session persistence)
- 适合需要保持会话的应用(如购物车)
- 当服务器数量变化时,大部分会话会重新分配
配置示例:
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
Bash3.3.4. 最少连接算法 (Least Connections)
动态分配算法。
- 工作原理:将请求分配给当前连接数最少的服务器
- 特点:
- 考虑服务器当前负载情况
- 适合请求处理时间差异较大的场景
- 需要Nginx实时监控后端连接数
配置示例:
upstream backend {
least_conn;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
Bash3.3.5. 加权最少连接 (Weighted Least Connections)
带权重的最少连接算法。
- 工作原理:结合权重和当前连接数进行分配
- 特点:
- 既考虑服务器性能差异,又考虑当前负载
- 适合高性能服务器需要处理更多请求的场景
配置示例:
upstream backend {
least_conn;
server backend1.example.com weight=5;
server backend2.example.com weight=3;
server backend3.example.com weight=2;
}
Bash3.3.6. 基于响应时间的负载均衡 (商业版功能)
Nginx Plus专有功能。
- 工作原理:根据服务器平均响应时间动态分配请求
- 特点:
- 自动将请求导向响应最快的服务器
- 适合对响应时间敏感的应用
配置示例:
upstream backend {
fair;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
Bash3.3.7. 哈希算法 (Generic Hash)
自定义键的哈希算法。
- 工作原理:根据指定的变量(如URL、参数等)计算哈希值分配请求
- 特点:
consistent
参数启用一致性哈希,减少服务器变动时的影响- 适合需要特定请求总是落到同一服务器的场景
- 常用于缓存服务器负载均衡
配置示例:
upstream backend {
hash $request_uri consistent;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
}
Bash3.3.8. 随机算法 (Random)
随机选择算法。
- 工作原理:随机选择一台服务器,可配置考虑权重
- 特点:
- 简单随机分配,适合测试环境
- 可选
random two
参数,随机选择两台后使用最少连接
配置示例:
upstream backend {
random;
server backend1.example.com weight=5;
server backend2.example.com weight=3;
server backend3.example.com weight=2;
}
Bash3.4. 后端获取客户端真实 IP 地址配置
七层负载均衡获取客户端真实 IP 地址配置示例:
负载均衡代理服务器传递 IP 配置:
http {
upstream webserver {
server 192.168.71.14:8080;
server 192.168.71.15:8080;
server 192.168.71.16:8080;
}
server {
listen 9090;
location / {
proxy_pass http://webserver;
# 只加上下面这一段即可
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
}
# 解释:
# X-Forwarded-For 头字段,它是一个被逐级代理服务器添加的、包含了所有中间 IP 的顺序列表,列表的最左侧是原始客户端的 IP。如果请求没有经过任何代理,这个变量为空。如果经过多级代理,这个变量会依次添加代理服务器的 IP,因此要获取真实的客户端 IP,应取这个列表的第一个 IP。
# HTTP 的 X-Real-IP 头字段,它被设计为单个 IP 地址,代表原始客户端的 IP。但在多级代理链中,如果每一级代理都覆盖 X-Real-IP 为自身的 $remote_addr,最终后端收到的 X-Real-IP 会是最后一层代理的 IP,而非原始客户端的 IP。
# Host 字段,将客户端原始请求的 Host 头原样传递给后端服务器。
# X-Forwarded-Proto 字段,告知后端服务器客户端与 Nginx 之间的连接协议(HTTP 或 HTTPS)。
Bash后端服务器获取 IP 配置:
如果你想在后端服务器的Nginx访问日志中打印出客户端的 IP 地址,配置示例如下:
# $remote_addr 获取的还是负载均衡的ip地址,我们默认增加了"$http_x_forwarded_for" "$http_x_real_ip"两个字段,这两个都可以拿到客户端的真实ip
http {
log_format main1 '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" "$http_x_real_ip"' ;
}
server {
access_log /var/log/nginx/access.log main1;
...
}
# 获得客户端IP的字段
# $http代表从http请求头里取
$http_x_forwarded_for # 获取X-Forwarded-For的值
$http_x_real_ip # 获取X-Real-IP的值
Bash四层+七层负载均衡获取客户端真实 IP 地址配置示例:
四层负载均衡配置:
要解决这个问题,我们需要在四层负载均衡上启用 proxy 协议,该协议通过为 tcp添加一个很小的头信息,来方便的传递客户端信息(协议栈、源IP、目的 IP、源端口、目的端口等),其本质是在三次握手结束后由代理在传输中插入了 一个携带了原始连接元组信息的数据包。
stream {
upstream lb_servers {
server 192.168.71.12:9090 max_fails=3 fail_timeout=5s;
server 192.168.71.13:9090 max_fails=3 fail_timeout=5s;
}
server {
listen 80;
proxy_pass lb_servers;
proxy_protocol on; # 新增这一条:代表开启proxy protocol 协议
}
}
Bash七层负载均衡配置:
http {
upstream web_app_servers {
server 192.168.71.112:80 weight=1;
server 192.168.71.113:80 weight=1;
}
server {
listen 80 proxy_protocol; # 因为上游的四层开启了proxy协议,所以此处需要配合启用proxy_protocol的监听
set_real_ip_from 负载均衡IP;
real_ip_header proxy_protocol; # 将proxy_protocol获取的IP替换原$remote_addr值
location / {
proxy_pass http://web_app_servers;
# 增加下面一段
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
}
Bash后端服务器获取 IP 配置同上。
4. Haproxy 代理四层与七层负载均衡
4.1. 四层负载均衡配置
示例:
global
log 127.0.0.1 local0 notice
maxconn 2000
user haproxy
group haproxy
defaults
log global
mode tcp
option tcplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
frontend ft web
bind *: 80
default backend bk web
backend bk web
balance roundrobin
server webl 192.168.1.1: 80 check
server web2 192.168.1.2: 80 check
# mode tcp 表示这是一个四层 TCP 负载均衡
# frontend ft_web 定义了监听的端口
# backend bk_web 定义了后端服务器列表,每个 server 行定义一个后端服务器,check 选项表示对服务器进行健康检查
Bash4.2. 七层负载均衡配置
示例:
global
log 127.0.0.1 local0 notice
maxconn 2000
user haproxy
group haproxy
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
frontend ft web
bind *: 80
acl xxx url reg -i \.html$
acl xxx path_beg -i /static /images /javascript /stylesheets
acl xxx path_end -i .jpg .gif .png .css .js
use backend static if xxx
default_backend bk_web
backend bk_web
balance roundrobin
mode http
# 添加http层面的健康检查,默认只会做 tcp 链接层面的健康检查
option httpchk HEAD / HTTP/1.1\r\nHost: localhost
server web1 192.168.1.1: 80 check
server web2 192.168.1.2: 80 check
# mode http:用于指示 HAProxy 在处理请求时要操作到应用层(也就是 HTTP 层面)。这使得可以对 HTTP 头部、URL 、Cookie 等进行处理和使用。
# option httplog:这设置 HAProxy 生成的日志包含 HTTP 信息,如请求的方法、URI 等。
# option forwardfor:这用于插入 X-Forwarded-For 头部信息,这是一个 HTTP 头部信息,用来记录原始客户端的 IP 地址。
# http-request set-header and http-request add-header:这用于插入或修改 HTTP 请求头信息。
# option httpchk HEAD / HTTP/1.1\r\nHost:localhost 配置的含义是:
## option httpchk:启用HTTP型的健康检查。
## HEAD:这个指定了具体使用的HTTP方法是 HEAD。使用HEAD请求可以减少健康检查产生的数据传输量,因为它不获取实际的响应体
## /:这是要访问以检查服务器健康状态的URI路径,这里是根路径
# HTTP/1.1:这指定了HTTP协议的版本是1.1。
# \r\nHost:localhost:这是一个额外的HTTP头部,指定了请求的Host头信息。\r\n 是回车和换行的转义字符,用来分隔HTTP头部。在这里,Host头被设置为 localhost,代表请求将被发送到配置为 localhost 的服务器。
# 注意:
## Host字段值不应设置为localhost,应根据后端服务器的配置调整,设置为后端服务的域名
## 如果请求失败或者超时,那么 HAProxy 会将此服务器标记为不健康, 流量不再会被转发至此服务器,直到下一个正常的健康检查。
Bash详细说明:
global # 全局参数
log 127.0.0.1 local2 info # 日志服务器
pidfile /var/run/haproxy.pid
maxconn 4000 #最大连接数(优先级低于后续的maxconn设置)
user haproxy
group haproxy
daemon #守护进程方式后台运行
nbproc 1 #工作进程数量 cpu内核是几就写几
defaults # 用于为其他配置段提供默认参数
mode http #工作模式是http (tcp 是 4 层,http是 7 层)
log global
retries 3 #健康检查。3次连接失败就认为服务器不可用,主要通过后面的check检查
option redispatch #服务不可用后重定向到其他健康服务器。
maxconn 4000 #优先级中
timeout connect 5000 #ha服务器与后端服务器连接超时时间,单位毫秒ms
timeout client 50000 #客户端超时
timeout server 50000 #后端服务器超时
listen stats # haproxy自带的状态监控服务
mode http
bind *:81
stats enable
stats uri /haproxy #使用浏览器访问 http://192.168.71.12:81/haproxy,可以看到服务器状态
stats auth egonlin:666 #用户认证
monitor-uri /monitoruri
frontend web # haproxy作为负载均衡的配置
mode http # 七层
bind *:80 # haproxy作为负载均衡对外暴漏的ip和端口
option httplog #日志类别 http 日志格式
acl xxx url_reg -i \.html$ #acl相当于nginx的location。url_reg定义自己的正则匹配url,-i忽略大小写,下同
acl xxx url_reg -i \/$ #针对访问末尾不加任何路径的情况例如http://xx.xx.xx
#acl xxx path_beg -i /static /images /javascript /stylesheets # path_beg匹配路径开头
#acl xxx path_end -i .jpg .gif .png .css .js # path_end匹配路径结尾
acl yyy path_end -i .css .js # path_end匹配路径结尾
use_backend static1 if xxx #如果满足acl xxx规则,则代理给后端服务器组static
use_backend static2 if yyy #如果满足acl yyy规则,则代理给httpservers组
default_backend httpservers #上述规则都匹配失败后默认的代理的组
backend static1
balance roundrobin
server static1_a 192.168.71.14:8080 check
backend static2
balance roundrobin
server static2_a 192.168.71.15:8080 check
backend httpservers
balance roundrobin
server myhttp1 192.168.71.16:8080 maxconn 2000 weight 1 check inter 1s rise 2 fall 2
#server myhttp2 192.168.71.17:8080 maxconn 2000 weight 1 check inter 1s rise 2 fall 2
# inter表示健康检查的间隔,单位为毫秒 可以用1s等,
# fall代表健康检查失败2回后放弃检查。rise代表连续健康检查成功2此后将认为服务器可用。
# 默认的,haproxy认为服务时永远可用的,除非加上check让haproxy确认服务是否真的可用。
Bash4.3. 后端获取客户端真实 IP 地址配置
七层负载均衡获取客户端真实 IP 地址配置示例:
frontend http-in
bind *:80
mode http
# 启用 X-Forwarded-For 并添加客户端 IP
option forwardfor
# 默认情况下,HAProxy 会添加 X-Forwarded-For,但也可以手动设置:
http-request set-header X-Real-IP %[src]
default_backend web_servers
backend web_servers
mode http
balance roundrobin
server web1 192.168.1.1:80 check
server web2 192.168.1.2:80 check
Bash- 关键选项
option forwardfor
HAProxy 自动在请求头中添加X-Forwarded-For
,格式:XX-Forwarded-For: <client_ip>, <proxy1_ip>, <proxy2_ip>…
http-request set-header X-Real-IP %[src]
显式设置X-Real-IP
头,直接存储客户端 IP。
后端服务器读取:
Nginx 示例:
location / {
real_ip_header X-Forwarded-For;
set_real_ip_from 192.168.1.0/24; # 信任 HAProxy 的 IP
# 或者使用 X-Real-IP
# real_ip_header X-Real-IP;
}
BashApache 示例:
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 192.168.1.0/24
Bash四层负载均衡获取客户端真实 IP 地址配置示例:
frontend tcp-in
bind *:3306
mode tcp
default_backend mysql_servers
backend mysql_servers
mode tcp
balance roundrobin
server mysql1 192.168.1.3:3306 check send-proxy
# 或使用 send-proxy-v2(推荐)
server mysql2 192.168.1.4:3306 check send-proxy-v2
Bash- 关键选项
send-proxy
/send-proxy-v2
在 TCP 连接建立时发送 Proxy Protocol 头,包含客户端 IP 和端口。
5. LVS 代理四层负载均衡
LVS(Linux Virtual Server) 是由中国工程师 章文嵩 开发的一个高性能、高可用的 四层(传输层)负载均衡 解决方案,基于 Linux 内核实现。性能能达到硬件负载均衡的60%左右。
LVS 相关专业术语:
- 典型架构术语
- DS (Director Server):运行LVS的主机,负责流量调度。
- RS (Real Server):实际处理请求的后端服务器(如Web、数据库)。
- LVS Cluster:多台Director组成的集群(如主备+Keepalived)。
- 网络与调度术语
- CIP (Client IP):客户端的原始IP地址。
- VIP (Virtual IP):对外暴露的虚拟IP地址,客户端访问的入口。
- RIP (Real Server IP):后端真实服务器的实际IP地址。
- DIP (Director IP):配置在负载均衡器上,用于和内部服务器通讯的IP地址。
LVS 有多种模式,我们主要使用 DR 模式来做四层负载均衡,下面详细介绍 LVS 的DR 模式。
LVS DR(Direct Routing)模式是 Linux Virtual Server 中性能最高的一种负载均衡模式,其核心特点是 后端服务器(Real Server)直接向客户端返回数据,而无需经过负载均衡器(Director)。这使得 DR 模式能够支持极高的吞吐量,适用于高并发场景(如 Web 服务器集群)。
所以 LVS DR 性能高主要基于两点:
- 负责转发工作的 ipvs 是工作在内核态的,不需要经历频繁的用户态与内核态的切换。
- 请求包经过 LVS,而响应包直接由后端服务器向客户端返回数据。
LVS DR 模式工作原理图:
LVS DR 模式配置详解:
- 在 DS (Director Server) 上配置 VIP 和 DIP。
- VIP 和 DIP 可以配置在同一个网卡上且该网卡是连接网线的真实物理网卡。
- 在 RS (Real Server) 上配置 RIP 和 VIP。
- VIP 配置在 lo 网卡上,同时配置ARP 抑制。
- ARP 抑制:RS 必须 隐藏 VIP,仅 DS 对外宣告 VIP。防止多个服务器(DS + RS)同时响应 VIP 的 ARP 请求,导致 IP 冲突。
- lo 网卡上配置 VIP 作用:因为 DS 仅修改客户端请求的目标MAC地址(不修改IP)为一台 RS 的 MAC 地址,在
lo
上配置VIP,使得 RS 能正常接收目标IP为VIP的数据包(内核认为VIP是本地IP)。
- VIP 配置在 lo 网卡上,同时配置ARP 抑制。
- 在 RS 上直接配置路由。
- RS 处理请求后,直接通过 本地路由表 将响应包发送给客户端,绕过 DS。
LVS DR 模式工作流程详解:
- 客户端发起请求
- 客户端发送请求到
VIP:Port
(如192.168.1.100:80
)。 - 请求包:
- 客户端发送请求到
SRC_IP: Client_IP
DST_IP: VIP
DST_MAC: Director_MAC(通过 ARP 解析获得)
Bash- Director 接收并转发请求
- Director 收到请求后,根据 负载均衡算法(如 Round Robin)选择一台 Real Server。
- 修改目标 MAC 地址(不修改 IP/Port)然后将数据包转发给 Real Server:
SRC_IP: Client_IP(不变)
DST_IP: VIP(不变)
DST_MAC: RealServer_MAC(替换为选中的 Real Server 的 MAC)
Bash- Real Server 处理请求
- Real Server 收到数据包,发现目标 IP 是 VIP(本地已配置),因此接受请求。
- 处理请求(如生成 HTTP 响应)。
- 直接返回响应给客户端:
- 源 IP = VIP,目标 IP = Client_IP。
- 通过本地路由表发送,不经过 Director。
- 客户端接收响应
- 客户端收到来自
VIP:Port
的响应,认为请求是 VIP 服务器直接处理的,无感知负载均衡过程。
- 客户端收到来自
LVS DR 模式负载均衡配置参考文档。
6. 基于 DNS 轮询实现负载均衡
DNS 轮询是一种 简单、低成本 的负载均衡方法,通过 DNS 服务器将一个域名解析为多个 IP 地址(后端服务器),并按轮询顺序返回给客户端,从而实现流量的初步分发。