不用等 DNS 缓存刷新了？这里有个小技巧：先用dig +trace完整走一遍解析链路，确认新 IP 已经生效，再决定要不要调低 TTL。另外很多云厂商的 DNS 管理面板有“预取”功能，可以在切换前先把新记录预热起来，实现无缝迁移。这招我靠它躲过好几次流量高峰期的迁移事故。
3.3 高并发场景的演进路线（从单机到集群）
# 用 HAProxy 做负载均衡 + 健康检查 frontend web_front bind *:80 default_backend web_servers backend web_servers balance roundrobin option httpchk GET /healthz server web1 10.0.0.11:8080 check inter 3s fall 3 rise 2 server web2 10.0.0.12:8080 check inter 3s fall 3 rise 2当单台机器扛不住时，加机器是最直接的手段。但加机器不是简单复制一份配置，而是要让整个架构支持水平扩展。上面的 HAProxy 配置就是一个标准的多节点负载均衡方案，balance roundrobin做轮询分发，httpchk定时探测后端健康状态，发现挂掉的节点自动摘除。等到规模再上一个台阶，就可以引入 Kubernetes，用 Deployment 管理无状态应用副本，用 Service 做内部负载均衡，用 Ingress 统一入口。但说实话，很多业务在 5000 并发以内，Nginx 多 worker + 多台云服务器 + Redis 缓存已经绰绰有余。我见过不少团队守着几万并发的业务非要上 K8s，最后光运维成本就压垮了开发节奏。架构升级应该是被动的事，业务到了那个量级再演进，每个人的时间都很贵。
