一、Spring Cloud Gateway 是什麼

在微服務架構中，系統通常被拆分為多個獨立的小服務，每個服務有自己的端口與職責。
但用户請求需要通過統一入口進入系統，並正確路由到目標服務，這就是 API 網關（Gateway） 的職責。

Spring Cloud Gateway 是 Spring 官方推出的新一代網關組件，基於 Spring WebFlux + Reactor 響應式編程模型 構建，取代了老舊的 Zuul 1.x。

✅ 它與 Spring Cloud 全家桶（Nacos、OpenFeign、LoadBalancer） 無縫集成，具備高性能、可擴展、易維護等特性。

二、核心功能

三、執行流程：從請求到轉發的全過程

我們以訪問 /order/get 為例，來看 Gateway 的完整執行鏈路。

1️⃣ 請求到達 Gateway

所有外部請求（如前端 API 調用）首先到達 Gateway 的監聽端口（如 8080）。

2️⃣ 匹配路由規則（Route Predicate）

Gateway 會根據配置文件中定義的匹配規則，判斷該請求應路由到哪個微服務：

spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://order-service
          predicates:
            - Path=/order/**

lb://order-service 表示使用負載均衡，從 Nacos 獲取 order-service 實例。

3️⃣ 執行過濾器鏈（Filters）

在路由轉發前後，Gateway 會執行一系列過濾器。
常見過濾器場景包括：

• 鑑權過濾器：校驗 Token；
• Header 增強：添加統一請求頭；
• 限流與熔斷：控制訪問頻率；
• 日誌記錄：記錄請求耗時與路徑。

4️⃣ 通過 LoadBalancer 選擇實例

Gateway 調用 Spring Cloud LoadBalancer，從 Nacos 拉取 order-service 的服務實例列表。
然後根據策略（輪詢、隨機、權重等）選出目標實例。

5️⃣ 發起請求

Gateway 使用 WebClient（響應式 HTTP 客户端）將請求轉發到選中的服務節點。

6️⃣ 響應返回

目標服務返回響應後，響應數據同樣會經過過濾器鏈（如日誌、統一包裝等），再返回客户端。

四、身份認證放在哪更合適？

📘 結論：
推薦將認證邏輯放在 Gateway 層，實現統一 Token 驗證與權限控制。

🔒 示例：全局 Token 認證過濾器

@Component
public class AuthFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String token = exchange.getRequest().getHeaders().getFirst("Authorization");
        if (token == null || !isValidToken(token)) {
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }
        return chain.filter(exchange);
    }
    @Override
    public int getOrder() { return -1; }
}

五、LoadBalancer 與 Ribbon 的區別

📘 簡單理解：

• Ribbon 是過去獨立的客户端負載均衡；
• LoadBalancer 是現在官方內置方案，更輕量、響應式、與 Gateway 深度融合。

六、小項目中沒有 Gateway 時，可以使用 Ribbon 嗎？

✅ 可以，而且很常見。

在一些服務數量少（3~5個以內）、調用鏈簡單的小型項目中，引入 Gateway 反而增加複雜度。
這種情況下，可以直接使用 Ribbon 或 LoadBalancer 實現服務間的負載均衡。

示例：

@FeignClient(name = "user-service")
public interface UserClient {
    @GetMapping("/user/{id}")
    UserDTO getUser(@PathVariable Long id);
}

Ribbon 的流程：

1. 從 Nacos 拉取 user-service 實例；
2. 選擇一個實例（輪詢、隨機等）；
3. 發起 HTTP 調用。

✅ 對比 Gateway 與 Ribbon

📘 結論：

• 小項目：Ribbon / LoadBalancer 足夠用
• 大項目：必須使用 Gateway 統一網關層

七、Gateway + Nacos + OpenFeign 的完整鏈路關係

完整的服務調用鏈如下：

[Client] → [Spring Cloud Gateway]
     → [Nacos Service Discovery]
     → [Order-Service]
     → [OpenFeign]
     → [User-Service]

1️⃣ 客户端請求進入 Gateway

Gateway 根據路由規則匹配目標服務，如 lb://order-service。

2️⃣ Nacos 服務發現

Gateway 從 Nacos 獲取可用實例，LoadBalancer 根據策略選擇目標。

3️⃣ Gateway 轉發請求

認證、限流、日誌在此階段處理。

4️⃣ Order-Service 內部調用 Feign

@FeignClient(name = "user-service")
public interface UserClient {
    @GetMapping("/user/{id}")
    UserDTO getUser(@PathVariable Long id);
}

Feign 再次通過 LoadBalancer 從 Nacos 獲取 user-service 實例發起請求。

5️⃣ Nacos 健康維護

Nacos 持續接收服務實例心跳，Gateway 與 Feign 動態感知節點變化。

八、常見問題與優化建議

九、整體架構總結

總結一句話

在 Spring Cloud 微服務體系中，Gateway + Nacos + LoadBalancer + Feign 構成了完整的服務調用鏈。
它讓每個微服務既能保持獨立，又能高效協作，是現代分佈式系統的標準架構核心。