在微服务体系中,Nacos 主要承担"服务注册与发现、配置中心"的职能,Gateway (如 Spring Cloud Gateway)通常负责"路由转发、过滤、安全鉴权、灰度流量控制"等功能,而 Nginx 则常被用作"边缘反向代理"或"统一流量入口"。在实际项目里,这三者经常组合使用,以实现高扩展、高可用、可观测且灵活的流量调度。
一、Nacos + Gateway + Nginx 的常见部署架构
一般来说,可以把 Nginx 放在最外层作为"边缘代理"或"静态资源服务器",在内网或容器集群里部署 Gateway 实例作为微服务的入口网关,网关与 Nacos 对接获取后端微服务实例信息,然后将请求路由到对应的服务。
示意图:
┌───────────────────┐
Internet │ Nginx (Edge) │ <-- 监听80/443端口,做SSL、静态资源、反向代理
└────────┬──────────┘
│
▼
┌───────────────────┐
│ Spring Cloud │ <-- 网关集群(多个节点)
│ Gateway │ <-- 进行路由、鉴权、灰度流量控制
└────────┬──────────┘
│
┌──────────────────┴───────────────────┐
│ │
│ ┌───────────────────┐ │
│ │ microservice-A │ │ <-- 内部微服务集群
│ └───────────────────┘ │ <-- (多实例) 注册到 Nacos
│ │
│ ┌───────────────────┐ │
│ │ microservice-B │ │
│ └───────────────────┘ │
└──────────────────────────────────────┘
┌───────────────────┐
│ Nacos │ <-- 提供服务注册、发现、配置管理
│ (Discovery + Conf)│
└───────────────────┘
-
Nginx (Edge):
- 处理公网的 HTTP/HTTPS 流量,以及静态资源、域名解析等。
- 将请求反向代理到内网的 Gateway 集群地址。
-
Gateway (Spring Cloud Gateway / Zuul / etc.):
- 与 Nacos 整合,实现动态获取微服务实例列表。
- 进行更细粒度的负载均衡、路由转发、权限控制、限流、灰度发布等工作。
-
Nacos:
- 微服务(如 microservice-A、microservice-B)启动时向 Nacos 注册,网关也从 Nacos 拉取这些实例信息进行动态路由。
- 同时可做分布式配置管理。
这种架构好处:
- Nginx 专注处理边缘流量、SSL 证书、静态资源缓存等;
- Gateway 在内部网络中,实现微服务网关应有的路由、负载、鉴权、灰度、可观测功能;
- Nacos 提供统一的服务发现和配置管理;
- 部署和职责清晰,各组件各司其职,易于扩展和维护。
二、网关层负载均衡方案
Spring Cloud Gateway(或基于 LoadBalancer、Ribbon、Feign 等)的微服务负载均衡通常有两种模式:
-
基于服务名 :
在 Gateway 的路由配置中,写
lb://microservice-A
,Gateway 会通过 Spring Cloud LoadBalancer / Ribbon 去 Nacos 查询microservice-A
的实例列表,并根据轮询或自定义策略进行负载均衡。 -
基于元数据或标签:
- 如果需要灰度发布、按版本路由等,则可以在实例注册到 Nacos 时,设置
metadata.version=v2
等属性。 - Gateway 中的路由过滤器会基于请求头或特定条件筛选元数据为
v2
的实例,达到版本级或标签级的智能负载。
- 如果需要灰度发布、按版本路由等,则可以在实例注册到 Nacos 时,设置
示例:(简化写法)
yaml
spring:
cloud:
gateway:
discovery:
locator:
enabled: true # 开启基于 Nacos 的自动路由
routes:
- id: microservice-a
uri: lb://microservice-a
predicates:
- Path=/api/a/**
filters:
- StripPrefix=1
# 更多路由定义...
然后 Gateway 会自动通过 Nacos 找到 microservice-a
下所有可用实例并进行负载均衡。
三、Nginx 侧负载均衡最佳实践
3.1 在网关集群之上负载
如果你有多个 Gateway 实例(水平扩展),可以让 Nginx 来做第一层负载均衡,将外部流量分发到各 Gateway 实例。例如:
nginx
upstream gateway_cluster {
least_conn;
server 10.0.1.101:8080;
server 10.0.1.102:8080;
# 如果有更多 gateway 实例都可加上
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://gateway_cluster;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
- 网关集群 内部再通过 Nacos 寻址到微服务。
- 一般只在 Nginx 配置文件中维护 Gateway 实例即可,实例数量不会频繁变化,减少动态更新的复杂度。
3.2 直接负载微服务(不推荐)
如果你希望 Nginx 直接 负载到后端微服务实例,那么就需要自定义脚本 或 OpenResty + Lua 来让 Nginx 跟 Nacos 同步实例列表(详见 上一条回答 或网上类似方案)。
- 这种做法在大多数场景下不推荐,因为失去了网关层的可观测、流量管理、灰度控制等优势,维护起来也更复杂。
- 最佳实践 还是将负载均衡下沉到 Gateway,Nginx 只需知道 Gateway 的地址做统一外部入口。
四、常见问题与建议
-
为什么还要 Nginx,如果 Gateway 也能做反向代理和 SSL?
- 某些公司已有成熟的 Nginx 部署体系,用作七层安全防护、WAF、边缘缓存、流量统计等;或是依赖 Nginx 强大的高并发性能和成熟运维工具。
- 也可以让 Gateway 直接对外暴露端口进行 HTTPS / 证书管理,但运维成本及安全需求决定了许多公司仍然倾向在最外层保留 Nginx。
-
如何实现灰度 / 蓝绿发布?
- 最常见在 Gateway 层按用户标签或请求头区分流量;
- 如果想在 Nacos 上给不同实例打上
metadata.version
,再在 Gateway 的负载均衡策略里筛选可用实例,就能实现更精细的路由。
-
Nacos 配置管理如何与 Gateway 结合?
- Gateway 的路由规则或限流规则也可以存放在 Nacos Config 中,实现动态刷新;
- 或者使用 Apollo / Spring Cloud Config 的方式管理网关配置。关键是要有统一的配置中心,避免重复修改、维护困难。
-
性能和高可用
- Nacos:建议做集群部署(3 节点以上 odd 数目),并优化数据库写入/读取;
- Gateway:可横向扩容,多实例配合 Nginx 或负载均衡器;
- Nginx:也要做多节点或 keepalived / LVS 等方案防止单点;
- 在高流量场景,应重点关注网关与微服务的压测和监控(QPS、RT、内存、CPU)。
-
可观测与日志
- 建议在 Gateway 层做统一的链路追踪、埋点监控、日志收集(如 Zipkin / SkyWalking / SLS),更容易排查服务调用问题;
- Nginx Access Log 只提供最外层访问日志,有助于了解外部访问频次、来源 IP 等。
五、总结
- Nacos:服务发现 + 配置中心
- Gateway:微服务网关层(路由、鉴权、限流、灰度)
- Nginx:对外入口或边缘代理(SSL、静态资源、缓存、与 Gateway 集群负载均衡)
推荐架构:
- Nginx 在外部扮演"CDN/反向代理"角色,可将请求分发到内部 Gateway 集群;
- Gateway 与 Nacos 深度整合,通过服务名或元数据查找后端实例并进行更多流量治理;
- 微服务(如订单、库存、支付等)都在 Nacos 注册并实现动态上下线管理;
- 若需要更精细的灰度、蓝绿发布,可在 Gateway 层结合 Nacos metadata 做路由筛选;
- 如果有 K8s 等容器平台,也可结合 Ingress / Service Mesh 进行更先进的流量管理和服务发现。
通过此种分层,既能让 Nginx 继续发挥在边缘侧(安全、缓存、静态资源)的优势,又能让 Gateway + Nacos 充分利用 Spring Cloud Alibaba 生态的微服务治理功能,形成一个高可用、高扩展、易运维的分布式架构体系。