第4章：网关路由与负载均衡原理
本章聚焦API网关核心机制：路由规则、服务发现、负载均衡算法与容错策略。面试时需从架构设计到具体实现完整阐述，并体现工程落地经验。
面试问答卡片
问题1：请描述API网关的路由规则是如何设计的？你会如何实现动态路由？
考察点：路由设计能力、动态路由实现细节、对网关配置管理的理解。
回答框架：
- 分层说明路由匹配顺序：精确路由 > 前缀路由 > 正则路由。
- 动态路由核心：基于路由表热加载（如Consul/etcd配置中心）或服务注册信息实时生成。
- 实现要点：监听配置变更 → 解析规则 → 更新内存路由树 → 新请求命中新规则。
示例回答：我设计路由规则时采用多级匹配：精确路径优先，其次前缀，最后正则。动态路由通过监听etcd中路由配置变化，使用Trie树在内存中重建路由表，保证O(k)时间复杂度。每次变更仅影响新增/删除的规则，存量请求不受影响。
可能追问：路由表过大时如何优化？路由冲突如何解决？如何做路由预热？
避坑提醒：不要只讲理论，必须提及具体实现（如Trie树、基数树）和配置中心选型（etcd/Nacos）。
问题2：网关层如何集成服务发现？与注册中心如何交互？
考察点：服务发现原理、注册中心选型、健康检查与缓存机制。
回答框架：
- 说明两种模式：客户端发现（网关直接拉取注册中心）和服务端发现（通过DNS/SLB）。
- 网关常见使用客户端模式：watch注册中心的服务列表变更，本地维护缓存。
- 健康检查：定期主动探测+被动心跳，剔除异常实例。
示例回答：我使用Consul作为注册中心，网关通过HTTP长轮询watch服务变更。本地缓存服务实例列表，并设置TTL。当实例变化时，异步更新负载均衡权重。同时网关每5秒对后端节点做TCP探测，连续失败3次则从本地缓存移除。
可能追问：注册中心宕机如何保证网关可用？缓存一致性和实时性如何平衡？
避坑提醒：不要忽略注册中心高可用问题（本地缓存+优雅降级），要主动提及。
问题3：请对比几种常见负载均衡算法的优缺点，网关场景下你倾向选择哪种？
考察点：负载均衡算法原理、场景适配能力、调优经验。
回答框架：
- 列举轮询、加权轮询、最小连接、一致性哈希、随机+权重。
- 对比：轮询简单但忽略负载；最小连接感知实时负载；一致性哈希适合粘性会话。
- 网关推荐：默认使用加权轮询（平滑加权轮询），若需会话保持则用一致性哈希。
示例回答：我通常选择平滑加权轮询（Nginx WRR），它解决了普通加权轮询的毛刺问题，且实现简单、性能高。对于需要会话保持的业务，我会配置一致性哈希，但注意节点变更时只影响1/n流量。
可能追问：如何实现自定义权重？权重动态调整怎么做？一致性哈希虚拟节点如何设置？
避坑提醒：不要照搬理论，要结合网关场景说明选择理由（如性能、无状态、运维简便）。
项目案例：统一API网关路由与负载均衡重构
| 项目名称 | 统一API网关路由与负载均衡重构 |
| 业务背景 | 原有网关基于Nginx静态配置路由，服务扩缩容需手动修改并重载，部署效率低；部分核心服务因负载不均导致雪崩。 |
| 规模指标 | 日请求量 5亿+；后端微服务 200+；网关集群 30节点；配置变更频率 每日100+次。 |
| 技术栈 | Spring Cloud Gateway + Nacos (注册中心/配置中心) + 平滑加权轮询 + 熔断(Hystrix/Resilience4j) |
| 核心难点 | 1. 动态路由变更无损；2. 注册中心宕机时网关不降级；3. 流量突增时负载不均导致部分节点过载。 |
| 面试高频追问 | 你如何保证路由更新的原子性？如何防止缓存击穿？负载均衡权重基于什么维度调整？ |
| 可迁移回答话术 | “我的方案核心是：配置中心监听+本地缓存 + 两级健康检查。每次变更生成全量路由版本号，网关采用双Buffer原子切换，保证更新期间请求不丢失。缓存方面设置了熔断保护，注册中心不可用时使用最后一次有效快照。” |
知识结构：负载均衡算法对比
| 算法 | 优点 | 缺点 | 网关场景推荐度 |
|---|---|---|---|
| 轮询 (Round Robin) | 实现简单，无状态 | 不考虑节点负载差异 | 低（基础可用） |
| 加权轮询 | 支持机器规格差异化 | 权重固定，无法动态调整 | 中（平滑加权轮询可接受） |
| 最小连接数 | 反应实时负载 | 需要维护连接数状态，增加开销 | 高（长链接场景推荐） |
| 一致性哈希 | 支持会话保持，节点增删影响小 | 哈希倾斜需虚拟节点 | 高（需会话保持时） |
| 随机+权重 | 分布均匀，性能高 | 极端情况下可能集中 | 中 |
面试加分：主动提及“自适应负载均衡”，结合CPU/内存/响应时间动态调整权重。