load-balancing-patterns

负载均衡模式

使用合适的负载均衡方法，在基础设施间分配流量，从简单的轮询到全球多区域故障转移。

何时使用此技能

在以下情况使用 load-balancing-patterns：

• 在多台应用服务器间分配流量
• 实现高可用性和故障转移
• 根据 URL、标头或地理位置路由流量
• 管理无状态后端的会话持久性
• 将应用部署到 Kubernetes 集群
• 配置跨区域的全局流量管理
• 实现零停机部署（蓝绿部署、金丝雀发布）
• 在云托管和自托管负载均衡器之间进行选择

负载均衡核心概念

第 4 层与第 7 层

第 4 层（L4）— 传输层：

• 根据 IP 地址和端口（TCP/UDP 数据包）进行路由
• 不检查应用数据，延迟更低，吞吐量更高
• 与协议无关，可保留客户端 IP 地址
• 适用于：数据库连接、视频流、游戏、金融交易、非 HTTP 协议

第 7 层（L7）— 应用层：

• 根据 HTTP URL、标头、Cookie 和请求正文进行路由
• 可全面查看应用数据，支持 SSL/TLS 终止、缓存和 WAF 集成
• 支持基于内容的路由
• 适用于：Web 应用、REST API、微服务、GraphQL 端点、复杂路由逻辑

如需详细比较（包括性能基准和混合方案），请参阅 references/l4-vs-l7-comparison.md。

负载均衡算法

算法	分配方式	使用场景
轮询	依次分配	无状态、配置相近的服务器
加权轮询	按容量分配	服务器规格不同
最少连接数	分配给活动连接数最少的服务器	长连接
最短响应时间	分配给响应最快的服务器	对性能敏感
IP 哈希	基于客户端 IP	会话持久性
基于资源	根据 CPU/内存指标	工作负载变化较大

健康检查类型

浅层检查（存活状态）： 进程是否存活？

• 端点：/health/live 或 /live
• 返回值：进程运行时返回 200
• 适用于：进程监控、容器健康检查

深层检查（就绪状态）： 服务是否能够处理请求？

• 端点：/health/ready 或 /ready
• 验证内容：数据库、缓存、外部 API 的连通性
• 适用于：负载均衡器的路由决策

健康检查迟滞： 标记为正常与异常时使用不同的阈值，以避免状态抖动

• 示例：连续失败 3 次后标记为异常，连续成功 2 次后标记为正常

如需完整的健康检查实现模式，请参阅 references/health-check-strategies.md。

云负载均衡器

AWS 负载均衡

应用负载均衡器（ALB）— 第 7 层：

• 适用于：HTTP/HTTPS 应用、微服务、WebSocket
• 功能：路径/主机/标头路由、AWS WAF 集成、Lambda 目标
• 适用情况：需要基于内容的路由

网络负载均衡器（NLB）— 第 4 层：

• 适用于：超低延迟（<1ms）、TCP/UDP、静态 IP、每秒数百万次请求
• 功能：保留源 IP、TLS 终止
• 适用情况：非 HTTP 协议、对性能要求极高

Global Accelerator — 全球第 4 层：

• 适用于：多区域应用、全球用户、DDoS 防护
• 功能：Anycast IP、自动区域故障转移

GCP 负载均衡

应用负载均衡器（L7）： 全球 HTTPS 负载均衡器、Cloud CDN 集成、Cloud Armor（WAF/DDoS） 网络负载均衡器（L4）： 区域 TCP/UDP、直通式均衡、会话亲和性 Cloud Load Balancing： 单个 Anycast IP、全球分发、后端存储桶

Azure 负载均衡

Application Gateway（L7）： WAF 集成、基于 URL 的路由、SSL 终止、自动缩放 Load Balancer（L4）： Basic 和 Standard SKU、运行状况探测、高可用性端口 Traffic Manager（全球）： 基于 DNS 的路由（优先级、加权、性能、地理位置）

如需完整的云服务提供商配置和 Terraform 示例，请参阅 references/cloud-load-balancers.md。

自管理负载均衡器

NGINX

最适合： 通用 HTTP/HTTPS 负载均衡、Web 应用技术栈

功能：

• 支持多种算法的 HTTP 反向代理
• TCP/UDP 流量负载均衡
• SSL/TLS 终止
• 被动健康检查（开源版），主动健康检查（NGINX Plus）
• 基于 Cookie 的粘性会话（NGINX Plus）

基本配置：

upstream backend {
    least_conn;
    server backend1.example.com:8080 weight=3;
    server backend2.example.com:8080 weight=2;
    keepalive 32;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

如需完整的 NGINX 模式和高级配置，请参阅 references/nginx-patterns.md。

HAProxy

最适合： 极致性能、数据库负载均衡、资源效率

功能：

• 最高原始吞吐量、最低内存占用
• 10 多种负载均衡算法
• 精密的健康检查（HTTP、TCP、Redis、MySQL 等）
• 基于 Cookie 或 IP 的持久性

基本配置：

frontend http_front
    bind *:80
    default_backend web_servers

backend web_servers
    balance roundrobin
    option httpchk GET /health
    server web1 192.168.1.101:8080 check
    server web2 192.168.1.102:8080 check

如需完整的 HAProxy 模式，请参阅 references/haproxy-patterns.md。

Envoy

最适合： 微服务、Kubernetes、服务网格集成

功能：

• 采用云原生设计，支持动态配置（xDS API）
• 熔断、重试、超时
• 高级健康检查（TCP、HTTP、gRPC）
• 出色的可观测性

如需完整的 Envoy 模式，请参阅 references/envoy-patterns.md。

Traefik

最适合： Docker/Kubernetes 环境、动态配置、易于使用

功能：

• 自动服务发现
• 原生 Kubernetes 集成
• 内置 Let's Encrypt 支持
• 中间件系统（身份验证、速率限制）

如需完整的 Traefik 模式，请参阅 references/traefik-patterns.md。

Kubernetes Ingress 控制器

选择指南

控制器	最适合	优势
NGINX Ingress (F5)	通用场景	稳定性、广泛采用、功能成熟
Traefik	动态环境	配置简单、服务发现
HAProxy Ingress	高性能	高级 L7 路由、可靠性
Envoy (Contour/Gateway)	服务网格	丰富的 L7 功能、可扩展性
Kong	API 密集型应用	JWT 身份验证、速率限制、插件
云服务提供商	单一云环境	原生云集成

基本 Ingress 示例

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/affinity: "cookie"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - app.example.com
    secretName: app-tls
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

如需完整的 Kubernetes ingress 示例和 Gateway API 模式，请参阅 references/kubernetes-ingress.md。

会话持久性

粘性会话（谨慎使用）

基于 Cookie： 负载均衡器设置 Cookie 以追踪服务器亲和性

• 路由准确，适用于 NAT/代理
• 仅适用于 HTTP，会增加 Cookie 开销

IP 哈希： 对客户端 IP 进行哈希，以选择后端服务器

• 无需 Cookie，适用于非 HTTP 流量
• 使用 NAT/代理时分配效果较差

缺点： 负载分配不均、服务器故障时会丢失会话、增加扩展复杂度

共享会话存储（推荐）

架构：无状态应用服务器 + 集中式会话存储（Redis、Memcached）

优势：

• 无需粘性会话
• 真正的负载均衡
• 服务器故障不会导致会话丢失
• 轻松实现横向扩展

客户端令牌（最适合 API）

JWT（JSON Web Tokens）：服务器生成签名令牌，客户端存储该令牌并随请求发送

优势：

• 服务器完全无状态
• 负载均衡效果理想
• 无需会话存储

如需完整的会话管理模式和代码示例，请参阅 references/session-persistence.md。

全局负载均衡

GeoDNS 路由

根据地理位置将用户路由到最近的服务器：

• DNS 根据客户端位置返回不同的 IP
• 降低延迟，支持合规要求和区域内容
• 实现方式：AWS Route 53、GCP Cloud DNS、Azure Traffic Manager

多区域故障转移

主/次区域配置：

• 健康检查用于确定主区域的健康状态
• 自动通过 DNS 故障转移到次区域
• 对客户端透明

CDN 集成

将负载均衡与 CDN 结合：

• GeoDNS 将请求路由到最近的 CDN PoP
• CDN 在全球缓存内容
• 缓存未命中时由源站进行负载均衡

如需查看使用 Terraform 实现全球负载均衡的完整示例，请参阅 references/global-load-balancing.md。

决策框架

L4 与 L7 的选择

在以下情况下选择 L4：

• 协议为 TCP/UDP（而非 HTTP）
• 超低延迟至关重要（<1ms）
• 需要高吞吐量（每秒数百万个请求）
• 需要保留客户端源 IP

在以下情况下选择 L7：

• 协议为 HTTP/HTTPS
• 需要基于内容路由（URL、标头）
• 需要 SSL 终止
• 需要集成 WAF
• 采用微服务架构

云托管与自行管理

在以下情况下选择云托管：

• 部署在单一云平台
• 需要自动扩缩
• 团队缺乏负载均衡器方面的专业知识
• 倾向于使用托管服务

在以下情况下选择自行管理：

• 多云或混合部署
• 有高级路由需求
• 重视成本优化
• 需要完全控制
• 希望避免供应商锁定

自行管理方案的选择

• NGINX： 通用场景、Web 技术栈、支持 HTTP/3
• HAProxy： 追求最高性能、数据库负载均衡、资源占用最低
• Envoy： 微服务、服务网格、动态配置
• Traefik： Docker/Kubernetes、自动发现、配置简单

配置示例

examples/ 目录中提供了可直接运行的完整示例：

云服务提供商：

• examples/aws/alb-terraform.tf - 配置基于路径路由的 AWS ALB
• examples/aws/nlb-terraform.tf - 用于 TCP 负载均衡的 AWS NLB

自行管理：

• examples/nginx/http-load-balancing.conf - NGINX HTTP 反向代理
• examples/haproxy/http-lb.cfg - HAProxy 配置
• examples/envoy/basic-lb.yaml - Envoy 集群配置
• examples/traefik/kubernetes-ingress.yaml - Traefik IngressRoute

Kubernetes：

• examples/kubernetes/nginx-ingress.yaml - 带 TLS 的 NGINX Ingress
• examples/kubernetes/traefik-ingress.yaml - Traefik IngressRoute
• examples/kubernetes/gateway-api.yaml - Gateway API 配置

监控与可观测性

关键指标

吞吐量： 每秒请求数、传输字节数、连接速率 延迟： 请求耗时（p50、p95、p99）、后端响应时间、SSL 握手时间 错误： HTTP 错误率（4xx、5xx）、后端连接失败次数、运行状况检查失败次数 资源利用率： CPU、内存、活动连接数、连接队列深度 运行状况： 健康/不健康后端数量、运行状况检查成功率

负载均衡器日志

启用访问日志以记录请求/响应详情、客户端 IP、响应时间和错误

• AWS ALB： 存储在 S3 中，使用 Athena 分析
• NGINX： 自定义日志格式，并发送到集中式日志系统
• HAProxy： 集成 Syslog，使用结构化日志

故障排查

负载分配不均

症状： 某台服务器收到的流量远超其他服务器 原因： 客户端数量较少时启用了会话保持、NAT 导致 IP 哈希集中、连接持续时间过长 解决方案： 改用最少连接算法、禁用会话保持、实现连接排空

运行状况检查反复切换

症状： 服务器在健康与不健康状态之间快速切换 原因： 运行状况检查超时时间过短、阈值过低、网络不稳定 解决方案： 延长检查间隔和超时时间、实现迟滞机制、使用深度运行状况检查

故障转移后会话丢失

症状： 服务器故障时用户被登出 原因： 会话保持未配置复制、使用内存中的会话 解决方案： 实现共享会话存储（Redis）、使用客户端令牌（JWT）

集成点

相关技能：

• infrastructure-as-code - 通过 Terraform/Pulumi 部署负载均衡器
• kubernetes-operations - 用于 K8s 流量管理的 Ingress 控制器
• network-architecture - 负载均衡的网络设计和拓扑
• deploying-applications - 通过负载均衡器进行蓝绿部署和金丝雀部署
• observability - 负载均衡器指标、访问日志、分布式追踪
• security-hardening - WAF 集成、速率限制、DDoS 防护
• service-mesh - Envoy 同时用作入口和服务网格代理
• implementing-tls - TLS 终止和证书管理

快速参考

选择矩阵

用例	推荐方案
HTTP Web 应用（AWS）	ALB
非 HTTP 协议（AWS）	NLB
Kubernetes HTTP 入口	NGINX Ingress 或 Traefik
最高性能	HAProxy
服务网格	Envoy
Docker Swarm	Traefik
多云可移植	NGINX 或 HAProxy
全球分发	CloudFlare、AWS Global Accelerator

算法选择

流量模式	算法
无状态、服务器性能相近	轮询
无状态、服务器容量不同	加权轮询
长连接	最少连接数
对性能敏感	最短响应时间
需要会话持久性	IP 哈希或 Cookie
服务器负载各异	基于资源

健康检查配置

服务类型	检查类型	间隔	超时
Web 应用	HTTP /health	10s	3s
API	HTTP /health/ready	10s	5s
数据库	TCP 连接	5s	2s
关键服务	HTTP 深度检查	5s	3s
后台工作器	HTTP /live	30s	5s

总结

负载均衡对于分发流量、确保高可用性和实现水平扩展至关重要。原始性能和非 HTTP 协议场景应选择 L4，智能内容路由应选择 L7。为简化运维和自动扩缩容，优先选择云托管负载均衡器；为实现多云可移植性和使用高级功能，可选择自行管理。实施带滞回机制的适当健康检查，尽可能避免粘性会话，并持续监控关键指标。

有关部署模式，请参阅 examples/aws/、examples/nginx/、examples/kubernetes/ 和其他提供商目录中的示例。