Nginx集群架构设计

生产环境需要多层架构确保高可用、可扩展和易维护。NGINX 集群通常分为入口层、分发层、应用层和数据层。

典型架构

                    ┌─────────────┐
                    │  DNS/CDN    │
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
        ┌─────▼─────┐ ┌───▼────┐ ┌────▼────┐
        │ Keepalived│ │ LB-N1  │ │ LB-N2   │  ← 入口层（VIP）
        │ VIP       │ └───┬────┘ └────┬────┘
        └─────────────┘     │         │
                            │         │
              ┌─────────────┼─────────┼─────────────┐
              │             │         │             │
        ┌─────▼────┐  ┌────▼───┐ ┌──▼────┐ ┌─────▼────┐
        │ NGINX-1  │  │ NGINX-2│ │ NGINX-3│ │ NGINX-4 │  ← 反向代理层
        └─────┬────┘  └────┬───┘ └──┬────┘ └─────┬────┘
              │             │        │            │
              └─────────────┼────────┼────────────┘
                            │        │
              ┌─────────────┼────────┼─────────────┐
              │             │        │             │
        ┌─────▼────┐  ┌────▼───┐ ┌──▼────┐ ┌─────▼────┐
        │ APP-1    │  │ APP-2  │ │ APP-3 │ │ APP-4   │  ← 应用层
        └──────────┘  └────────┘ └───────┘ └──────────┘
                            │
                    ┌───────▼───────┐
                    │ Redis/MySQL   │  ← 数据层
                    └───────────────┘

各层职责

入口层（L4/L7）

# L4 负载均衡（HAProxy/Keepalived）
# 仅做 TCP 层转发，不解析 HTTP

• 使用 Keepalived + VIP 提供故障转移
• 或使用云厂商的 L4 负载均衡器（ALB/SLB）
• 将流量分发到反向代理层

反向代理层

upstream app_pool {
    server app1:8080 max_fails=3 fail_timeout=30s;
    server app2:8080 max_fails=3 fail_timeout=30s;
    server app3:8080 max_fails=3 fail_timeout=30s;
    server app4:8080 max_fails=3 fail_timeout=30s;
    
    keepalive 64;
}

server {
    listen 80;
    
    # SSL 终止
    listen 443 ssl http2;
    
    # 静态资源
    location /static/ {
        root /var/www;
        expires 365d;
    }
    
    # 动态请求
    location / {
        proxy_pass http://app_pool;
    }
}

• SSL/TLS 终止
• 静态资源服务
• 请求路由和负载均衡
• 限流和访问控制
• 日志收集

应用层

• 业务逻辑处理
• 水平扩展（无状态设计）
• Session 存储在 Redis

数据层

• Redis（缓存/Session）
• MySQL/PostgreSQL（持久化存储）
• 读写分离和分库分表

弹性扩展

动态扩缩容

# 使用 Consul + consul-template 自动更新 upstream
upstream app_pool {
    {{ range service "app" }}
    server {{ .Address }}:{{ .Port }};
    {{ end }}
}

consul-template 监控服务注册/注销，自动更新 NGINX 配置并 reload。

云原生方案

# Kubernetes Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/limit-connections: "10"
    nginx.ingress.kubernetes.io/limit-rps: "5"
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  number: 80

K8s Ingress Controller 基于 NGINX 实现动态配置。Service 端点变化自动更新 upstream。

容灾设计

多活架构

Region A (主)          Region B (备)
├── NGINX × 2          ├── NGINX × 2
├── App × 4            ├── App × 4
└── Redis (主) ──────→ Redis (从)

• DNS 多活解析或 GSLB 实现跨地域负载均衡
• Redis 主从同步或 Cluster 跨地域部署
• RPO（恢复点目标）取决于数据同步策略

要点总结

• 典型四层架构：入口层 → 反向代理层 → 应用层 → 数据层
• 入口层使用 Keepalived + VIP 或云 L4 负载均衡
• 反向代理层负责 SSL 终止、限流、路由和缓存
• 应用层无状态设计，便于水平扩展
• consul-template 或 K8s Ingress 实现动态配置
• 多活架构跨地域部署提高可用性
• 容灾设计需考虑 RPO 和 RTO 目标