台湾站群20m场景下的负载均衡与流量分配最佳实践

1. 概述与目标

1. 目标：保证台湾站群在20m级别PV（月/日根据场景）下可用性≥99.95%、响应延迟稳定在200ms以内，并支持平滑流量分配与灰度发布。
2. 假设：前端用户主要来自台湾；后端部署在多可用区与边缘CDN节点；可接入GeoDNS与第三方CDN。
3. 输出：提供可复制的步骤（DNS→CDN→LB→服务→监控→回滚）。

2. 架构设计总览（实操要点）

2. 组件：边缘CDN（静态加速）、GeoDNS（按地域分配）、互联网LB（HAProxy/Nginx/LVS）、应用池（多实例）、Redis/DB（主从或读写分离）、监控链路。
步骤：先部署CDN与GeoDNS，再部署LB组并做健康检查，最后接入监控与自动扩缩容。
注意点：把静态资源尽量放CDN，减少后端压力。

3. DNS 与 CDN 策略（可操作步骤）

3. 选择：使用支持Geo/Weighted的DNS（如AWS Route53、NS1、DNSPod）。
配置步骤：在DNS里新增台湾节点记录（A/ALIAS）并配权重，例如主节点weight=90，备份节点weight=10；TTL设为60s便于切换。
健康检查：为每个记录启用HTTP(S)健康检查（间隔10s，失败3次下线）。将CDN的回源指向LB VIP或DNS名。

4. 负载均衡器配置（HAProxy 与 Nginx 实战）

4. HAProxy 示例：在haproxy.cfg里定义后端：balance leastconn; server app1 10.0.0.1:80 weight 100 check inter 2000 rise 2 fall 3。
步骤：1) 部署至少2台HAProxy做主动-被动或任意cast。2) 配置健康检查与日志。3) 使用cookie或src认证做会话粘性：cookie SERVERID insert indirect nocache。
Nginx upstream：upstream backend { least_conn; server 10.0.0.1:80 max_fails=3 fail_timeout=10s; keepalive 32; }，在location里proxy_pass并设置proxy_cache和proxy_cache_bypass。

5. 流量分配与灰度发布（具体操作流程）

5. 场景：要把5%流量导向新版本。方法A（DNS权重）：在GeoDNS将台湾记录拆分为两个记录，设置权重5/95并监控健康。
方法B（LB权重/路由）：在HAProxy新增backend v2，给server行设置低weight或使用use_backend条件：acl canary rand(100) lt 5 use_backend v2。
实施步骤：1) 在低流量时间段先推5%，监控CPU/RT/错误率；2) 观察48小时无异常后按10%、25%、50%、100%递增；3) 若异常立即回滚：在HAProxy切掉v2或调整DNS回退权重。

6. 监控、报警与自动扩缩容（落地步骤）

6. 指标：QPS、95/99百分位延迟、5xx比率、CPU、内存、TCP连接数、后端队列长度。
部署：Prometheus + node_exporter + blackbox_exporter + Grafana；对接Alertmanager发送短信/Slack。示例报警：avg_over_time(http_request_duration_seconds{job="app"}[5m]) > 0.5 for 3m触发。
自动扩缩容：K8s环境使用HPA（基于CPU或自定义指标），非K8s可编写Scaler脚本（接收Prometheus告警，通过云API/Ansible扩容，再修改LB后端），并在扩缩容完成后做健康探测与流量回流。

7. 运维流程、测试与回滚（操作清单）

7. 上线流程：1) 在预发布环境做压测（压到目标PV的10%-20%），收集基线；2) 灰度按步骤5执行；3) 每步监控关键指标并记录；4) 回滚方法：修改GeoDNS权重或在LB中下线异常节点并reload。
测试命令示例：使用wrk压测：wrk -t12 -c400 -d60s http://canary.example.com/。
回滚命令示例：haproxy通过PUT /-sf 实现无缝重载，或在Route53减少权重。

8. 常见故障与快速排查（问答 Q1）

8. Q: 台湾站群在20m场景下若出现延迟飙升，首要排查哪些点？
A: 先看CDN命中率与回源QPS，若回源猛增排查后端；查看LB的连接数和错误率，查看后端Pod/VM的CPU、GC、数据库慢查询与Redis命中；快速措施：提高CDN缓存、临时扩容后端、把流量回流到健康节点。

9. 会话粘性与缓存策略（问答 Q2）

9. Q: 会话粘性会影响流量分配和扩缩容，如何兼顾？
A: 优先做无状态设计，把会话信息放Redis或JWT；若必须粘性，使用LB层cookie粘性并确保session存储可复制（Redis哨兵/集群）；扩缩容时配合会话迁移策略，扩容前先同步缓存热数据，缩容时优雅移除实例。

10. 部署验证与长期优化（问答 Q3）

10. Q: 部署完成后如何验证并长期优化负载分配？
A: 验证：执行端到端压测、灰度流量比对不同版本的错误率与延迟；长期优化：定期分析Prometheus历史数据调整权重和缓存策略，优化慢查询、压缩静态资源并调整CDN规则；设置SLA回顾和容量规划周期（每月/每季度）。

来源：台湾站群20m场景下的负载均衡与流量分配最佳实践