Spring Cloud Gateway 必须用 Nacos 吗？3 种服务发现模式 + 配置示例

nacos-discovery 只是 Spring Cloud Gateway 集成「服务发现」的一种方案（适配 Nacos 注册中心），而 Gateway 的核心功能（路由转发、过滤、限流等）完全可以脱离服务发现独立工作。是否需要使用 nacos-discovery，取决于你的微服务架构是否采用「服务注册与发现」模式。

一、先明确两个核心概念

1. Spring Cloud Gateway：网关的核心职责是「请求路由转发、过滤增强」，它的路由目标（uri）有两种配置方式：
   • 「固定地址」：直接写死下游服务的 IP + 端口（如 http://192.168.31.70:8010）；
   • 「服务名」：通过服务名（如 lb://order-service）动态获取下游服务的 IP + 端口（需依赖服务发现组件）。
2. nacos-discovery：是 Spring Cloud 生态中对接 Nacos 注册中心的「服务发现客户端」，作用是让 Gateway 能从 Nacos 拉取服务实例列表，实现「基于服务名的动态路由」和负载均衡。

二、Gateway 支持的 3 种路由模式（是否用 nacos-discovery 看模式）

模式 1：无服务发现（无需任何注册中心，最基础）

直接配置下游服务的「固定 IP + 端口」，无需依赖 Nacos/Eureka/Consul 等任何注册中心，Gateway 仅做简单的路径转发。

适用场景：

• 下游服务是单体应用（非微服务）；
• 微服务规模极小，无需动态扩容缩容（如仅 1 个实例）；
• 测试环境（快速验证网关功能）。

配置示例（无需引入 nacos-discovery 依赖）：

spring:
  cloud:
    gateway:
      routes:
        - id: order-service-route
          uri: http://192.168.31.70:8010  # 直接写死订单服务的IP+端口
          predicates:
            - Path=/order/**
          filters:
            - StripPrefix=1
        - id: stock-service-route
          uri: http://192.168.31.71:8020  # 固定库存服务地址
          predicates:
            - Path=/stock/**
          filters:
            - StripPrefix=1

优缺点：

• 优点：配置简单、无需额外依赖注册中心；
• 缺点：下游服务扩容 / 地址变更时，必须手动修改网关路由配置（不适合生产微服务）。

模式 2：基于 Nacos 服务发现（用 nacos-discovery）

引入 spring-cloud-starter-alibaba-nacos-discovery 依赖，Gateway 通过服务名从 Nacos 拉取实例列表，实现动态路由和负载均衡（生产微服务最常用）。

适用场景：

• 微服务架构（服务数量多、需动态扩容缩容）；
• 依赖 Nacos 作为注册中心（统一管理服务实例）；
• 需实现负载均衡、故障自动切换（无需手动维护实例地址）。

配置示例（需引入 nacos-discovery 依赖）：

spring:
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848  # Nacos 注册中心地址
    gateway:
      routes:
        - id: order-service-route
          uri: lb://order-service  # lb=负载均衡，order-service是Nacos中的服务名
          predicates:
            - Path=/order/**
          filters:
            - StripPrefix=1

核心依赖（Maven）：

<!-- Gateway 核心依赖 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<!-- Nacos 服务发现依赖 -->
<dependency>
    <groupId>***.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

模式 3：基于其他服务发现（不用 nacos-discovery，用替代方案）

除了 Nacos，Spring Cloud Gateway 还支持对接其他主流注册中心，此时无需 nacos-discovery，而是引入对应注册中心的客户端依赖：

示例：对接 Eureka 服务发现（无需 nacos-discovery）

1. 引入 Eureka 客户端依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-***flix-eureka-client</artifactId>
</dependency>

1. 配置 Eureka 地址和路由：

spring:
  cloud:
    gateway:
      routes:
        - id: order-service-route
          uri: lb://order-service  # 服务名与Eureka中注册的一致
          predicates:
            - Path=/order/**
          filters:
            - StripPrefix=1
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:8761/eureka/  # Eureka注册中心地址

三、关键总结：什么时候需要用 nacos-discovery？

只有满足以下两个条件时，才需要引入 nacos-discovery：

1. 你的微服务架构采用 Nacos 作为注册中心（服务实例注册到 Nacos）；
2. Gateway 需通过 服务名（如 lb://order-service） 动态路由，而非固定 IP + 端口。

四、常见误区澄清

1. 「Gateway 必须依赖服务发现」→ 错误：基础路由转发无需服务发现，直接配置固定 IP 即可；
2. 「服务发现必须用 Nacos」→ 错误：支持 Eureka/Consul 等多种注册中心，nacos-discovery 只是其中一种实现；
3. 「不用 nacos-discovery 就不能用负载均衡」→ 错误：若用固定 IP 模式，可手动配置多个实例实现简单负载均衡（如 uri: lb://order-service 改为 uri: http://192.168.31.70:8010,http://192.168.31.71:8010，但需手动维护实例列表，不如服务发现灵活）。

五、生产环境选择建议

• 若为 微服务架构：优先使用「服务发现模式」（推荐 Nacos/Eureka），引入对应依赖（如 nacos-discovery），适配动态扩容和高可用；
• 若为 单体应用 / 小规模部署：可直接用「固定 IP 模式」，无需服务发现，简化架构；
• 若已用其他注册中心（如 Eureka/Consul）：无需切换到 Nacos，Gateway 可直接对接，无需 nacos-discovery。

总之，nacos-discovery 是 Gateway 对接 Nacos 服务发现的「可选依赖」，而非必选依赖，核心看你的架构设计和注册中心选型。