第3章 网关高可用与容灾设计
本章聚焦API网关在极端场景下的稳定性保障，核心考点包括集群部署策略、故障自动转移机制、跨节点数据一致性方案。以下为面试高频问答与真实项目案例模板。
面试问答卡片
Q1：请描述API网关集群的部署架构和故障转移设计。
考察点：架构设计能力、对分布式系统高可用原则的理解、容灾经验。
回答框架：
① 部署架构：多机房/多AZ + 负载均衡器（如Nginx/LVS）前置，网关节点无状态化。
② 故障检测：健康检查（HTTP探活/心跳）+ 自动摘除异常节点。
③ 转移机制：DNS切换 / VIP漂移 / 服务发现健康检查触发重新路由。
④ 数据一致性：共享配置中心（Nacos/Etcd）+ 本地缓存失效策略。
示例回答（80字）：
“采用多AZ部署，前端LVS做流量分发，网关节点无状态化。每个节点通过Nacos健康检查上报状态，异常时自动摘除。故障转移依赖DNS解析切换，同时配置中心推送最新路由表，确保切换后流量正确路由。”
可能追问：
- 如何避免节点摘除时连接中断？（优雅关闭/平滑下线）
- 跨AZ同步数据延迟如何处理？（最终一致性 + 本地降级）
避坑提醒：
- 避免只说“多副本部署”，要细化故障检测与自动触发机制。
- 不要忽略数据一致性，特别是动态路由、限流配置等。
Q2：网关集群中如何保证数据（如路由表、限流配置）的一致性？
考察点：分布式一致性方案选型、CAP权衡、缓存与配置理解。
回答框架：
① 配置管理：统一配置中心（Nacos/Etcd）+ Watch机制推送变更。
② 本地缓存：网关节点缓存配置 + 版本号比较，增量拉取。
③ 最终一致性：允许短暂不一致，但通过MQ或定期全量对齐。
④ 降级策略：配置中心不可用时，使用本地缓存快照继续服务。
示例回答（85字）：
“路由表等配置存于Nacos集群，网关节点通过长轮询监听变更，增量推送更新本地缓存。如Nacos故障，节点使用最后有效的本地缓存并打日志告警，同时提供API手动重载配置，保证极端情况继续服务。”
可能追问：
- 如果配置更新期间有大量请求，如何保证一致性？（版本号路由/RBAC校验）
- 如何做配置灰度发布？（分组发布 + 流量染色）
避坑提醒：
- 避免说“强一致性”，说明是最终一致性并给出可接受延迟范围。
- 不要忽略本地缓存持久化策略（如溢出到磁盘）。
Q3：网关故障转移时如何处理正在处理的请求（如长连接/WebSocket）？
考察点：有状态连接处理、优雅下线、无状态化改造思路。
回答框架：
① 无状态化：将应用层状态（如会话）外移到Redis/分布式缓存，网关自身无连接状态。
② 优雅关闭：节点收到摘除信号后，设置一个宽限期不再接受新连接，等待已有请求完成。
③ 重试机制：客户端侧配置重试，交换机遇到连接重置时自动重连其他节点。
④ WebSocket场景：使用网关透传 + 连接标识（如sessionId）映射到后端节点，靠心跳检测重建。
示例回答（90字）：
“首先推动网关无状态化，会话状态放Redis；摘除节点时先停止新连接，等待现有请求完成（最长30秒），超时强制断开。客户端配置重试策略，断线后自动尝试其他节点。WebSocket则通过心跳检测，失联后重新握手并携带原sessionId恢复上下文。”
可能追问：
- 如何实现“等待现有请求完成”的具体机制？（ConnectionLimit + 流量控制）
- 长连接迁移时的数据完整性如何保证？（应用层幂等）
避坑提醒：
- 不要说“直接关闭”，要体现优雅的Graceful Shutdown细节。
- WebSocket迁移是难点，需给出具体方案，否则容易被质疑。
项目案例模板：电商API网关高可用改造
项目名称：电商大促网关高可用改造
| 业务背景 | 618/双11大促期间，流量峰值10万QPS，要求可用性99.99%。原单机房部署存在单点风险，需跨AZ容灾。 |
| 规模指标 | 网关节点30台（3 AZ各10台），后端应用500+，动态路由条目1200条，配置变更1s内生效。 |
| 技术栈 | Kong（网关）+ Nacos（配置中心）+ Redis（缓存/会话）+ LVS（负载均衡）+ Etcd（服务发现） |
| 核心难点 | ① 跨AZ配置同步延迟导致路由不一致；② 健康检查误判引起雪崩；③ 长连接迁移时session丢失。 |
| 面试高频追问 | - Nacos与Etcd如何分工？ - 如何做AZ级故障演练？ - 配置灰度发布如何保障？ |
| 可迁移回答话术 | “在某电商大促项目中，我们通过多AZ部署 + Nacos配置中心 + Redis缓存，实现网关无状态化。健康检查采用三层探活（TCP+HTTP+gRPC），误杀率降至0.05%。长连接通过sessionId映射Redis，切换时由客户端重连恢复，数据零丢失。” |