实现微服务网关统一路由需三者协同：统一自定义bridge网络确保服务名通信；注册中心（如Nacos）实现服务自动发现与健康检查；网关启用discovery.locator动态映射路由，配合声明式配置、安全策略及可观测性增强。
要实现微服务网关到下游服务的统一路由，核心是让网关能动态识别、发现并正确转发请求到各后端服务，而不是硬编码 ip 或端口。这需要网络层、注册发现层和路由配置层三者协同。
统一网络基础：用自定义 bridge 网络打通服务可见性
所有服务（网关 + 微服务）必须接入同一个自定义 bridge 网络，才能通过服务名通信：
- 在 docker-compose.yml 中显式声明一个网络（如
micro-net），驱动设为bridge - 网关服务（如 Spring Cloud Gateway、Traefik 或 Kong）和每个业务服务（
user-service、order-service）都加入该网络 - 避免使用默认网络——它缺乏可读性和可控性；也不要用
host模式，会破坏容器隔离 - 验证方式：进入网关容器执行
ping user-service，应能通
服务自动注册与发现：让网关“知道”谁在线
网关不能靠写死地址列表，而要从注册中心实时拉取健康实例：
- 部署注册中心（如 Nacos、Consul 或 Eureka），并配置
healthcheck，确保只提供存活节点 - 各微服务启动时向注册中心注册自身（例如 Spring Boot 项目引入
spring-cloud-starter-alibaba-nacos-discovery） - 网关启用服务发现支持：Spring Cloud Gateway 配置
spring.cloud.gateway.discovery.locator.enabled=true；Traefik 启用对应 provider（如 consulCatalog） - 这样，
/user/**请求会自动转发到注册名为user-service的任意可用实例，无需手动维护路由条目
统一路由规则：声明式配置 + 动态映射
路由逻辑应集中管理、支持热更新，而非打包进镜像：
- 网关配置不固化在镜像中，改用
volumes挂载外部 YAML 或通过环境变量注入 - 启用自动路由映射：如开启
discovery.locator后，服务名user-service默认对应路径/user-service/**，可进一步用spring.cloud.gateway.discovery.locator.route-id-prefix去掉前缀，变成更友好的/user/** - 对特定路径做精细化控制（如
/api/payments→payment-service），单独定义Route并启用插件（JWT 验证、限流、重试） - Kong 用户可通过 Admin API 或 Konga 界面创建 Service/Route，上游设置为
http://user-service:8080（注意：用服务名，不是 localhost 或宿主机 IP）
安全与可观测性增强：路由不止于转发
统一路由不仅是路径匹配，还承载策略与追踪能力：
- 所有出网关的响应头自动注入
X-Request-ID和X-Response-Time，用于全链路日志关联 - 在网关层统一启用认证（如 key-auth）、限流（rate-limiting）、熔断（如 Sentinel 集成）
- 若下游协议不一致（如 OpenAI 格式 vs 文心一言），可在网关挂载协议转换插件或前置代理服务，对外暴露统一接口
- 数据库等敏感服务不接入公共网络，仅允许 backend 层服务访问，网关不直连 DB
