Spring Cloud Gateway接入Nacos：动态路由与服务发现实践指南

网关接入 Nacos这句话我最近几乎每天都在碰。手里这套微服务的上游服务越来越多如果网关路由还写死成 IP 加端口前端一个接口切换、后端一次扩容都要去改配置重启来回折腾真的会让人崩溃。把 Spring Cloud Gateway 接入 Nacos 之后服务发现、动态路由、配置统一管理终于拧到了一起这也是我下定决心把整套接入过程整理出来的原因。这篇内容适合正在做微服务网关、或者想把现有网关从静态路由改成动态路由的开发者不管是只差一个 demo还是已经在排查线上问题都能从里面找到有用的东西。1. 想清楚再动手网关接 Nacos 到底解决什么问题1.1 网关在微服务链路里的角色网关在微服务里的角色我习惯用一个小区的门禁系统来类比。所有请求先进网关再由网关决定放行到哪个后端服务。除了路由网关通常还承担鉴权、限流、跨域处理、请求头改写这些事情。也就是说网关是所有流量的入口它对路由规则的灵活性要求非常高。有的项目一开始服务就几个路由配置简单网关的存在感并不强。等后来服务拆分多了每个服务还有多套环境、多个副本路由规则如果还是靠人肉维护迟早要出问题。所以网关接入注册中心本质上是要把“服务列表”这个最基础的信息从配置里解放出来让网关自己去发现。Spring Cloud Gateway 是响应式网关底层跑在 WebFlux 上和传统的 Spring MVC 不是一套东西。它内置了 RouteDefinition、Predicate、Filter 这些概念配合 Nacos 这种注册配置中心能组合出非常灵活的动态路由体系。这也是为什么很多微服务项目最终都走向这条路网关不关心后端服务具体部署在哪里只关心服务名和路由规则。1.2 不接注册中心时的痛点不接注册中心的时候网关路由最常见的写法是直接把 URI 写死spring: cloud: gateway: routes: - id: order-service uri: http://192.168.1.10:8081 predicates: - Path/api/order/**这种配置在最开始能跑但维护起来很痛苦。服务扩了一个实例要往网关配置里加一行某台机器要下线又要去删一行。如果后端服务做了多副本部署网关前面还得再挂一层负载均衡否则单点压力全部暴露出来。更麻烦的是服务重命名、迁移到新环境、切换机房这些操作全部要跟着改网关配置。配置一多谁改过、什么时候改的、为什么改完全说不清楚。遇到线上故障要回滚先得把配置翻出来对比半天。静态配置带来的不是安全问题而是效率问题尤其是在服务上下线频繁的阶段每次操作都像在雷区里走。另外静态 URI 无法自然支持按权重、按版本、按区域做流量控制。就算强行做也只能写在网关的 LB 规则里后端实例的变化根本感知不到。微服务的好处是弹性伸缩如果网关不跟着弹性起来整个链路就缺了最重要的一环。1.3 接了 Nacos 以后的变化接入 Nacos 之后最直观的变化就是路由 URI 可以写成服务名uri: lb://order-service这里的lb://告诉网关不要直接访问这个地址而是通过负载均衡组件去注册中心找名为order-service的服务实例。后端服务上线、下线、扩容网关都不需要改配置Nacos 会基于心跳机制把健康状态同步过来。我整理了一个简单的对比表能力静态路由接入 Nacos后端实例变更改配置重启自动发现多副本负载均衡需要额外搭建 LB网关内置支持按环境隔离靠不同配置文件名namespace 天然隔离路由规则动态调整基本靠重启配置中心推送实例健康检查不关心Nacos 可控当然接入 Nacos 不是说所有问题都自动消失了路由匹配规则、配置刷新、服务异常下线这些细节还是要自己盯。但至少在“服务发现”这件事上网关终于不再是一个只知道转发流量的死板盒子了。2. 动手前的方案选型版本、接入方式与基础设施2.1 版本兼容这里最容易翻车Spring Cloud Gateway、Spring Cloud Alibaba、Nacos 这三者的版本必须匹配这是我在多个项目里反复踩过的最大的坑。版本不匹配导致的症状很诡异常见的是启动时报ClassNotFoundException、NoSuchMethodError或者配置文件读不到可能表面上能启动实际服务发现完全无效。我这边常用的一个稳定组合是Spring BootSpring CloudSpring Cloud AlibabaNacos Server2.4.x2020.0.x2021.0.1.01.4.x / 2.x2.6.x2021.0.x2021.0.5.02.2.x3.0.x2022.0.x2022.0.0.02.3.x这里我不建议照搬一个版本号就结束因为 Spring Cloud Alibaba 官方维护着版本说明里面会列出每个 Alibaba 版本对应的是哪个 Spring Cloud 和 Spring Boot 版本。动手之前先去确认这个映射关系能省掉后面所有奇奇怪怪的兼容问题。还有一个很隐蔽的点Spring Cloud 2020 版本之后默认不再启用 bootstrap 上下文。以前很多教程会把 Nacos 相关的配置放在bootstrap.yml里新版本如果你还按照老写法配置很可能不加载。这个我在后面实操部分会专门讲。版本验证也有简单方法。引入依赖之后可以直接用 Maven 查看实际依赖树mvn dependency:tree -Dincludescom.alibaba.cloud:* -Dincludesorg.springframework.cloud:*看输出的版本号和 BOM 是否一致如果有多个相同包的不同版本就要检查是不是 dependencyManagement 没有生效。2.2 两种接入方式靠配置还是靠代码网关接入 Nacos从实现路线上看主要分成两种。第一种是纯配置方式。网关本身作为 Nacos 的客户端注册进去然后路由规则写在application.yml里或者放到 Nacos Config 里管理。路由 URI 用lb://服务名的形式网关通过服务发现拿到真实实例。这种方式代码量最少配置清晰适合大多数普通项目。第二种是代码接管方式。通过实现 Spring Cloud Gateway 的RouteDefinitionRepository接口把路由定义的来源从默认的配置文件改成 Nacos 配置中心。这样做的好处是路由规则完全动态化每次变更都由 Nacos 推送网关收到消息后主动刷新路由不需要依赖 Spring 配置刷新机制的“顺带”行为。两种方式并不互斥。实际项目里我通常先用纯配置方式把链路跑通等确定需要频繁调整路由了再把核心路由收敛到自定义仓库里。如果一上来就把代码写复杂前期排查问题会非常难受。2.3 要准备哪些东西在动手之前至少要把这几样东西准备好。Nacos Server 要能访问本地开发可以直接用单机模式启动。官方包下载后在conf里改一下配置然后跑startup.sh -m standalone或者 Windows 下的启动脚本即可。如果你是第一次用建议先用默认用户名密码登录控制台看几眼确认服务已经起来。要有一个可以作为下游测试的服务。随便一个 Spring Boot 应用只要它能注册到 Nacos 就行。我习惯造一个叫order-service的测试服务接口路径用/api/order/list这样网关路由规则也能一起验证。网关工程本身需要引入 Nacos discovery、Nacos config、Gateway 和 LoadBalancer 的依赖。很多新手会漏掉 LoadBalancer导致lb://这种 URI 无法解析。Gateway 默认使用 Spring Cloud LoadBalancer需要显式依赖。还有一个容易忽略的点网关是响应式应用启动时要保证spring.main.web-application-type是 reactive 而不是 servlet。如果你不小心把 Spring MVC 的spring-boot-starter-web引入了网关会启动失败因为 Gateway 和 MVC 的 web 类型冲突。3. 核心配置细节Nacos 数据模型、路由与刷新机制3.1 Nacos 数据模型namespace、group、dataIdNacos 的配置管理和服务发现都围绕三个概念namespace、group、dataId。namespace 通常用来做环境隔离。同一个 Nacos 集群里可以建dev、test、prod几个命名空间每个命名空间里的服务和配置互不可见。网关接入 Nacos 时如果下游服务注册在dev网关却配了prod控制台里能看到服务但网关就是找不到这种问题很难一眼定位。group 是第二级隔离。默认是DEFAULT_GROUP也可以自定义。一般情况下不用动它但如果你有多套环境共用 namespacegroup 可以帮助进一步区分。dataId 是配置中心里最核心的定位信息。默认格式是应用名前缀 文件后缀比如gateway-server.yaml。Nacos Config 会按照${spring.application.name}.${file-extension}去找配置。你可以手动在控制台创建这个 dataId也可以把配置放在本地根据环境用不同配置文件区分。在实际规划时我建议按环境把 namespace 隔离好然后用同一个 group 管理所有网关配置。服务发现的 namespace 和配置中心的 namespace 最好保持一致否则同一个服务在控制台看着正常网关却始终报错。3.2 网关本地配置怎么写网关的application.yml最核心的内容是应用名、Nacos 地址和服务发现开关server: port: 8080 spring: application: name: gateway-server cloud: nacos: discovery: server-addr: 127.0.0.1:8848 namespace: dev group: DEFAULT_GROUP这个配置里的server-addr是 Nacos 的地址本地可以是127.0.0.1:8848多环境建议用${NACOS_ADDR}这种占位符。namespace要和你下游服务保持一致不然网关注册过去了却发现在另一个命名空间找服务。注意这里只写了 discovery 配置还没有写 config 配置。如果把 Nacos Config 也引进来需要单独加config节点指定文件后缀、namespace、group。很多时候服务发现正常、路由不生效问题就出在 config 没配好。我习惯把本地application.yml保持得尽量简单只放不能集中管理的东西比如端口、本地临时开关。路由规则和更通用的公共配置尽量放到 Nacos Config 里避免本地和远端同时维护同一份配置会特别容易产生覆盖混乱。3.3 路由规则怎么写路由规则的表达主要靠 predicate 和 filter。predicate 是匹配条件相当于“什么请求会走这条路由”。最常见的Pathpredicatepredicates: - Path/api/order/**这个意思是只要请求路径以/api/order/开头就匹配这条路由。注意/**和/*不一样前者匹配多级路径后者只匹配一级路径。filter 是对请求或响应做处理。最常用的是StripPrefix它的作用是把路径前缀去掉一部分再转发给下游filters: - StripPrefix2假设客户端请求地址是/api/order/listStripPrefix2会把前两段/api/order去掉下游服务收到的实际路径就是/list。如果下游服务本身也有/order这个 context path那你可以把 StripPrefix 改成1让下游收到/order/list。我实际项目里的一条完整路由长这样spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path/api/order/** filters: - StripPrefix2这里的id是路由的唯一标识后面排查问题会用到。uri用的是lb://order-service这是接入 Nacos 后最核心的写法网关先去注册中心找到order-service的所有实例再通过负载均衡选一个出来转发。3.4 要不要开 discovery locatorNacos 接入后有一个开关很多人会顺手打开spring: cloud: gateway: discovery: locator: enabled: true lower-case-service-id: true开了这个开关网关会自动为所有注册到 Nacos 的服务生成路由规则比如访问/order-service/**就会转发给order-service。这在开发和联调阶段非常方便不需要为每个服务手写路由。但我不建议生产环境长期依赖它。自动生成的路由没有精细的 predicate 和 filter 控制路径规则是靠服务名拼接的一旦服务命名和对外 URL 不一致就会很混乱。更关键的是自动路由会让所有服务都暴露在网关入口之下这跟网关作为统一鉴权入口的目标是冲突的。我通常的做法是开发环境打开 locator生产环境关闭只保留显式声明的路由。这样既能在本地快速调试又不至于把网关变成一个“全裸转发器”。3.5 动态刷新机制是怎么回事接入 Nacos 之后大家最关心的一个问题是路由配置改了网关能不能不重启就生效这个问题的标准回答是分情况。Nacos Config 配置变更后客户端会通过长轮询感知到变化Spring 上下文会触发配置刷新事件理论上路由配置可以自动重载。但不同版本的 Spring Cloud Gateway 和 Spring Cloud Alibaba 对非RefreshScope的ConfigurationProperties处理方式不完全一样有些版本会刷新有些版本需要额外处理。所以如果你对动态路由有强依赖我更推荐用自定义RouteDefinitionRepository来接管路由定义把“配置变了”和“路由刷新”这两个动作显式绑定起来。这样不管 Spring 内部怎么变只要 Nacos 推送了新配置网关就一定会重新加载路由。这个方案我在第四章会有完整代码。4. 实操从零把网关工程接入 Nacos4.1 建工程、引依赖第一步创建一个普通的 Spring Boot 工程然后引入 Gateway、Nacos discovery、Nacos config 和 LoadBalancer 依赖。我这里用 Maven 示例。dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-gateway/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-loadbalancer/artifactId /dependency版本号不用一个个写死前提是你已经在 dependencyManagement 里引入了 Spring Cloud BOM 和 Spring Cloud Alibaba BOM。如果你用的是spring-boot-starter-parent还需要保证 BOM 的版本匹配。这里有一个容易踩的坑Gateway 是 WebFlux 的不要在网关工程里引入spring-boot-starter-web。一旦引了工程会启动报错因为你同时配了spring.mvc和spring.webflux。网关的 web 类型就是 reactive这是它的天然属性。4.2 区分 bootstrap 和 spring.config.import新版本 Spring Cloud 默认会把 bootstrap 关掉。很多老教程里让你把 Nacos config 写到bootstrap.yml在新版本里可能不生效。有两种解决办法。第一种是显式引入spring-cloud-starter-bootstrap让bootstrap.yml重新生效。适合老项目升级改动最小。第二种是新推荐的做法在application.yml里使用spring.config.import把 Nacos 配置引入spring: config: import: optional:nacos:gateway-server.yamloptional:前缀的意思是这个配置源是可选的如果 Nacos 里没有它应用也能启动。如果你希望应用必须能拉到配置才能启动可以去掉optional:。我自己的习惯是新项目一律用spring.config.import因为它是更标准的 Spring Boot 方式。老项目如果有一套稳定运行的 bootstrap 链路也就没太大必要强行改。4.3 在 Nacos 配置中心维护路由在 Nacos 控制台里我创建了一个 dataId 为gateway-server.yaml、group 为DEFAULT_GROUP的配置格式选择 YAML。内容就是网关路由spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path/api/order/** filters: - StripPrefix2这里请留意一个坑不要在本地application.yml里也写同样的spring.cloud.gateway.routes。如果本地和 Nacos 里都有路由配置合并后优先级会变得很难预测你可能会发现改了 Nacos 里的配置网关还在执行本地那份。我把本地application.yml只保留应用名、端口、Nacos 地址这类基础信息。路由规则全部收口到 Nacos 配置中心这样网关的多副本实例拿到的路由就是一致的了。4.4 启动、注册、验证一条龙配置完成后先启动 Nacos Server再启动下游的order-service最后启动网关。启动完成后打开 Nacos 控制台在服务列表里能看到order-service和gateway-server两个服务状态都标记为健康。说明服务注册是通的。然后模拟一次网关转发curl -X GET http://localhost:8080/api/order/list如果一切正常应该会看到order-service返回的结果。如果返回 404大概率是路由没有匹配上如果返回 503基本可以确定是lb://order-service在注册中心里没找到实例。我还习惯在网关的启动日志里确认一行信息看它是否成功从 Nacos 拉到了配置。Spring Boot 启动时会打印配置来源如果日志里没有 Nacos config 相关的内容说明spring.config.import没生效先回去检查 dataId 和文件后缀。4.5 进阶做法用 RouteDefinitionRepository 接管动态路由如果你觉得靠 Nacos Config 自动刷新路由不够稳或者想完全掌控路由变更行为可以实现一个自定义的RouteDefinitionRepository。核心逻辑是监听 Nacos 配置路由配置一变化就重新加载并发布RefreshRoutesEvent。代码大概长这样Component public class NacosRouteDefinitionRepository implements RouteDefinitionRepository { private static final String DATA_ID gateway-routes.json; private static final String GROUP DEFAULT_GROUP; private final ConfigService configService; private final ObjectMapper objectMapper; private final ApplicationEventPublisher publisher; private volatile ListRouteDefinition routeDefinitions new ArrayList(); public NacosRouteDefinitionRepository(NacosConfigManager nacosConfigManager, ObjectMapper objectMapper, ApplicationEventPublisher publisher) throws NacosException { this.configService nacosConfigManager.getConfigService(); this.objectMapper objectMapper; this.publisher publisher; init(); } private void init() throws NacosException { String configInfo configService.getConfig(DATA_ID, GROUP, 5000); refreshRoutes(configInfo); configService.addListener(DATA_ID, GROUP, new Listener() { Override public Executor getExecutor() { return null; } Override public void receiveConfigInfo(String configInfo) { refreshRoutes(configInfo); } }); } private void refreshRoutes(String configInfo) { try { if (configInfo null || configInfo.trim().isEmpty()) { routeDefinitions new ArrayList(); } else { routeDefinitions objectMapper.readValue( configInfo, objectMapper.getTypeFactory().constructCollectionType(List.class, RouteDefinition.class)); } publisher.publishEvent(new RefreshRoutesEvent(this)); } catch (Exception e) { throw new RuntimeException(解析网关路由配置失败, e); } } Override public FluxRouteDefinition getRouteDefinitions() { return Flux.fromIterable(routeDefinitions); } Override public MonoVoid save(MonoRouteDefinition route) { return Mono.error(new UnsupportedOperationException(请通过 Nacos 配置中心修改路由)); } Override public MonoVoid delete(MonoString routeId) { return Mono.error(new UnsupportedOperationException(请通过 Nacos 配置中心修改路由)); } }Nacos 里存的配置是一个 JSON 数组每个元素就是一个路由定义[ { id: order-service, uri: lb://order-service, predicates: [ { name: Path, args: { pattern: /api/order/** } } ], filters: [ { name: StripPrefix, args: { parts: 2 } } ] } ]这样做的优点是把路由刷新机制握在自己手里Nacos 推什么网关就加载什么中间没有 Spring 配置刷新机制的灰色地带。缺点是自己维护解析逻辑配置格式也要约定统一。我认为值得尤其是路由规则不仅多、还经常调整的项目。5. 踩坑记录五个最常遇到的问题5.1 路由一直 404到底谁的问题路由 404 是接入网关之后最常遇到的现象但大部分时候不是 Nacos 的问题而是路径匹配规则的问题。我遇到最典型的例子是客户端请求/api/order路由里写的是/api/order/**结果匹配不上。Path predicate 对末级路径非常敏感你要么把规则写成/api/order/**并让客户端统一带一个斜杠要么再补一条/api/order路由。如果不确定实际匹配结果把网关日志调到 TRACE 级别可以看到每个请求匹配了哪条 predicate、最终命中了哪条路由这比自己瞎猜靠谱得多。也有一种情况是上游服务实际路径和你预期的不一致。比如下游接口本身就是/order/list但网关StripPrefix2把/api/order全去掉了只剩/list那下游自然 404。遇到这种情况先直接 curl 下游服务确定真实路径再反推网关该用StripPrefix1还是2。5.2 lb:// 报错找不到服务实例lb://order-service没用报错找不到实例这也是高频问题。第一步先看 Nacos 控制台order-service是否真的已经注册。如果没有注册去下游服务里检查 Nacos 地址和 namespace 配置。第二步看网关的 namespace 是不是和下游一样控制台能查到不代表网关能查到如果 namespace 配错对网关来说那个服务就是不存在的。还有一个小坑是服务名大小写。Nacos 服务名默认不区分大小写存储但 Spring Cloud LoadBalancer 在匹配服务名时是精确匹配的。lb://ORDER-SERVICE和lb://order-service对你来说是同一个名字对注册中心来说可能就变成两个服务。统一用全小写命名最稳妥。5.3 配置中心的路由改了没反应改完 Nacos 里的路由等了半天没生效这个现象我也见过不少。优先检查是不是本地配置把 Nacos 里的配置覆盖了。如果你在本地application.yml里也写了spring.cloud.gateway.routes而本地配置文件优先级比 Nacos 的高那你改 Nacos 当然没用。解决方法是把路由从本地彻底删掉统一收口到配置中心。还有一种情况是spring.config.import没有生效。表现为应用启动时完全没拉远程配置改什么都不动。检查 dataId 和应用名是否匹配文件后缀是yaml还是properties这俩不一致会导致读取不到。如果你用的自定义RouteDefinitionRepository记得在控制台确认 Nacos 监听有没有加成功。监听失败往往是网络不通或者 Nacos 服务端不正常但异常往往不会打断应用启动所以很容易被忽略。5.4 实例下线了网关还在转发后端服务都停掉了Nacos 控制台里也显示下线了网关还是会偶尔把请求转发过去然后报连接失败。这种现象其实不是网关的锅是注册中心的心跳机制和本地负载均衡缓存共同导致的。Nacos 有健康检查周期默认情况下实例状态变化不会秒级同步到所有客户端。网关使用了 Spring Cloud LoadBalancer 之后还有一个缓存默认 TTL 大约 35 秒。这两个机制加在一起就会出现短暂的“我已经下线了但网关不知道”的情况。如果你对实时性要求高可以把 LoadBalancer 的缓存关掉spring: cloud: loadbalancer: cache: enabled: false但我不建议所有环境都关频繁关闭缓存会加大注册中心的压力。更合理的做法是接受几十秒的容忍窗口同时在网关层面配置超时和重试避免单个实例异常导致整个请求长期挂起。5.5 版本兼容和循环依赖版本兼容问题我在 2.1 里已经强调过这里再补充一个具体现象Spring Boot 3 和 Spring Boot 2 的依赖包名称变化很大尤其是javax到jakarta的切换。如果你把一个 Spring Boot 2 的依赖直接塞进 Spring Boot 3 的工程里启动时多半会报NoClassDefFoundError然后你会以为是 Nacos 的问题其实只是依赖冲突。遇到循环依赖一般不是代码写错而是自动配置类互相引用的版本不匹配。我的排查顺序是先看完整异常堆栈再查mvn dependency:tree里有没有不同版本的同一个包最后对照 Spring Cloud Alibaba 的版本说明。大部分兼容性问题都可以在这三步里解决。6. 几个让网关更好用的小技巧6.1 加一个全局过滤器统一处理请求头网关接入 Nacos 解决了路由动态化的问题但网关本身还要承担很多通用逻辑。我建议至少加一个全局过滤器用来处理统一的请求头透传或者简单鉴权。一个简单的示范Component public class AuthFilter implements GlobalFilter, Ordered { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String token exchange.getRequest().getHeaders().getFirst(Authorization); if (token null || token.isBlank()) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } return chain.filter(exchange); } Override public int getOrder() { return -100; } }这里只是告诉大家 GlobalFilter 的写法真正的鉴权肯定不是判断空 Token 这么简单。getOrder()返回值越小过滤器执行得越早。我把登录校验放在-100就是为了让它先于绝大多数路由内部过滤器执行。还有一点网关里对请求体做修改会比较麻烦因为 WebFlux 的请求体是响应式流。如果只是透传 header、校验参数GlobalFilter 足够如果要改 body就要考虑用ModifyRequestBody这类过滤器复杂度会高不少。6.2 打开路由匹配日志排查路由问题最省力的手段是把网关的路由匹配日志打开logging: level: org.springframework.cloud.gateway: TRACE打开之后请求进来时日志会把每个 predicate 的匹配结果打印出来你一眼就能看到是哪条规则没匹配上。TRACE 级别日志量大生产环境尽量别长期开着只在排查问题时开几分钟用完就关。我还习惯在网关里加一个统一的访问日志 Filter记录请求路径、目标路由、下游服务名、响应耗时和状态码。这些数据在后端服务报错时非常有用能快速定位是网关没转发出去还是下游服务返回的异常。6.3 上线前按这个清单检查一遍我把自己实际用过的检查项整理出来每次网关发版前按这个清单过一遍检查项说明Nacos 地址确认当前环境变量指向了正确的环境namespace网关和下游服务必须一致dataId配置中心的 dataId 和应用名、格式要严格匹配路由规则本地和 Nacos 不要重复维护同一份路由下游服务状态Nacos 控制台里服务健康状态正常超时配置给网关配置合理的连接超时和响应超时多副本一致性多实例网关的配置来源必须相同这套检查清单看起来很基础但每次都能挡住不少低级问题。尤其是多实例部署的时候如果有一个实例配置文件没同步流量负载均衡过去就会出现“一半正常一半 404”的诡异现象。6.4 我对这套方案的一点体会网关接入 Nacos 的核心价值不在技术本身而在把“服务列表”和“路由规则”这两件事从静态配置里解放出来。但动态化不是越复杂越好。项目早期服务数量不多的时候静态路由反而最好排查也没有必要强行引入大量自定义代码。等真的出现服务上下线频繁、路由规则经常调整的情况再把配置收口到 Nacos并且把配置变更当成一次发布动作来管理线上出了问题才能快速回滚。我自己现在比较喜欢的一个做法是不在生产环境通过 Nacos 控制台直接乱改路由而是把配置变更走一次正式流程审批通过后再更新到配置中心。虽然多了一道操作但每次变更都有记录回滚有依据出问题时不会因为一条随手写的路由规则闹到整个链路不可用。最后再分享一个小技巧网关服务多副本部署时路由规则千万不要在某一台实例的本地配置里单独改。你们可以因为业务需要临时调某一台的日志级别但路由、鉴权这类全局配置必须保证所有实例一致。否则问题不会立刻暴露只会在某一次流量倾斜时突然冒出来到时候排查成本比现在多做十倍都不止。