十万个why：有了 Spring Cloud Gateway，为什么前面还

有同学私信了我这个问题，Nginx能做反向代理，Gateway也能做，既然功能重叠，为什么还要两层？

这么想其实是因为看问题的视角局限在了功能上，从架构上看，这两者的定位很清晰的，Nginx 是网络流量网关，Spring Cloud Gateway 是业务网关。

它们不仅不是竞争关系，而是上下游的协作关系。

微服务架构的流量链路中，它们处于不同的层级，正常流程应该是：用户 - Nginx - Spring Cloud Gateway - 微服务

看下边这个图就很容易理解了，Nginx 接收公网的流量，Spring Cloud Gateway 是内网业务逻辑路由。

图片

我列几个还需要 Nginx 的原因：

1、静态资源访问

我们现在项目基本都是前后端分离的，后端服务返回业务数据，但前端的那些 HTML、CSS、JS、图片，谁来提供？

Nginx 处理静态文件有天然优势，Nginx 不用把文件数据读到用户态内存，直接通过内核态的 sendfile 系统调用，磁盘文件直接转发给网卡，全程无 CPU 拷贝开销，性能吊打 Java 十条街。

Gateway 基于 Netty 处理静态文件，哪怕用了 Netty 的零拷贝，数据也需要经过磁盘 → 内核缓冲区 → Netty 缓冲区 → 网卡这么走一圈，高并发静态请求下，性能远不如 Nginx。

让它去处理静态文件，有点像开法拉利拉砖，不是不能干，性价比极低。流量治理的逻辑处理，路由转发、限流熔断、灰度发布、鉴权过滤、负载均衡…… 这些才是它的长处。

Nginx 还能做动静分离，前端请求来了 Nginx 判断：

匹配 /api/** - 转发给 Gateway 去处理业务。

匹配 .html/.js/.css/图片 - Nginx 直接返回静态资源，毫秒级响应，用户体验很好，java 返回这些页面容易转圈。

图片

2、谁来给网关做负载均衡？

Gateway 自己也是一个 Java 服务，线上肯定要做高可用吧，关键服务不能只部一台，它万一挂了业务服务都访问不了了，好歹来 3 台组成一个集群。

那么问题来了，前端的请求，到底发给 IP1、IP2 还是 IP3？

Nginx 负责把流量均衡地分发给这 3 个 Gateway 节点，没有 Nginx，Gateway 集群就没有入口。