如果將 Gateway 單獨部署為一個服務而不做任何高可用處理，它確實會成為一個單點故障（SPOF, Single Point of Failure）。如果這個唯一的 Gateway 實例因為服務器宕機、應用崩潰、部署更新或其他任何原因而不可用，那么整個系統的所有外部請求都將無法訪問，后果非常嚴重。

因此，在生產環境中，絕對需要對 Spring Cloud Gateway 進行集群化部署。

下面我用一個表格和架構圖來詳細說明為什么以及如何做：

📊 單點部署 vs. 集群部署對比

🏗? Gateway 集群架構示意圖

標準的解決方案是為 Gateway 部署多個實例，然后在前端使用一個負載均衡器（Load Balancer）作為統一的流量入口。整個架構的流程如下所示：

flowchart TDInternet[Internet/外部流量] --> SLB[負載均衡器<br>SLB/ELB/F5/Nginx]subgraph GatewayCluster [Gateway 高可用集群]SLB --> G1[Gateway 實例 1<br>:9000]SLB --> G2[Gateway 實例 2<br>:9001]SLB --> G3[Gateway 實例 3<br>:9002]endG1 --> Discovery[服務注冊中心<br>Nacos/Eureka]G2 --> DiscoveryG3 --> Discoverysubgraph BusinessServiceCluster [業務服務集群]Discovery --> S1[業務服務 1<br>user-service]Discovery --> S2[業務服務 2<br>order-service]Discovery --> S3[業務服務 3<br>product-service]end

🔧 搭建 Gateway 集群的關鍵步驟

搭建一個高可用的 Gateway 集群并不復雜，主要涉及以下三個環節：

1. 部署多個 Gateway 實例：

• • 這是最簡單的一步。只需將相同的 Gateway 應用包部署到多臺服務器（或多個容器）上。
  • 每個實例的 application.yml 中的主要配置（如Nacos地址、路由規則）應該完全一致。
  • 每個實例的 server.port 可以相同（如果機器不同）也可以不同（如果在同一機器用不同端口，常用于本地測試）。

1. 使用負載均衡器 (LB)：

• • 這是集群的入口和關鍵。所有外部請求首先到達這個負載均衡器，再由它分發給后端的各個 Gateway 實例。
  • 選擇：

• • • 硬件負載均衡器：如 F5。
    • 云服務商提供的LB：這是最省事的方式，如 阿里云的 SLB、騰訊云的 CLB、AWS 的 ELB/ALB。它們本身通常就是高可用的。
    • 自建軟件LB：如 Nginx、HAProxy。你需要至少部署兩個Nginx節點并通過 Keepalived 實現VIP漂移，以避免Nginx本身成為單點。

1. 共享配置與服務發現：

• • 配置一致性：確保所有 Gateway 實例的路由、過濾器等配置完全相同。最佳實踐是使用配置中心（如 Nacos Config、Apollo），而不是將配置寫在每個應用的本地文件里。
  • 服務發現：所有 Gateway 實例和業務服務都需要注冊到同一個服務注冊中心（如 Nacos、Eureka）。這樣，任何一個 Gateway 實例都能準確地知道所有業務服務的網絡地址，從而正確地進行路由轉發。如上圖所示，這是Gateway集群能正確工作的基礎。

💡 集群下的注意事項

• 分布式會話：如果你在 Gateway 上做了登錄鑒權等功能，需要將會話（Session）存儲到外部存儲（如 Redis）中，以實現會話共享。這樣用戶請求被轉發到集群內任何一個 Gateway 實例上時，都能識別其登錄狀態。
• 限流器的作用域：如果你使用了基于Redis的分布式限流（如之前的 RequestRateLimiter），那么限流是集群級別的。例如，你設置了每秒10次請求，指的是整個集群所有實例加起來每秒處理10次，而不是每個實例10次。這正是你想要的效果。
• 健康檢查：負載均衡器需要能夠對后端的 Gateway 實例進行健康檢查，自動將故障實例從服務列表中剔除，從而保證流量的可靠性。

💎 總結

單獨部署的 Gateway 必須做成集群，否則就有單點故障風險。

核心部署模式就是：負載均衡器 (LB) + 多個 Gateway 實例 + 統一的服務注冊與配置中心。

對于生產環境，強烈推薦使用云服務商的負載均衡服務，因為它們提供開箱即用的高可用性和強大的流量處理能力，可以讓你更專注于業務開發本身。