Http负载均衡参数怎么配？Http负载均衡算法有哪些

HTTP 负载均衡（HTTP Load Balancing）是应用层负载均衡的核心技术，它基于 HTTP 协议的特性（如 URL、Header、Cookie 等）进行流量分发，与传统的 TCP/UDP 负载均衡不同，HTTP 负载均衡具备更细粒度的控制能力，能够理解应用层语义,从而实现更智能的路由策略。

以下是关于 HTTP 负载均衡关键参数的详细解析。

基础连接与会话保持参数

这些参数决定了客户端与负载均衡器（LB）以及负载均衡器与后端服务器之间的连接行为。

HTTP 头部处理参数

HTTP 负载均衡器可以修改、添加或删除 HTTP 请求头,这对于后端应用识别客户端信息至关重要。

• X-Forwarded-For (XFF):
  • 作用: 保留客户端的真实 IP 地址，当请求经过多层代理时，LB 会将客户端 IP 追加到 X-Forwarded-For 头部。
  • 配置: 通常默认开启，需注意防止杜撰 IP，后端应用应信任 LB 传来的 XFF 值。

• Host 头部重写:
  • 作用: 如果后端服务器依赖 Host 头进行虚拟主机路由，LB 可能需要重写 Host 头以匹配后端服务器的配置。
  • 场景: 内部服务使用非标准域名,但后端应用期望看到标准域名。

• 自定义 Header 载入:
  • 作用: 在请求中载入自定义头部（如 X-Request-ID, X-Trace-ID）,用于全链路追踪和日志分析。
  • 示例: add_header X-Request-ID $uuid;

路由与重写参数

这些参数用于根据请求内容将流量引导至不同的后端服务集群。

高级功能与安全参数

现代 HTTP 负载均衡器通常集成 WAF（Web 应用防火墙）和 SSL 卸载功能。

• SSL/TLS 卸载 (SSL Offloading):
  • 描述: LB 终止 HTTPS 连接，解密流量后以 HTTP 形式转发给后端。
  • 优势: 减轻后端服务器 CPU 负担,简化证书管理。
  • 参数: 证书文件路径、协议版本（TLS 1.2/1.3）、加密套件。

• 请求大小限制 (Request Size Limit):
  • 描述: 限制客户端上传的请求体大小。
  • 示例: client_max_body_size 10m;
  • 作用: 防止恶意大文件上传导致后端存储或带宽耗尽。

• 限流与熔断 (Rate Limiting & Circuit Breaking):
  • 描述: 限制单位时间内的请求数或并发连接数。
  • 参数: rate: 100r/s, burst: 50
  • 作用: 保护后端服务免受 分布 攻破或突发流量冲击。

配置示例 (Nginx 风格)

以下是一个典型的 HTTP 负载均衡配置片段,展示了上述参数的综合应用：

upstream backend_servers { # 1. 负载均衡算法：加权轮询 least_conn; server 192.168.1.10:8080 weight=5; server 192.168.1.11:8080 weight=3; # 2. 健康检查（Nginx Plus 或第三方模块支持） health_check interval=10 fails=3 passes=2; } server { listen 443 ssl; server_name api.example.com; # 3. SSL 卸载配置 ssl_certificate /etc/ssl/certs/api.pem; ssl_certificate_key /etc/ssl/private/api.key; ssl_protocols TLSv1.2 TLSv1.3; # 4. 请求大小限制 client_max_body_size 5m; location /api/ { # 5. 路径匹配与反向代理 proxy_pass http://backend_servers; # 6. 头部处理 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-Request-ID $request_id; # 7. 超时设置 proxy_connect_timeout 5s; proxy_read_timeout 30s; proxy_send_timeout 30s; } }

相关问题与解答

问题 1：在 HTTP 负载均衡中，为什么有时需要开启“会话保持”（Session Affinity），而在微服务架构中又常常建议关闭它？

解答：

开启会话保持的主要原因是为了兼容有状态应用，如果后端应用将用户会话信息（如登录状态、购物车数据）存储在服务器本地内存或本地磁盘中，那么后续请求必须路由到同一台服务器，否则用户会遭遇“未登录”或数据丢失，常见的实现方式包括基于 Cookie 插入（LB 在响应中载入 Cookie）或基于源 IP 哈希。

在微服务架构和云原生环境中，通常建议关闭会话保持,原因如下：

1. 无状态设计：现代微服务通常设计为无状态，会话数据存储在外部集中式存储（如 Redis、Memcached）中,任何服务器都可以处理任何请求。
2. 弹性伸缩：关闭会话保持允许负载均衡器更均匀地分发流量，便于根据负载动态增加或减少后端实例，而无需担心“绑定”问题。
3. 故障转移：如果某台服务器宕机，基于 IP Hash 的会话保持可能导致部分用户无法立即切换到新实例,而轮询算法能更快恢复服务。

问题 2：HTTP 负载均衡器中的“健康检查”失败后，流量是如何处理的？如果所有后端服务器都标记为不健康，会发生什么？

解答：

当负载均衡器执行健康检查（如发送 HTTP GET 请求到 /health 端点）并收到非 2xx/3xx 状态码或超时未响应时，会将该后端服务器标记为“不健康”或“下线”。

• 流量处理：LB 会立即从上游服务器的可用列表中移除该节点，后续的新请求将不再被分发到该服务器，直到健康检查再次成功将其标记为“健康”。
• 所有服务器不健康的后果：如果所有后端服务器均被标记为不健康，负载均衡器通常有两种处理策略：
  1. 返回错误：向客户端返回 502 Bad Gateway 或 503 Service Unavailable 错误,表明后端服务暂时不可用。
  2. 继续转发（兜底策略）：某些配置允许 LB 继续将流量发送到标记为不健康的服务器（称为“兜底”或“fallback”模式），这通常用于维护场景，允许管理员在不中断服务的情况下重启单个节点，但需谨慎使用,因为可能导致请求失败。