在當前微服務架構中，雖然 Nginx 是一個高性能的反向代理和負載均衡服務器，但在實際使用中仍然存在諸多局限性。為了滿足運維效率、功能統一治理以及與微服務生態集成的需求，通常會在 Nginx 和業務服務之間引入一層基于 Java 實現的服務網關（API Gateway）。

🔧 從運維角度看：Nginx 的配置維護成本較高

在傳統架構中，每當有新服務上線或已有服務擴容時，都需要手動修改 Nginx 的配置文件，并執行 reload 操作。例如：

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

這種靜態配置方式無法適應微服務架構中服務動態擴縮容、自動注冊與下線的特性，導致運維復雜度上升。尤其是在大規模服務部署的情況下，頻繁的手動配置更新不僅容易出錯，還嚴重降低了系統的響應速度和靈活性。

🧑?💻 從后端開發角度看：通用功能重復開發問題嚴重

每個微服務往往都需要單獨實現諸如用戶鑒權、接口限流、日志記錄等公共功能，造成大量重復代碼。雖然可以通過引入 SDK 的方式進行一定程度的復用，但每當需要新增功能（如日志告警）時，仍需修改所有相關服務并重新引入 SDK，維護成本高、升級困難。
將這些通用能力集中到網關層統一處理，不僅能減輕各業務服務的負擔，還能有效解耦業務邏輯與通用治理邏輯，提升系統可維護性和一致性。

🛠? 然而，Nginx 原生并不支持上述復雜的微服務治理功能

若要實現類似能力，通常需要借助 Lua 模塊進行二次開發。然而，Lua 的開發門檻較高、調試不便，且團隊技術棧可能并不匹配，進一步增加了實施難度。
例如，要在 Nginx 中實現簡單的限流功能，你需要編寫如下 Lua 腳本：

local limit_req = require "resty.limit.req"
local lim, err = limit_req.new("my_limit_req_store", 5, 1)
if not lim thenngx.log(ngx.ERR, "failed to instantiate a resty.limit.req object: ", err)return ngx.exit(500)
endlocal key = ngx.var.binary_remote_addr
local delay, err = lim:incoming(key, true)
if not delay thenif err == "no memory" thenreturn ngx.exit(500)end-- delay == nil 表示請求被拒絕return ngx.exit(503)
end

這類腳本不僅難以維護，而且對非 Lua 技術棧的團隊來說，學習成本極高。

? 解決方案：引入基于 Java 的服務網關

為了解決這些問題，可以在系統架構中引入一個基于 Java 實現的服務網關，例如 Spring Cloud Gateway 或 Zuul。它們具備良好的擴展性和開發友好性，能夠更好地適配現代微服務架構的需求。

Java 生態本身擁有強大的工具鏈和豐富的開源組件支持，開發者可以更快速地實現各種定制化插件，如權限校驗、灰度發布、流量染色、日志采集等功能，并通過熱加載機制實現無需重啟即可生效的能力。
此外，服務網關還可以與服務注冊中心（如 Nacos、Eureka）無縫集成，實現服務實例的自動發現與負載均衡，從而真正實現服務治理的自動化與智能化。

🌐 總結一句話：

• Nginx 是基礎設施，適合做邊緣接入；
• 服務網關是微服務治理的核心，負責統一處理鑒權、限流、熔斷、路由等通用能力;

兩者互補，共同構建完整的微服務網關體系。