为什么已经有 Nginx 了，还需要服务网关？

在当前微服务架构中，虽然 Nginx 是一个高性能的反向代理和负载均衡服务器，但在实际使用中仍然存在诸多局限性。为了满足运维效率、功能统一治理以及与微服务生态集成的需求，通常会在 Nginx 和业务服务之间引入一层基于 Java 实现的服务网关（API Gateway）。

🔧 从运维角度看：Nginx 的配置维护成本较高

在传统架构中，每当有新服务上线或已有服务扩容时，都需要手动修改 Nginx 的配置文件，并执行 reload 操作。例如：

bash 复制代码

upstream user-service {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

这种静态配置方式无法适应微服务架构中服务动态扩缩容、自动注册与下线的特性，导致运维复杂度上升。尤其是在大规模服务部署的情况下，频繁的手动配置更新不仅容易出错，还严重降低了系统的响应速度和灵活性。

🧑‍💻 从后端开发角度看：通用功能重复开发问题严重

每个微服务往往都需要单独实现诸如用户鉴权、接口限流、日志记录等公共功能，造成大量重复代码。虽然可以通过引入 SDK 的方式进行一定程度的复用，但每当需要新增功能（如日志告警）时，仍需修改所有相关服务并重新引入 SDK，维护成本高、升级困难。

将这些通用能力集中到网关层统一处理，不仅能减轻各业务服务的负担，还能有效解耦业务逻辑与通用治理逻辑，提升系统可维护性和一致性。

🛠️ 然而，Nginx 原生并不支持上述复杂的微服务治理功能

若要实现类似能力，通常需要借助 Lua 模块进行二次开发。然而，Lua 的开发门槛较高、调试不便，且团队技术栈可能并不匹配，进一步增加了实施难度。

例如，要在 Nginx 中实现简单的限流功能，你需要编写如下 Lua 脚本：

lua 复制代码

local limit_req = require "resty.limit.req"
local lim, err = limit_req.new("my_limit_req_store", 5, 1)
if not lim then
    ngx.log(ngx.ERR, "failed to instantiate a resty.limit.req object: ", err)
    return ngx.exit(500)
end

local key = ngx.var.binary_remote_addr
local delay, err = lim:incoming(key, true)
if not delay then
    if err == "no memory" then
        return ngx.exit(500)
    end
    -- delay == nil 表示请求被拒绝
    return ngx.exit(503)
end

这类脚本不仅难以维护，而且对非 Lua 技术栈的团队来说，学习成本极高。

✅ 解决方案：引入基于 Java 的服务网关

为了解决这些问题，可以在系统架构中引入一个基于 Java 实现的服务网关，例如 Spring Cloud Gateway 或 Zuul。它们具备良好的扩展性和开发友好性，能够更好地适配现代微服务架构的需求。

Java 生态本身拥有强大的工具链和丰富的开源组件支持，开发者可以更快速地实现各种定制化插件，如权限校验、灰度发布、流量染色、日志采集等功能，并通过热加载机制实现无需重启即可生效的能力。

此外，服务网关还可以与服务注册中心（如 Nacos、Eureka）无缝集成，实现服务实例的自动发现与负载均衡，从而真正实现服务治理的自动化与智能化。

🌐 总结一句话：

Nginx 是基础设施，适合做边缘接入；
服务网关是微服务治理的核心，负责统一处理鉴权、限流、熔断、路由等通用能力;

两者互补，共同构建完整的微服务网关体系。