真正降低单节点压力需分层集群架构：第一层DNS/Anycast全局粗粒度分流；第二层边缘Nginx集群专注TLS卸载、WAF、限流与灰度；第三层业务网关按weight、max_conns等精细控流，并配套配置即代码与自动化巡检。
要真正降低单节点压力，不能只靠“多加几台 Nginx”，而得靠分层分工的集群架构——把流量在不同层级上合理切分、动态调度、按需承载。
第一层：DNS 或 Anycast 做全局粗粒度分流
最外层不处理业务逻辑，只负责把用户请求初步导向离他最近的接入区域。DNS 轮询可快速上线，TTL 设为 60 秒便于紧急切流；Anycast 更优，同一 IP 在多地广播，网络自动选最优路径，机房故障时流量秒级迁移，无需等 DNS 生效。中小团队若暂不支持 Anycast，可用 HTTP 302 重定向兜底。
第二层：边缘 Nginx 集群专注安全与协议卸载
每个区域部署 ≥3 台 Nginx 实例，用 Keepalived/VRRP 或云厂商 SLB（如 ALB/CLB）提供 VIP 高可用。这一层干四件事：TLS 卸载、WAF 规则过滤、统一限流熔断、灰度标透传。它不绑定具体后端服务，避免把业务路由逻辑堆在边缘，保持轻量和可维护性。
- 用 upstream + health_check 主动探测后端健康状态，失败即隔离
- Web API 推荐无状态设计，慎用 ip_hash；需要会话保持时优先考虑应用层方案
- 启用 keepalive 减少 TCP 握手开销，提升吞吐效率
第三层：业务网关集群按能力精细分发
这一层直连真实后端服务，核心是让每台机器只承担它能扛住的流量。小内存节点不是“避开”，而是“控流”：
- 显式配置 weight：4C8G 节点设
weight=1，8C16G 设weight=4，请求按比例分配 - 加上 max_conns：如
max_conns=10，防长尾请求占满连接导致雪崩 - 配 max_fails + fail_timeout：连续 2 次失败，10 秒内不再转发，避免持续打挂弱节点
- 禁用 backup 标识——它不是低优先级轮询，而是最后兜底，反而会让小内存机器在最差时刻扛全部流量
配套机制：配置即代码 + 自动化巡检
所有 upstream、健康检查、超时参数都应纳入版本管理，通过 CI/CD 自动发布。搭配定时巡检脚本，验证：
- upstream 中各节点 weight 是否生效
- health_check 是否正常探测 /healthz
- proxy_read_timeout 等参数是否匹配压测或生产实际延迟
- 日志中 502/503 出现频率是否异常升高
不复杂但容易忽略。
