全部產品
Search

搜尋本產品

    Serverless App Engine：為SAE應用配置雲原生API Gateway路由規則

    文件中心

    Serverless App Engine：為SAE應用配置雲原生API Gateway路由規則

    更新時間：Aug 18, 2026

    本文介紹如何為部署在Serverless應用引擎（SAE）中的應用配置雲原生API Gateway路由規則，以實現通過統一入口對外部請求進行精細化分發和管理。方案的核心是利用雲原生API Gateway作為流量入口，將滿足特定匹配條件的請求轉寄至後端SAE應用。

    業務情境說明

    在微服務架構中，應用通常被拆分為多個獨立的服務部署在SAE上。為了向外部暴露這些服務，並實現統一的流量管理、安全防護和可觀測性，需要一個中心化的入口。例如，一個電商系統需要將所有發往 www.example.com 網域名稱下 /orders 路徑的請求，安全、可靠地路由到後端的訂單服務。通過為SAE應用配置網關路由，可以精確控制流程量的轉寄邏輯，實現這一目標。

    方案架構

    方案通過雲原生API Gateway與SAE的整合，構建了一個從公網（或私網）到後端服務的完整請求鏈路。

    工作流程說明

    1. 用戶端向雲原生API Gateway的公網或私網地址發起HTTP或HTTPS請求。

    2. 網關接收請求後，根據預設的路由規則，對請求的網域名稱、路徑、方法、Header等屬性進行匹配。

    3. 當請求成功匹配一條規則後，網關通過整合的服務發現機制（如MSE Nacos或Kubernetes Service）擷取後端SAE應用執行個體的動態IP地址清單。

    4. 網關從健康的執行個體列表中選擇一個，並將請求轉寄至該執行個體。

    5. SAE應用處理請求並返迴響應，響應經由網關最終回傳給用戶端。

    此架構將流量管理與商務邏輯解耦，由網關負責處理路由、負載平衡、安全性原則和流量灰階等通用能力，使後端SAE應用可以更專註於業務實現。

    實施步驟

    以下步驟將引導完成一條從請求匹配到後端服務轉寄的完整路由規則配置，並包含驗證與排障指導。

    1. 建立路由規則

    1. 訪問SAE網關路由頁面。

    2. 選擇目標地區和命名空間，然後單擊建立網關路由。

    3. 在建立路由頁面，為規則設定一個唯一的路由名稱，例如 route-for-order-service。

    2. 定義請求匹配條件

    此步驟定義了哪些請求應被此規則處理。網關會按照精確度從高到低的順序匹配規則，成功匹配後即停止。

    1. 選擇網路類型。若要對外提供服務，選擇公網；若僅在VPC內部訪問，選擇私網。

    2. 在網關類型中選擇雲原生API Gateway，並指定一個與SAE應用處於同一VPC下的網關執行個體。

    3. 配置網域名稱。選擇請求需要匹配的網域名稱，例如 www.example.com。

    4. 配置路徑（Path）。這是路由匹配的核心，支援多種匹配方式。

      • 匹配邏輯：路徑匹配的優先順序為等於 > 首碼是 > 正則匹配。在同等匹配類型下，更長的路徑（如 /api/v1）優先順序高於更短的路徑（如 /api）。

      • 配置樣本：為匹配所有訂單相關的請求，可將條件設定為首碼是，路徑值為 /orders。

    5. （可選）更多匹配規則：添加更精細的匹配條件。

      • 方法（Method）：限制僅處理特定HTTP方法，如 GET 或 POST。

      • 要求標頭（Header）：基於要求標頭進行匹配，例如 version=v2。

      • 請求參數（Query）：基於URL查詢參數進行匹配，例如 channel=web。

    3. 配置後端服務目標

    定義請求在匹配成功後應被轉寄到哪個SAE應用。

    1. 選擇服務來源。這必須與後端SAE應用的服務註冊發現方式保持一致。

      • MSE Nacos：適用於使用Nacos進行服務註冊與發現的微服務應用。

      • K8s Service：適用於通過Kubernetes Service進行服務發現的容器化應用。

    2. 選擇使用情境。對於標準路由，選擇單服務。

    3. 在後端服務中，選擇目標SAE應用的應用程式名稱和對應的服務名稱。服務連接埠通常會自動讀取。

      若後端服務中應用列表為空白，檢查頁面頂部選擇的命名空間是否與應用所在命名空間一致。建立路由時所選命名空間必須與應用命名空間相同，網關執行個體需與該命名空間處於同一地區且使用同一VPC。

    4. 配置進階策略（可選）

    通過進階配置可以提升服務的健壯性和靈活性。

    在進階配置地區，可以配置以下策略：

    • 逾時時間（秒）：設定網關等待後端服務響應的最長時間。建議根據業務情境設定為一個合理的非零值（如30秒），以避免因後端服務響應慢而導致請求長時間掛起。設定為0表示永不逾時，這在生產環境中存在風險。

    • 重試策略：當後端服務調用失敗時，網關可以自動重試。

      • 重試次數：設定最大重試次數。

      • 重試條件：選擇觸發重試的條件，例如 connect-failure（串連失敗）或 refused-stream（請求被拒絕）。

      • 重試狀態代碼：當後端服務返回特定HTTP狀態代碼（如 502, 503）時觸發重試。注意：重試策略僅應用於等冪請求（如 GET, PUT, DELETE），以避免產生非預期的副作用。

    • Fallback：配置一個降級服務。當主後端服務完全不可用時，網關會將請求轉寄到此處指定的Fallback服務，從而實現服務降級，避免將錯誤直接暴露給用戶端。

    5. 儲存並驗證規則

    完成所有配置後，儲存規則並驗證其是否按預期工作。

    1. 單擊頁面底部的儲存按鈕。路由規則下發到網關執行個體通常需要幾十秒時間。

    2. 驗證DNS解析：確保路由規則中配置的網域名稱已通過CNAME記錄解析到雲原生API Gateway的公網地址。

    3. 發送測試請求：使用curl或其他HTTP用戶端工具，向網關發起一個符合匹配條件的請求。

    # 假設網關公網IP為 123.45.67.89，網域名稱為 www.example.com，路徑為 /orders/100
curl -v -H "Host: www.example.com" http://123.45.67.89/orders/100

    1. 分析結果：

      • 成功（2xx）：如果收到來自後端SAE應用的成功響應，說明路由規則已正確生效。

      • 404 Not Found：通常表示請求未能匹配任何路由規則。請檢查網域名稱、**路徑（Path）**等匹配條件是否與請求完全一致。

      • 502 Bad Gateway / 503 Service Unavailable：表示網關無法串連到後端服務。請檢查SAE應用是否在正常運行，以及服務發現配置是否正確。

    成本與風險說明

    • 成本構成：使用方式情節會涉及雲原生API Gateway的執行個體費用和公網流量費用。具體計費標準請參考相關產品文檔。

    • 主要風險：

      • 配置錯誤：錯誤的路由、逾時或重試配置可能導致業務流量中斷或異常。建議在測試環境中充分驗證後，再應用到生產環境。

      • 效能瓶頸：不合理的Regex或過於複雜的路由邏輯可能影響網關效能。應遵循最佳實務，簡化匹配規則。

    結論

    通過以上步驟，一條串連外部請求與內部SAE應用的網關路由規則已成功建立並生效。網關現在能夠根據定義的條件，將流量精確地轉寄到指定的後端服務。

    此基礎路由配置為實現更複雜的流量管理原則（如藍綠髮布、金絲雀發布）奠定了基礎，開發人員可以基於此進一步探索API Gateway提供的進階功能。