API 网关如何实现动态路由？
简化版
动态路由指网关的路由规则不写死在配置文件里，而是能在运行时动态增删改、无需重启网关。两个层面：① 路由目标动态——结合服务发现（注册中心），网关按服务名路由（lb://order-service），后端实例扩缩容时网关自动感知最新实例，不用改配置；② 路由规则动态——把路由规则存到配置中心（Nacos）或数据库，网关监听变化，规则一改就实时刷新生效。Spring Cloud Gateway 通过 RouteDefinitionRepository 从外部数据源加载路由，配合配置中心监听实现动态路由。
详细版
静态路由的问题： 路由配在 application.yml 里，改路由（加个服务、改个规则）要改配置 + 重启网关，生产环境不灵活、有中断风险。
动态路由的两个层面：
| 层面 | 实现 | 效果 |
|---|---|---|
| 目标动态 | 集成注册中心，uri: lb://service-name | 后端实例变化自动感知，无需改路由 |
| 规则动态 | 路由规则存配置中心/DB，监听变化刷新 | 增删改路由规则实时生效、不重启 |
Spring Cloud Gateway 动态路由实现：
- 服务发现路由：开启
discovery.locator.enabled，或用lb://前缀，网关从注册中心动态获取实例。 - 规则动态化：自定义 RouteDefinitionRepository（如从 Nacos 读路由配置），监听配置中心变化 → 发布
RefreshRoutesEvent→ 网关刷新路由。
完整版教学
一、为什么需要动态路由
Spring Cloud Gateway 的路由默认写在配置文件（application.yml）里。这在生产环境有明显不便：
- 改路由要重启：想加一个新服务的路由、或调整一条路由规则，得改配置文件 → 重新部署/重启网关。而网关是流量入口，重启有中断风险、也很慢。
- 不够灵活：微服务环境下服务经常变动，静态配置跟不上。
动态路由解决这个问题：让路由能在运行时动态变更、实时生效、无需重启网关。这分两个层面——路由的目标（转发到哪个实例） 和 路由的规则本身（有哪些路由），都可以动态化。
二、层面一：路由目标动态（集成服务发现）
第一个层面：即使路由规则不变，转发的目标实例是动态的——因为后端服务的实例会扩缩容、上下线。
解决靠集成注册中心（服务发现）：
- 路由的目标 uri 写成
lb://order-service（lb= LoadBalance，负载均衡到名为 order-service 的服务），而不是写死的http://192.168.1.10:8080。 - 网关从注册中心动态获取
order-service当前的所有健康实例，转发时负载均衡选一个。 - 后端实例扩容、缩容、宕机时，网关自动感知注册中心的变化，路由到最新的实例——完全不用改网关配置。
还可以开启 spring.cloud.gateway.discovery.locator.enabled=true，让网关自动为注册中心里的每个服务生成默认路由（按服务名路径转发），连路由都不用手动配。
三、层面二：路由规则动态（配置中心/数据库）
第二个层面：路由规则本身（有哪些路由、每条路由的断言和过滤器）能动态增删改。
Spring Cloud Gateway 的路由规则由 RouteDefinition 表示，默认从配置文件加载。要动态化，就把路由规则存到外部数据源（配置中心 Nacos、数据库、Redis），并让网关监听变化：
- 实现自定义的 RouteDefinitionRepository，从外部数据源（如 Nacos 的某个配置）读取路由规则。
- 监听数据源变化：比如监听 Nacos 配置变更，一旦路由规则被修改。
- 变更后发布
RefreshRoutesEvent事件，触发网关重新加载路由——新路由规则实时生效，无需重启。
这样运维在配置中心/管理界面改路由规则，网关秒级刷新，动态增删改路由。
四、动态路由的完整实现思路
综合两个层面，一个完整的动态路由方案：
- 路由规则存 Nacos（或数据库）：路由规则以配置形式存在配置中心，可通过管理界面维护。
- 网关自定义 RouteDefinitionRepository：从 Nacos 加载路由规则。
- 监听 Nacos 配置变更：路由规则改了，Nacos 推送变更给网关。
- 发布 RefreshRoutesEvent：网关收到变更，发布刷新事件，重新加载路由到内存。
- 目标用
lb://+ 服务发现：路由目标是服务名，实例由注册中心动态提供。
这样路由规则（改配置中心实时生效）和路由目标（注册中心自动感知实例）都动态化了，网关无需为路由变更重启。
五、动态路由的价值
- 运维灵活：加服务、改路由、调整灰度规则，在管理界面点几下就生效，不用发版重启网关。
- 无中断：网关作为流量入口，避免频繁重启带来的抖动。
- 适应微服务动态性：服务实例频繁变化，动态路由 + 服务发现让网关始终指向正确的实例。
- 配合灰度、限流动态调整：路由规则里的灰度规则、限流参数也能动态改，实现运行时的流量精细调控。
六、常见误区与追问
这道题面试时最容易丢分的地方，是把「网关动态路由」答成一段泛泛的组件介绍。更稳的答法是先给结论，再沿着 统一流量入口链路 拆清楚流程，最后补上异常场景、数字边界和选型取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心定义 | 动态路由让网关无需重启即可新增、修改或下线路由规则 | 不要停在名词解释 |
| 流程机制 | 路由配置存储在配置中心或数据库 -> 网关启动加载路由 -> 监听路由变更 -> 刷新内存路由表 -> 新请求按新规则匹配 | 说明谁触发、谁存储、谁通知、谁兜底 |
| 工程取舍 | 新增 /api/coupon/** 到 coupon-service 的路由，理想情况下配置发布后秒级生效，不需要重启网关集群 | 网关适合收口横切能力，但不能把业务逻辑堆到网关，否则会形成新的复杂单体 |
网关动态路由 面试拆解：
1. 路由配置存储在配置中心或数据库
2. 网关启动加载路由
3. 监听路由变更
4. 刷新内存路由表
5. 新请求按新规则匹配记忆钩子：先拆路由、过滤器、鉴权、限流、熔断、灰度，再说明网关和业务服务的边界；回答时一定要落到题目中的「网关动态路由」，不要把相邻中间件的能力混着讲。
- 误区：动态路由就是每次请求查数据库。 生产一般变更时刷新内存路由表，请求路径走内存匹配。
- 误区：路由更新不需要校验。 错误路由会直接影响入口流量，必须校验目标服务、谓词和过滤器配置。
- 误区：删除路由可以立即无风险。 应确认无流量或先灰度下线，避免客户端仍在访问。
- 追问：动态路由配置放在哪里？ 可放配置中心、数据库或网关管理平台，并推送变更给网关实例。
- 追问：多台网关如何保持一致？ 通过配置版本、广播通知和定期拉取校准路由表。
- 追问：动态路由失败怎么兜底？ 保留上一版有效路由，发布失败不覆盖，并支持版本回滚。
七、加强记忆
动态路由 = 网关路由运行时可动态变更、无需重启（解决静态配置「改路由要重启、不灵活」的问题）。两个层面：① 路由目标动态——集成注册中心，目标写 lb://service-name，网关从注册中心自动感知实例变化、负载均衡转发，后端扩缩容不用改配置（可开 discovery.locator 自动生成路由）；② 路由规则动态——路由规则（RouteDefinition）存配置中心（Nacos）/数据库，自定义 RouteDefinitionRepository 加载，监听变化 → 发布 RefreshRoutesEvent → 网关刷新路由，规则改动实时生效。价值：运维灵活、无中断、适应微服务动态性、支持灰度/限流动态调整。口诀：目标用 lb:// 靠服务发现、规则存配置中心监听刷新、都不用重启网关。