load-balancing-patterns

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Load Balancing Patterns

负载均衡模式

Distribute traffic across infrastructure using the appropriate load balancing approach, from simple round-robin to global multi-region failover.

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

When to Use This Skill

何时使用本技能

Use load-balancing-patterns when:

Distributing traffic across multiple application servers
Implementing high availability and failover
Routing traffic based on URLs, headers, or geographic location
Managing session persistence across stateless backends
Deploying applications to Kubernetes clusters
Configuring global traffic management across regions
Implementing zero-downtime deployments (blue-green, canary)
Selecting between cloud-managed and self-managed load balancers

在以下场景中使用负载均衡模式：

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

Core Load Balancing Concepts

核心负载均衡概念

Layer 4 vs Layer 7

L4与L7对比

Layer 4 (L4) - Transport Layer:

Routes based on IP address and port (TCP/UDP packets)
No application data inspection, lower latency, higher throughput
Protocol agnostic, preserves client IP addresses
Use for: Database connections, video streaming, gaming, financial transactions, non-HTTP protocols

Layer 7 (L7) - Application Layer:

Routes based on HTTP URLs, headers, cookies, request body
Full application data visibility, SSL/TLS termination, caching, WAF integration
Content-based routing capabilities
Use for: Web applications, REST APIs, microservices, GraphQL endpoints, complex routing logic

For detailed comparison including performance benchmarks and hybrid approaches, see

references/l4-vs-l7-comparison.md

L4（传输层）：

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

L7（应用层）：

基于HTTP URL、请求头、Cookie、请求体进行路由
完全可见应用数据，支持SSL/TLS终止、缓存、WAF集成
具备基于内容的路由能力
适用场景：Web应用、REST API、微服务、GraphQL端点、复杂路由逻辑

如需包含性能基准测试和混合方案的详细对比，请查看

references/l4-vs-l7-comparison.md

。

Load Balancing Algorithms

负载均衡算法

Algorithm	Distribution Method	Use Case
Round Robin	Sequential	Stateless, similar servers
Weighted Round Robin	Capacity-based	Different server specs
Least Connections	Fewest active connections	Long-lived connections
Least Response Time	Fastest server	Performance-sensitive
IP Hash	Client IP-based	Session persistence
Resource-Based	CPU/memory metrics	Varying workloads

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

Health Check Types

健康检查类型

Shallow (Liveness): Is the process alive?

Endpoint:
```
/health/live
```
or
```
/live
```
Returns: 200 if process running
Use for: Process monitoring, container health

Deep (Readiness): Can the service handle requests?

Endpoint:
```
/health/ready
```
or
```
/ready
```
Validates: Database, cache, external API connectivity
Use for: Load balancer routing decisions

Health Check Hysteresis: Different thresholds for marking up vs down to prevent flapping

Example: 3 failures to mark down, 2 successes to mark up

For complete health check implementation patterns, see

references/health-check-strategies.md

**浅度检查（存活态）：**进程是否存活？

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

**深度检查（就绪态）：**服务能否处理请求？

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

**健康检查滞回机制：**标记服务器为可用/不可用使用不同阈值，防止状态频繁切换

示例：连续3次失败标记为不可用，连续2次成功标记为可用

如需完整的健康检查实现模式，请查看

references/health-check-strategies.md

。

Cloud Load Balancers

云负载均衡器

AWS Load Balancing

AWS负载均衡

Application Load Balancer (ALB) - Layer 7:

Use for: HTTP/HTTPS applications, microservices, WebSocket
Features: Path/host/header routing, AWS WAF integration, Lambda targets
Choose when: Content-based routing needed

Network Load Balancer (NLB) - Layer 4:

Use for: Ultra-low latency (<1ms), TCP/UDP, static IPs, millions RPS
Features: Preserves source IP, TLS termination
Choose when: Non-HTTP protocols, performance critical

Global Accelerator - Layer 4 Global:

Use for: Multi-region applications, global users, DDoS protection
Features: Anycast IPs, automatic regional failover

Application Load Balancer (ALB) - L7：

适用场景：HTTP/HTTPS应用、微服务、WebSocket
特性：路径/主机/请求头路由、AWS WAF集成、Lambda目标
选择时机：需要基于内容的路由时

Network Load Balancer (NLB) - L4：

适用场景：超低延迟（<1ms）、TCP/UDP、静态IP、百万级请求每秒（RPS）
特性：保留源IP、TLS终止
选择时机：非HTTP协议、对性能要求极高的场景

Global Accelerator - 全局L4：

适用场景：多区域应用、全球用户、DDoS防护
特性：Anycast IP、自动区域故障转移

GCP Load Balancing

GCP负载均衡

Application LB (L7): Global HTTPS LB, Cloud CDN integration, Cloud Armor (WAF/DDoS) Network LB (L4): Regional TCP/UDP, pass-through balancing, session affinity Cloud Load Balancing: Single anycast IP, global distribution, backend buckets

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

Azure Load Balancing

Azure负载均衡

Application Gateway (L7): WAF integration, URL-based routing, SSL termination, autoscaling Load Balancer (L4): Basic and Standard SKUs, health probes, HA ports Traffic Manager (Global): DNS-based routing (priority, weighted, performance, geographic)

For complete cloud provider configurations and Terraform examples, see

references/cloud-load-balancers.md

**Application Gateway（L7）：**WAF集成、基于URL的路由、SSL终止、自动扩缩容 **Load Balancer（L4）：**基础版与标准版SKU、健康探针、高可用端口 **Traffic Manager（全局）：**基于DNS的路由（优先级、加权、性能、地理位置）

如需完整的云厂商配置和Terraform示例，请查看

references/cloud-load-balancers.md

。

Self-Managed Load Balancers

自托管负载均衡器

NGINX

Best for: General-purpose HTTP/HTTPS load balancing, web application stacks

Capabilities:

HTTP reverse proxy with multiple algorithms
TCP/UDP stream load balancing
SSL/TLS termination
Passive health checks (open source), active health checks (NGINX Plus)
Cookie-based sticky sessions (NGINX Plus)

Basic configuration:

nginx

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;
    }
}

For complete NGINX patterns and advanced configurations, see

references/nginx-patterns.md

**最佳适用场景：**通用HTTP/HTTPS负载均衡、Web应用栈

功能特性：

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

基础配置：

nginx

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

Best for: Maximum performance, database load balancing, resource efficiency

Capabilities:

Highest raw throughput, lowest memory footprint
10+ load balancing algorithms
Sophisticated health checks (HTTP, TCP, Redis, MySQL, etc.)
Cookie or IP-based persistence

Basic configuration:

haproxy

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

For complete HAProxy patterns, see

references/haproxy-patterns.md

**最佳适用场景：**极致性能、数据库负载均衡、资源高效利用

功能特性：

最高的原始吞吐量、最低的内存占用
10+种负载均衡算法
复杂健康检查（HTTP、TCP、Redis、MySQL等）
基于Cookie或IP的会话持久化

基础配置：

haproxy

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

Best for: Microservices, Kubernetes, service mesh integration

Capabilities:

Cloud-native design with dynamic configuration (xDS APIs)
Circuit breakers, retries, timeouts
Advanced health checks (TCP, HTTP, gRPC)
Excellent observability

For complete Envoy patterns, see

references/envoy-patterns.md

**最佳适用场景：**微服务、Kubernetes、服务网格集成

功能特性：

云原生设计，支持动态配置（xDS APIs）
熔断器、重试、超时机制
高级健康检查（TCP、HTTP、gRPC）
优秀的可观测性

如需完整的Envoy模式，请查看

references/envoy-patterns.md

。

Traefik

Best for: Docker/Kubernetes environments, dynamic configuration, ease of use

Capabilities:

Automatic service discovery
Native Kubernetes integration
Built-in Let's Encrypt support
Middleware system (auth, rate limiting)

For complete Traefik patterns, see

references/traefik-patterns.md

**最佳适用场景：**Docker/Kubernetes环境、动态配置、易用性优先

功能特性：

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

如需完整的Traefik模式，请查看

references/traefik-patterns.md

。

Kubernetes Ingress Controllers

Kubernetes Ingress控制器

Selection Guide

选型指南

Controller	Best For	Strengths
NGINX Ingress (F5)	General purpose	Stability, wide adoption, mature features
Traefik	Dynamic environments	Easy configuration, service discovery
HAProxy Ingress	High performance	Advanced L7 routing, reliability
Envoy (Contour/Gateway)	Service mesh	Rich L7 features, extensibility
Kong	API-heavy apps	JWT auth, rate limiting, plugins
Cloud Provider	Single-cloud	Native cloud integration

控制器	最佳适用场景	优势
NGINX Ingress（F5）	通用场景	稳定性、广泛采用、成熟特性
Traefik	动态环境	配置简单、服务发现
HAProxy Ingress	高性能场景	高级L7路由、可靠性
Envoy（Contour/Gateway）	服务网格	丰富的L7特性、可扩展性
Kong	以API为主的应用	JWT认证、速率限制、插件系统
云厂商原生控制器	单一云环境	原生云集成

Basic Ingress Example

基础Ingress示例

yaml

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

For complete Kubernetes ingress examples and Gateway API patterns, see

references/kubernetes-ingress.md

yaml

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

。

Session Persistence

会话持久化

Sticky Sessions (Use Sparingly)

粘性会话（谨慎使用）

Cookie-Based: Load balancer sets cookie to track server affinity

Accurate routing, works with NAT/proxies
HTTP only, adds cookie overhead

IP Hash: Hash client IP to select backend server

No cookie required, works for non-HTTP
Poor distribution with NAT/proxies

Drawbacks: Uneven load distribution, session lost on server failure, complicates scaling

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

路由精准，适用于NAT/代理场景
仅HTTP协议可用，增加Cookie开销

**IP哈希：**基于客户端IP哈希值选择后端服务器

无需Cookie，适用于非HTTP协议
在NAT/代理场景下分发效果差

**缺点：**负载分布不均，服务器故障会丢失会话，扩缩容复杂

Shared Session Store (Recommended)

共享会话存储（推荐）

Architecture: Stateless application servers + centralized session storage (Redis, Memcached)

Benefits:

No sticky sessions needed
True load balancing
Server failures don't lose sessions
Horizontal scaling trivial

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

优势：

无需粘性会话
真正的负载均衡
服务器故障不会丢失会话
水平扩缩容简单

Client-Side Tokens (Best for APIs)

客户端令牌（API场景最佳）

JWT (JSON Web Tokens): Server generates signed token, client stores and sends with requests

Benefits:

Fully stateless servers
Perfect load balancing
No session storage needed

For complete session management patterns and code examples, see

references/session-persistence.md

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

优势：

服务器完全无状态
完美的负载均衡
无需会话存储

如需完整的会话管理模式和代码示例，请查看

references/session-persistence.md

。

Global Load Balancing

全局负载均衡

GeoDNS Routing

GeoDNS路由

Route users to nearest server based on geographic location:

DNS returns different IPs based on client location
Reduces latency, supports compliance and regional content
Implementation: AWS Route 53, GCP Cloud DNS, Azure Traffic Manager

基于地理位置将用户路由至最近的服务器：

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

Multi-Region Failover

多区域故障转移

Primary/secondary region configuration:

Health checks determine primary region health
Automatic DNS failover to secondary
Transparent to clients

主/备区域配置：

健康检查判断主区域健康状态
自动通过DNS故障转移至备区域
对客户端透明

CDN Integration

CDN集成

Combine load balancing with CDN:

GeoDNS routes to closest CDN PoP
CDN caches content globally
Origin load balancing for cache misses

For complete global load balancing examples with Terraform, see

references/global-load-balancing.md

负载均衡与CDN结合：

GeoDNS路由至最近的CDN节点
CDN在全球缓存内容
缓存未命中时使用源站负载均衡

如需完整的全局负载均衡Terraform示例，请查看

references/global-load-balancing.md

。

Decision Frameworks

决策框架

L4 vs L7 Selection

L4与L7选型

Choose L4 when:

Protocol is TCP/UDP (not HTTP)
Ultra-low latency critical (<1ms)
High throughput required (millions RPS)
Client source IP preservation needed

Choose L7 when:

Protocol is HTTP/HTTPS
Content-based routing needed (URL, headers)
SSL termination required
WAF integration needed
Microservices architecture

选择L4的场景：

协议为TCP/UDP（非HTTP）
对超低延迟要求极高（<1ms）
需要高吞吐量（百万级RPS）
需要保留客户端源IP

选择L7的场景：

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

Cloud vs Self-Managed

云托管与自托管选型

Choose Cloud-Managed when:

Single cloud deployment
Auto-scaling required
Team lacks load balancer expertise
Managed service preferred

Choose Self-Managed when:

Multi-cloud or hybrid deployment
Advanced routing requirements
Cost optimization important
Full control needed
Vendor lock-in avoidance

选择云托管的场景：

单一云部署
需要自动扩缩容
团队缺乏负载均衡器专业知识
偏好托管服务

选择自托管的场景：

多云或混合云部署
有高级路由需求
成本优化需求高
需要完全控制权
避免厂商锁定

Self-Managed Selection

自托管负载均衡器选型

NGINX: General-purpose, web stacks, HTTP/3 support
HAProxy: Maximum performance, database LB, lowest resource usage
Envoy: Microservices, service mesh, dynamic configuration
Traefik: Docker/Kubernetes, automatic discovery, easy configuration

**NGINX：**通用场景、Web应用栈、支持HTTP/3
**HAProxy：**极致性能、数据库负载均衡、资源占用最低
**Envoy：**微服务、服务网格、动态配置
**Traefik：**Docker/Kubernetes环境、自动发现、配置简单

Configuration Examples

配置示例

Complete working examples available in

examples/

directory:

Cloud Providers:

```
examples/aws/alb-terraform.tf
```
- AWS ALB with path-based routing
```
examples/aws/nlb-terraform.tf
```
- AWS NLB for TCP load balancing

Self-Managed:

```
examples/nginx/http-load-balancing.conf
```
- NGINX HTTP reverse proxy
```
examples/haproxy/http-lb.cfg
```
- HAProxy configuration
```
examples/envoy/basic-lb.yaml
```
- Envoy cluster configuration

examples/traefik/kubernetes-ingress.yaml

- Traefik IngressRoute

Kubernetes:

```
examples/kubernetes/nginx-ingress.yaml
```
- NGINX Ingress with TLS

examples/kubernetes/traefik-ingress.yaml

- Traefik IngressRoute

```
examples/kubernetes/gateway-api.yaml
```
- Gateway API configuration

完整的可运行示例位于

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配置

Monitoring and Observability

监控与可观测性

Key Metrics

关键指标

Throughput: Requests per second, bytes transferred, connection rate Latency: Request duration (p50, p95, p99), backend response time, SSL handshake time Errors: HTTP error rates (4xx, 5xx), backend connection failures, health check failures Resource Utilization: CPU, memory, active connections, connection queue depth Health: Healthy/unhealthy backend count, health check success rate

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

Load Balancer Logs

负载均衡器日志

Enable access logs for request/response details, client IPs, response times, error tracking

AWS ALB: Store in S3, analyze with Athena
NGINX: Custom log format, ship to centralized logging
HAProxy: Syslog integration, structured logging

启用访问日志以获取请求/响应详情、客户端IP、响应时间、错误追踪

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

Troubleshooting

故障排除

Uneven Load Distribution

负载分布不均

Symptoms: One server receives disproportionate traffic Causes: Sticky sessions with few clients, IP hash with NAT concentration, long-lived connections Solutions: Switch to least connections, disable sticky sessions, implement connection draining

**症状：**某台服务器接收流量占比过高 **原因：**粘性会话但客户端数量少、IP哈希在NAT场景下集中、长连接 **解决方案：**切换至最少连接数算法、禁用粘性会话、实现连接排空

Health Check Flapping

健康检查状态频繁切换

Symptoms: Servers rapidly transition between healthy/unhealthy Causes: Health check timeout too short, threshold too low, network instability Solutions: Increase interval and timeout, implement hysteresis, use deep health checks

**症状：**服务器在可用/不可用状态间快速切换 **原因：**健康检查超时时间过短、阈值过低、网络不稳定 **解决方案：**增加检查间隔和超时时间、实现滞回机制、使用深度健康检查

Session Loss After Failover

故障转移后会话丢失

Symptoms: Users logged out when server fails Causes: Sticky sessions without replication, in-memory sessions Solutions: Implement shared session store (Redis), use client-side tokens (JWT)

**症状：**服务器故障时用户被登出 **原因：**使用粘性会话但无复制、会话存储在内存中 **解决方案：**实现共享会话存储（Redis）、使用客户端令牌（JWT）

Integration Points

集成点

Related Skills:

```
infrastructure-as-code
```
- Deploy load balancers via Terraform/Pulumi
```
kubernetes-operations
```
- Ingress controllers for K8s traffic management
```
network-architecture
```
- Network design and topology for load balancing
```
deploying-applications
```
- Blue-green and canary deployments via load balancers
```
observability
```
- Load balancer metrics, access logs, distributed tracing
```
security-hardening
```
- WAF integration, rate limiting, DDoS protection
```
service-mesh
```
- Envoy as both ingress and service mesh proxy
```
implementing-tls
```
- TLS termination and certificate management

相关技能：

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

Quick Reference

快速参考

Selection Matrix

选型矩阵

Use Case	Recommended Solution
HTTP web app (AWS)	ALB
Non-HTTP protocol (AWS)	NLB
Kubernetes HTTP ingress	NGINX Ingress or Traefik
Maximum performance	HAProxy
Service mesh	Envoy
Docker Swarm	Traefik
Multi-cloud portable	NGINX or HAProxy
Global distribution	CloudFlare, AWS Global Accelerator

适用场景	推荐方案
HTTP Web应用（AWS）	ALB
非HTTP协议（AWS）	NLB
Kubernetes HTTP Ingress	NGINX Ingress 或 Traefik
极致性能需求	HAProxy
服务网格	Envoy
Docker Swarm	Traefik
多云可移植	NGINX 或 HAProxy
全球分发	CloudFlare、AWS Global Accelerator

Algorithm Selection

算法选型

Traffic Pattern	Algorithm
Stateless, similar servers	Round Robin
Stateless, different capacity	Weighted Round Robin
Long-lived connections	Least Connections
Performance-sensitive	Least Response Time
Session persistence needed	IP Hash or Cookie
Varying server load	Resource-Based

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

Health Check Configuration

健康检查配置

Service Type	Check Type	Interval	Timeout
Web app	HTTP /health	10s	3s
API	HTTP /health/ready	10s	5s
Database	TCP connect	5s	2s
Critical service	HTTP deep check	5s	3s
Background worker	HTTP /live	30s	5s

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

Summary

总结

Load balancing is essential for distributing traffic, ensuring high availability, and enabling horizontal scaling. Choose L4 for raw performance and non-HTTP protocols, L7 for intelligent content-based routing. Prefer cloud-managed load balancers for simplicity and auto-scaling, self-managed for multi-cloud portability and advanced features. Implement proper health checks with hysteresis, avoid sticky sessions when possible, and monitor key metrics continuously.

For deployment patterns, see examples in

examples/aws/

examples/nginx/

examples/kubernetes/

, and other provider directories.

负载均衡是流量分发、高可用性保障和水平扩缩容的核心技术。L4适用于追求原始性能和非HTTP协议的场景，L7适用于智能内容路由的场景。云托管负载均衡器优先用于简化操作和自动扩缩容，自托管负载均衡器优先用于多云可移植性和高级特性。需配置带滞回机制的健康检查，尽可能避免粘性会话，并持续监控关键指标。

如需部署模式，请查看

examples/aws/

、

examples/nginx/

、

examples/kubernetes/

及其他厂商目录下的示例。