要实现99.999%年可用率的网关，需调度策略、高可用架构、健康治理与动态反馈四层协同：轮询保障公平，权重适配容量，动态权重轮询（基于RT、错误率实时调权）应对劣化；网关集群跨可用区部署，VIP秒级切换；健康探测自动剔除与修复；Trie树路由+本地缓存+地理路由+响应缓存协同加速。
要实现年可用率 99.999%（即“五个九”，全年宕机时间 ≤ 5.26 分钟）的网关，单靠轮询或权重策略本身远远不够——它必须是调度策略、高可用架构、健康治理与动态反馈四层能力协同的结果。轮询与权重不是二选一，而是分层配合：轮询保障基础公平性，权重实现容量适配，混合调度则用于应对真实业务中性能差异、故障波动和流量突变。
核心调度层：轮询+动态权重双模融合
静态加权轮询（WRR）在节点性能稳定时有效，但无法应对 RT 上升、错误率飙升等实时劣化。真正支撑 99.999% 的是带健康反馈的动态权重轮询：
- 每个后端节点维护三项运行时指标：当前活跃连接数、最近 30 秒平均响应时间（RT）、错误率（5xx/超时）
- 每 5 秒基于公式重算权重：weight = base_weight × (1 − RT_factor) × (1 − error_factor)，其中 RT_factor 和 error_factor 设有硬上限（如 RT 超过 800ms 或错误率＞5%，权重直接归零）
- 轮询队列仅包含权重 > 0 的健康节点；权重为 0 的节点自动剔除，不参与任何调度，直到连续 3 次健康检查通过才恢复初始权重的 30%
- 示例：service-a 初始权重 100，RT 升至 1200ms → RT_factor=0.6 → 权重临时降为 40；若再出现 2 次超时，权重归零并触发告警
高可用网关集群：无单点、秒级切换
网关自身必须消除所有单点风险，否则再优的调度也无意义：
- 至少部署 3 个网关实例，跨可用区（如华东1/华东2/华北1），全部注册到服务发现中心（Nacos/Consul）
- 前端用 LVS + Keepalived 提供 VIP，或直接使用云厂商的 ALB/CLB，避免 Nginx 单点；VIP 故障检测间隔 ≤ 1s，切换耗时
- 网关实例间不共享连接状态，但通过 Redis Cluster 同步熔断状态、限流计数、路由灰度规则等关键元数据，TTL 设置为 10s 防止脑裂
- 所有 HTTP 请求启用 HTTP/2 多路复用 + 连接池复用（最大空闲连接 200，keepalive 60s），减少建连开销与 TIME_WAIT 压力
健康探测与自动修复闭环
传统 ping 或 HTTP GET /health 不足以反映真实服务能力，需多维探活：
- 主动探测：每 2 秒向后端发送轻量 probe 请求（HEAD /probe?ts=${unixtime}），校验响应码、耗时（>1s 视为异常）、TCP 握手延迟
- 被动探测：网关实时统计每个 upstream 的 5xx 率、超时率、连接拒绝率；任一指标连续 5 个周期越界，立即标记为“亚健康”，权重减半
- 自动修复：当节点被剔除后，启动后台任务每 10 秒发起一次试探请求；连续 3 次成功且 RT 回落至阈值内，平滑恢复权重（每次+20%，避免雪崩）
- 配置示例（Spring Cloud Gateway）：spring.cloud.gateway.routes[0].filters[0]=StripPrefix=1,Retry=3,RequestSize=1MB，启用内置重试与请求体校验
路由与缓存协同加速
调度决策本身不能成为瓶颈，毫秒级路由匹配是底线：
- 路径匹配采用 Trie 树结构预编译，支持前缀、正则、精确三类规则；某电商实测 10 万条路由下查找稳定在 0.18ms
- 路由规则全量缓存在本地 Caffeine Cache 中，TTL 30s + expireAfterWrite 60s 双机制，避免配置中心抖动引发全量刷新
- 地理路由与权重叠加：CN_SHANGHAI 流量优先打到华东集群，该集群内再按动态权重分发；Trie 节点附加 region 标签，查表时一并过滤
- 对 /api/user/profile 等高频读接口，网关层开启响应缓存（Cache-Control: public, max-age=60），命中率超 70% 时可降低后端 30% QPS
