要求的轉送方式

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

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

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

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

詳情請參閱在開發伺服器中轉送

要求及網域

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]
  • 如果您使用手動調整資源配置服務,則可透過包含執行個體 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 主控台的版本頁面中查看設定用來接收流量的版本。

限制服務的存取權

所有服務均預設為公開。如果您要限制服務的存取權,請在服務的安全限制中加入 <role-name>admin</role-name> 元素。

範例

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

建立分派檔案

附註:這份參考資料使用 YAML 格式的設定檔,此設定檔由 Cloud SDK 的工具使用,例如 gcloud 指令列或以 Cloud SDK 為基礎的 MavenGradleEclipseIntelliJ 外掛程式。如果您使用 Java 適用的 App Engine SDK 工具,例如 appcfg,請使用 XML 格式

分派檔案應置於如 app.yaml 等其他設定檔所在的相同目錄。您最多可在分派檔案中定義 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 參考說明文件

部署分派檔案

dispatch.yaml 檔案可位於原始碼目錄中的任何位置。

如要在不更動目前提供版本的情況下部署分派設定檔,請根據您的環境,在分配檔案所在的目錄中使用下列其中一項指令:

gcloud

gcloud app deploy dispatch.yaml

Maven

mvn appengine:deployDispatch dispatch.yaml

Gradle

gradle appengineDeployDispatch dispatch.yaml

IDE

如果您使用 IntelliJEclipse,可透過部署表單選取要部署的個別設定檔。

在開發伺服器中轉送

探索執行個體位址

本機開發伺服器會在啟動時建立所有的執行個體。請注意,本機開發伺服器目前不支援基本資源配置執行個體。系統會指派專用的通訊埠給每個建立的執行個體。通訊埠指派會顯示在伺服器的記錄訊息串流中。網路用戶端可透過指定通訊埠的方式,與特定執行個體通訊。自動調整資源配置的服務只會建立一個執行個體 (和通訊埠),在伺服器記錄中顯示如下 (請注意,服務舊稱模組):

INFO: Module instance service-auto is running at http://localhost:37251/

指派不重複的通訊埠給手動調整資源配置服務的每個執行個體:

INFO: Module instance service-manual instance 0 is running at http://localhost:43190/
INFO: Module instance service-manual instance 1 is running at http://localhost:52642/

此外,系統還會指派一個額外的通訊埠給每個手動調整資源配置的服務,這樣用戶端就能存取該服務而不用指定特定的執行個體。傳送至這個通訊埠的要求會自動轉送至其中一個設定的執行個體:

INFO: Module instance service-manual is running at http://localhost:12361/

下表顯示如何在開發伺服器和 App Engine 環境中呼叫這些服務:

服務 執行個體 開發伺服器位址 App Engine 位址
service-auto (未使用) http://localhost:37251/ http://v1.service-auto.[PROJECT_ID].appspot.com/
service-manual 0 http://localhost:43190/ http://0.v1.service-manual.[PROJECT_ID].appspot.com/
service-manual 1 http://localhost:52642/ http://1.v1.service-manual.[PROJECT_ID].appspot.com/
service-manual (未使用) http://localhost:12361/ http://v1.service-manual.[PROJECT_ID].appspot.com/

如果您使用 Maven 或 Gradle 外掛程式,可以指派本機開發伺服器使用的通訊埠號。詳情請參閱 Apache MavenApache Maven (以 Cloud SDK 為基礎)Gradle

分派檔案

執行本機開發伺服器時會忽略所有分派檔案。指定執行個體的唯一方式就是透過執行個體的通訊埠。
本頁內容對您是否有任何幫助?請提供意見:

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

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