要求的轉送方式

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

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

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

如果您使用本機開發伺服器來測試應用程式,則可用的轉送和分派功能會略有不同。如要透過程式建立實際工作環境和開發伺服器都能使用的網址,請使用 get_hostname 方法。

請參閱在開發伺服器中轉送以瞭解詳情。

要求及網域

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 主控台中,您可以查看對應的「Instances」(執行個體)、「Services」(服務) 和「Versions」(版本) 頁面。

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]
  • 如果您使用手動調整資源配置的服務,則可以加入執行個體 ID 來指定執行個體並傳送要求。執行個體 ID 為 0 到運作中執行個體總數之間的整數,可以按照下列方式指定:

    將要求傳送至特定執行個體中的特定服務和版本:

    https://[INSTANCE_ID]-dot-[VERSION_ID]-dot-[SERVICE_ID]-dot-[MY_PROJECT_ID].appspot.com
    http://[INSTANCE_ID].[VERSION_ID].[SERVICE_ID].[MY_CUSTOM_DOMAIN]

預設服務

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

限制服務的存取權

所有服務均預設為公開使用。如果您想要限制服務的存取權,請在其處理常式中加入 login: admin 元素。

範例

為了順利示範網址模式,請假設您有一個專案 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

appcfg

appcfg.py update_dispatch [YOUR_APP_DIR]

在開發伺服器中轉送

探索執行個體位址

本機開發伺服器會在啟動時建立所有手動調整資源配置的執行個體,並對自動調整和基本資源配置服務的執行個體採取動態管理。伺服器會指派通訊埠給每個服務,用戶端可以依賴伺服器執行平衡負載及自動選取執行個體。用於每個服務定址的通訊埠指派會出現在伺服器的記錄訊息串流中。以下是定義三種服務的應用程式使用的通訊埠 (與每個服務的資源調度類型無關):

INFO Starting module "default" running at: http://localhost:8084
INFO Starting module "service1" running at: http://localhost:8082
INFO Starting module "service2" running at: http://localhost:8083

當您使用服務的位址時 (例如 http://localhost:8082/),伺服器會選取 (或建立) 服務的執行個體,然後將要求傳送至這個執行個體。

伺服器會為服務的每個執行個體指派不重複的通訊埠。如要探索這些通訊埠,您必須使用管理伺服器。管理伺服器有一個不重複的通訊埠,這個通訊埠記載於訊息記錄中:

INFO Starting admin server at: http://localhost:8000

這個位址會帶領您前往管理伺服器主控台。您可以在主控台中按一下 [執行個體],查看應用程式執行個體的動態狀態:

dev_appserver 管理控制台的螢幕擷取畫面

每個手動和基本執行個體會以不同的項目顯示。執行個體編號是一種連結,可連至每個執行個體的不重複通訊埠位址。您可以將游標懸置在連結上,查看指派給這個執行個體的通訊埠,或按一下連結,將要求直接傳送給這個執行個體。

分派檔案

如果應用程式含有 dispatch.yaml 檔案,記錄訊息串流就會含有分派器通訊埠:

INFO Starting dispatcher running at: http://localhost:8080

系統會依據分派檔案中的規則,轉送傳送至這個通訊埠的要求。伺服器不支援含有主機名稱的 dispatch.yaml 檔案規則 (例如 url: "customer1.myapp.com/*")。伺服器將採用具有相對路徑模式的規則 (url: "*/fun"),所以您可以使用 http://localhost/fun/mobile 之類的網址將要求傳送至執行個體。如果您嘗試使用含有主機規則的 dispatch.yaml 檔案啟動應用程式,則伺服器將會在記錄串流中報告錯誤。

本頁內容對您是否有任何幫助?請提供意見:

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

這個網頁
Python 2 適用的 App Engine 標準環境