要求的轉送方式

本頁面說明如何將使用者發出的 HTTP 要求送達適當的服務版本。您可透過兩種方式轉送要求:

  • App Engine 的預設轉送規則適用於網址結尾為網域層級的要求。

  • 您也可以使用分派檔案,依照您自己的規則轉送特定的網址模式。

這些選項僅適用於已部署的應用程式。如果您是在本機上測試,轉送行為會因您使用的特定執行階段與開發環境而異。

要求及網域

App Engine 會依照傳入要求的網域名稱,判斷該要求的目標是否為您的應用程式。網域名稱為 http://[YOUR_PROJECT_ID].appspot.com 的要求會轉送至 ID 為 [YOUR_PROJECT_ID] 的應用程式。每個應用程式都會免費獲得一個 appspot.com 網域名稱。

appspot.com 網域也支援 [SUBDOMAIN]-dot-[YOUR_PROJECT_ID].appspot.com 格式的子網域,其中的 [SUBDOMAIN] 可以是任何能在網域名稱中使用的字串,但不能使用 . 字元。所有以這種方式傳送到任何子網域的要求均會轉送至您的應用程式。

您可以使用 G Suite 設定自訂的頂層網域,然後將子網域指派給各種應用程式,例如 Google Mail 或 Google 協作平台,也可以將 App Engine 應用程式連結到子網域。如要進一步瞭解如何將自訂網域對應到應用程式,請參閱使用安全資料傳輸層 (SSL) 保護自訂網域

這些網址的要求都會傳送至您設定接收流量的應用程式版本。應用程式的每個版本都有自己的網址,因此您可以先部署及測試新版本,再對版本進行接收流量的設定。除了網域名稱 appspot.com 之外,版本專屬網址還包含特定版本的 ID,例如:http://[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com。您也可以在版本專屬網址中加入子網域:http://[SUBDOMAIN]-dot-[VERSION_ID]-dot-[YOUR_PROJECT_ID].appspot.com。如需詳細資訊及範例,請參閱透過網址轉送

用於要求的網域名稱會加入傳送至應用程式的要求資料。因此,您可以使用要求資料,來控制應用程式根據要求中的網域名稱進行回應的方式。舉例來說,如果您想要重新導向至官方網域,可以編寫應用程式的程式碼來檢查 Host 要求標頭,然後根據網域名稱提供相應的回應。

透過網址轉送

您可以透過具體程度不同的條件指定 HTTP 要求。在以下範例中,如果您有自訂網域,則 appspot.com 可以替換成應用程式的自訂網域[VERSION_ID][SERVICE_ID][MY_PROJECT_ID]等網址子字串皆代表應用程式的資源 ID。

提示:您可以使用下列工具擷取應用程式的資源 ID:

主控台

在 GCP 主控台中,您可以查看對應的執行個體服務版本頁面。

gcloud

執行 gcloud app instances list 指令,列出特定 GCP 專案中的資源 ID。

API

如要透過程式擷取資源 ID,請參閱 Admin API 中的 list 方法

預設轉送

下列網址模式使用預設的轉送行為。請注意,如果您在分派檔案中定義了比對模式,預設的轉送方式將會遭到覆寫:

  • 將要求傳送至 default 服務的可用執行個體:
    https://[MY_PROJECT_ID].appspot.com
    http://[MY_CUSTOM_DOMAIN]

    您在 default 服務中設定接收流量的版本會收到這些要求。

  • 將要求傳送至特定服務的可用執行個體:
    https://[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[SERVICE_ID].[MY_CUSTOM_DOMAIN]

    您在指定服務中設定接收流量的版本會收到這些要求。如果您指定的服務不存在,系統將軟轉送這些要求。

  • 將要求傳送至
    default 服務中特定版本的可用執行個體:
    https://[VERSION_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[VERSION_ID].[MY_CUSTOM_DOMAIN]

    如果未指定服務,系統會將要求傳送至 default 服務。

軟轉送

如果要求符合主機名稱的 [YOUR_PROJECT_ID].appspot.com 部分,但是含有不存在的服務、版本或執行個體,則系統會將要求轉送至 default 服務。軟轉送不適用於自訂網域;如果主機名稱無效,傳送到這些網域的要求將傳回 HTTP 404 狀態碼。

指定轉送

採用下列網址模式即可保證送達目標 (如果目標確實存在)。您在分派檔案中定義的模式絕不會攔截和重新轉送這些要求:

  • 將要求傳送至特定服務和版本的可用執行個體:
    https://[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[VERSION_ID].[SERVICE_ID].[MY_PROJECT_ID].[MY_CUSTOM_DOMAIN]

預設服務

當您部署應用程式的初始版本至 App Engine 時,即會建立 default 服務。未指定任何服務或指定無效服務的要求會轉送至 default 服務,接著您在 default 服務中設定接收流量的版本將處理這些要求。您可以在 GCP 主控台的版本頁面中查看哪些版本已設定接收流量。

範例

為了協助示範網址模式,請假設有個 ID 為 requestsProject 的 GCP 專案範例,其中有應用程式正在執行兩個服務和版本。這個應用程式範例的 default 服務包含 vFrontend 版本,而第二個服務 service2 則含有 vBackend 版本。

如要指定特定的服務和版本,可以使用下列網址模式:

  1. 如要以 HTTPS 在 default 服務中指定版本,可以使用:

    https://vFrontend-dot-default-dot-requestsProject.appspot.com
    https://vFrontend-dot-requestsProject.appspot.com
    
  2. 如要以非 HTTPS 的自訂網域指定 vBackend 版本,可以使用:

    http://vBackend.service2.example.net
    http://vBackend.example.net
    

    其中,requestsProject.appspot.com 會對應至 example.net 網域。

使用分派檔案轉送

對於使用前述模式的網址,您可以建立分派檔案來覆寫 App Engine 的轉送規則,以及定義自己的自訂轉送規則。分派檔案可以讓您根據要求網址中的路徑或主機名稱,將傳入要求傳送至特定服務。

如要深入瞭解建立分派檔案的方式,請參閱 dispatch.yaml 參考資料。

建立分派檔案

分派檔案應存放在專案目錄的根目錄,或 default 服務的根目錄中。您在分派檔案中最多可以定義 20 個轉送規則,每個規則皆由 serviceurl 元素組成。

舉例來說,您可以建立分派檔案,將像是 http://simple-sample.appspot.com/mobile/ 的行動要求轉送至行動裝置前端,以及將像是 http://simple-sample.appspot.com/work/ 的工作站要求轉送至靜態後端:

dispatch:
  # Send all mobile traffic to the mobile frontend.
  - url: "*/mobile/*"
    service: mobile-frontend

  # Send all work to the one static backend.
  - url: "*/work/*"
    service: static-backend

如要深入瞭解定義 dispatch.yaml 的方式,請參閱 dispatch.yaml 參考說明文件

部署分派檔案

如要部署分派設定檔,請執行下列指令:

gcloud

gcloud app deploy dispatch.yaml
本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Node.js 適用的 App Engine 彈性環境文件