執行個體是 App Engine 的基本構成要素，用來提供託管應用程式所需的資源。在任何特定時間內，您的應用程式皆可在單一或多個執行個體上執行，處理遍布這些執行個體的要求。每個執行個體都包含一個安全性階層，確保執行個體不會意外相互影響。
App Engine 可在流量波動時自動建立及關閉執行個體，您也可以指定執行的執行個體數量 (不論流量為何)。如要決定建立新執行個體的方式和時機，請為應用程式指定資源調度類型。資源調度設定會套用至 App Engine 版本層級，並納入 app.yaml 檔案。
資源調度類型
App Engine 支援下列資源調度類型，可控管建立執行個體的方式和時間：
- 自動 (預設)
- 基本
- 手動
您可以在應用程式的 app.yaml 中指定縮放類型。根據預設，應用程式會使用自動調整資源配置，也就是說，App Engine 會管理閒置執行個體的數量。
- 自動調整資源配置
- 自動調整資源配置會根據要求頻率、回應延遲時間和其他應用程式指標建立執行個體。您可以設定
automatic_scaling元素，為每項指標指定閾值，以及隨時保持運作的執行個體數量下限。
- 基本資源配置
- 「基本資源調度」會在應用程式收到要求時建立執行個體。當應用程式處於閒置狀態時，系統就會關閉每個執行個體。基本資源配置非常適合間歇性工作或是由使用者活動驅動的工作。
- 手動調整資源配置
- 手動調整資源配置會指定持續執行的執行個體數量，無論工作負載程度為何皆然。這種資源配置類型讓各項工作 (例如複雜的初始化) 及各時期皆依賴記憶體狀態的應用程式得以執行。
| 功能 | 自動調整資源配置 | 基本資源配置 | 手動調整資源配置 |
|---|---|---|---|
| 要求逾時 |
HTTP 要求和工作佇列工作：10 分鐘。如果應用程式未在這個時間限制內傳回要求，App Engine 會中斷要求處理常式，並發出錯誤，供您的程式碼處理。 針對舊版執行階段 (Java 8、PHP 5 和 Python 2)：
|
HTTP 要求和工作佇列工作：24 小時。如果應用程式未在這個時間限制內傳回要求，App Engine 就會中斷要求處理常式，並發出錯誤，供您的程式碼處理。 基本調整資源配置的執行個體可選擇處理 |
與基本資源配置相同。 |
| 背景執行緒 (僅限 Java) | 不允許 | 允許 | 允許 |
| 住宅 | 系統會根據使用模式關閉執行個體。 |
系統會根據 idle_timeout 參數關閉執行個體。如果執行個體處於閒置狀態 (例如未收到要求) 的時間超過 idle_timeout，系統就會關閉這個執行個體。 |
執行個體會留在記憶體中，不論處理多少要求，狀態均維持不變。停止執行個體時，記錄檔中會顯示 /_ah/stop 要求。如果有 /_ah/stop 處理常式或已註冊的關閉掛鉤 (Java、Python)，則掛鉤在關閉前有 30 秒可完成作業。
|
| 啟動與關閉 | 執行個體是在需要處理要求時建立，並於閒置時自動關閉。 |
執行個體是在需要處理要求時建立，並根據 idle_timeout 設定參數於閒置時自動關閉。手動停止的執行個體有 30 秒可以結束處理要求，之後就會被強制終止。 |
App Engine 會採用向 /_ah/start 發出的空白 GET 要求格式，自動將啟動要求傳送給執行個體。和基本資源調度一樣，手動停止的執行個體有 30 秒可以結束處理要求，之後就會被強制終止。 |
| 執行個體定址能力 | 執行個體屬於匿名資源。 |
服務「s」的「v」版本的「i」例項可透過以下網址存取：
https://i-dot-v-dot-s-dot-app_id.REGION_ID.r.appspot.com。
如果您已為自訂網域設定
萬用字元子網域對應，也可以透過 https://s.domain.com 或 https://i.s.domain.com 格式的網址，為服務或其任何執行個體定址。您可以放心將狀態暫存在每個執行個體中，在之後要求時再擷取狀態。 |
與基本資源配置相同。 |
| 資源調度 |
App Engine 可根據處理量自動調整執行個體的數量。這項資源配置包含設定檔中依據版本提供的 automatic_scaling 設定。 |
採用基本資源配置的服務的設定方式是透過在 basic_scaling 設定的 max_instances 參數中設定執行個體數量上限。運作中的執行個體數量會隨著處理量而調整。 |
您可以在服務的設定檔中設定每個版本的執行個體數量。執行個體的數量通常會對應到保存在記憶體中的資料集大小，或是希望達到的離線工作總處理量。 |
調整動態執行個體的資源配置
採用基本或自動調整資源配置的 App Engine 應用程式，會在特定時間內，依傳入要求的數量，提供任意數量的動態執行個體來支援應用程式。隨著對應用程式發出的要求量增加，動態執行個體的數量也可能隨之增加。
含有基本資源調度的應用程式
如果您使用基本資源配置，App Engine 會盡量降低成本，但這可能會導致傳入要求量增加，進而導致延遲時間變長。
如果沒有任何現有執行個體可用於處理傳入的要求，App Engine 就會啟動新的執行個體。即使已啟動新執行個體，部分要求可能仍需要排入佇列，直到新執行個體完成啟動程序為止。如果您需要盡可能縮短延遲時間，不妨考慮使用自動資源調度功能，這項功能會預先建立新執行個體，盡可能縮短延遲時間。
支援自動調整資源配置的應用程式
如果您使用自動調整資源配置功能，應用程式中的每個執行個體都會有自己的傳入要求佇列。在佇列變得足夠長，對應用程式延遲造成明顯影響之前，App Engine 會自動建立一或多個新執行個體，以處理不斷增加的負載。
您可以設定自動調度資源的設定，在所需效能和可能產生的成本之間取得平衡。下表說明這些設定。
| 自動調整資源配置設定 | 說明 |
|---|---|
| 目標 CPU 使用率 | 設定 CPU 使用率門檻，超過這個門檻時，系統會啟動更多執行個體來處理流量。 |
| 目標處理量使用率 | 針對並行要求的數量設定總處理量門檻，超過這個門檻時，系統會啟動更多執行個體來處理流量。 |
| 並行要求數量上限 | 設定單一執行個體可接受的並行要求數量上限，超過上限時，排程器會產生新的執行個體。 |
請觀看 App Engine 排程器設定影片，瞭解這些設定的效果。
縮減
當要求量減少時，App Engine 會減少執行個體數量。這種資源配置的縮減方式有助於確保應用程式目前的所有執行個體皆以最佳效率執行，並具有成本效益。
完全未使用某個應用程式時，App Engine 會關閉相關的動態執行個體，但可以在需要時立即重新載入這些執行個體。重新載入執行個體可能會產生載入要求，並讓使用者等候額外的延遲時間。
您可以根據要求量的多寡，為應用程式設定適當的閒置執行個體數量下限。如此一來，除非異常湧進大量要求，否則應用程式均能以極短的延遲時間為每個要求提供服務。
在自動調整資源配置中縮減資源
如果應用程式採用自動調度資源功能，閒置的執行個體大約需要 15 分鐘的閒置時間才能開始關閉。如要讓一或多個閒置執行個體持續執行，請將 min_idle_instances 的值設為 1 以上。
調整及批次處理要求
如果您將要求批次傳送至服務，例如傳送至工作佇列以進行處理，系統將會快速地建立大量的執行個體。建議您盡可能對每秒傳送的要求數量進行頻率限制，以控制執行個體的增生速度。舉例來說，如果您使用 Google Tasks，可以控制推送工作的速率。
執行個體生命週期
執行個體狀態
如果是自動調整資源配置的服務，其執行個體會一直處於執行中的狀態。但如果是手動調整資源配置或基本調整資源配置的服務，其執行個體狀態可能為執行中或已停止。相同服務與版本的所有執行個體會共用相同的狀態。您可以透過管理版本來變更執行個體的狀態，您可以：
- 使用Google Cloud 控制台中的「Versions」頁面
- 使用
gcloud app versions start和gcloud app versions stop指令
啟動
每個服務執行個體都是為了因應啟動要求而建立，啟動要求是向 /_ah/start 發出的空白 HTTP GET 要求。App Engine 會傳送這項要求來啟動執行個體，使用者則無法將要求傳送至 /_ah/start。採用手動和基本資源調度設定的執行個體都必須先回應啟動要求，接著才能處理其他要求。啟動要求有下列兩個用途：
- 啟動無限期運作的程式，不再接受其他要求。
- 在執行個體接收其他流量之前，先初始化該執行個體。
採用手動資源調度、基本資源調度和自動調整資源配置設定的執行個體會以不同方式啟動。您在啟動手動調度資源的執行個體時，App Engine 會立即將 /_ah/start 要求傳送至各個執行個體。您在啟動基本資源調度服務執行個體時，App Engine 會允許其接收流量，但必須等到收到第一項使用者要求之後，才會向執行個體傳送 /_ah/start 要求。除非需要處理的流量增加，否則系統不會啟動多個基本資源調度執行個體。自動調整資源配置的執行個體不會收到任何 /_ah/start 要求。
如果執行個體以 HTTP 狀態碼 200–299 或 404 回應 /_ah/start 要求，即視為該執行個體已成功啟動且可以處理其他要求。否則，App Engine 會終止該執行個體。系統會立即重新啟動手動調整資源配置的執行個體，但基本資源配置的執行個體只有在需要提供流量時才會重新啟動。
關閉
各種計畫或非計畫中的事件都有可能會觸發關閉程序，例如：
- 執行個體太多，但應用程式要求 (流量) 不足。
- 您以手動方式停止執行個體。
- 您將更新過的版本部署至服務。
- 執行個體超過所設
instance_class的記憶體上限。 - 應用程式耗盡「執行個體時數」配額。
- 執行個體已移至其他機器，因為原本執行個體所在的機器重新啟動，或是 App Engine 為了改善負載分配而移動執行個體。
如前文「縮減資源」一節所述，App Engine 標準環境的「只需支付所需資源」平台的其中一個優點，就是在沒有流量時，系統會自動將執行個體數量調降至零。這有助於讓 App Engine 成為不接收持續要求的小型應用程式的經濟實惠解決方案。當需要關閉執行個體時，系統會將新收到的要求導向其他執行個體 (如有)，並給予目前正在處理的要求完成時間。
App Engine 通常會將 STOP (SIGTERM) 訊號傳送至應用程式容器。應用程式不需要回應這個事件，但可以利用這個事件在容器關閉前執行任何必要的清理動作。在正常情況下，系統會等待最多 2 秒，讓應用程式停止運作，然後傳送 KILL (SIGKILL) 信號。如果應用程式未接收到 SIGTERM 信號，執行個體會立即關閉。
您可能會看到以下執行個體關閉記錄訊息：
[start] Quitting on terminated signal
[INFO] Handling signal: term
[INFO] Worker exiting (pid: 21)
[INFO] Worker exiting (pid: 24)
[INFO] Shutting down: Master
[start] Start program failed: termination triggered by nginx exit
這些記錄訊息並未指出任何錯誤狀態，而是表示正常的執行個體關閉程序。請注意，記錄檔中的 [start] 和 Start 是指名為 start 的平台程序，與啟動執行個體或應用程式無關。
載入要求
當 App Engine 為應用程式建立新的執行個體時，該執行個體必須先載入處理要求所需的任何程式庫和資源。這項作業會在第一個要求傳送至執行個體期間 (稱為「載入要求」) 進行。在載入要求期間，應用程式會進行初始化作業，致使該要求耗費更長的時間。
您可參考下列最佳做法，以減少載入要求的所需時間：
- 只載入啟動所需的程式碼。
- 盡量減少對磁碟的存取。
- 在某些情況下，從 zip 或 jar 檔案載入程式碼，會比從許多個別檔案載入程式碼還要快。
暖機要求
暖機要求是一種特定類型的載入要求，會在有任何實際要求之前，預先將應用程式的程式碼載入執行個體中。手動調整或基本資源配置執行個體不會收到 /_ah/warmup 要求。
如要進一步瞭解如何使用暖機要求，請參閱「設定暖機要求」。
執行個體運作時間
App Engine 會嘗試讓手動調整和基本資源配置執行個體保持無限期運作，但是目前仍無法保證採用這兩種資源配置方式的執行個體的運作時間。
NTP 與 App Engine 標準環境
App Engine 標準環境提供使用 Google NTP 伺服器的網路時間通訊協定 (NTP) 服務。不過，無法編輯 NTP 服務。
管理服務
視執行個體的調整型態而定，您可以在 Google Cloud 控制台或 Google Cloud CLI 中管理服務和版本。
停止版本
根據您設定的處理流量，App Engine 中的每個版本都會在一或多個執行個體中執行。
按一下分頁標籤，瞭解如何使用自選工具：
主控台
如要停止或停用服務的版本，請按照下列步驟操作：
前往 Google Cloud 控制台的 App Engine「Versions」頁面：
從表格中選取版本，然後按一下「停止」。
gcloud
執行以下指令：
gcloud app versions stop --service=SERVICE VERSION
取代：
- SERVICE 改為您的服務名稱。
- VERSION 改為您的服務版本名稱。
刪除服務
每項服務都可以設定為使用不同的執行階段，並以不同的效能設定運作。您無法刪除預設服務。刪除服務時，系統也會一併刪除專案中的所有相關版本。
按一下分頁標籤，瞭解如何使用自選工具：
主控台
如要刪除服務：
前往 Google Cloud 控制台的 App Engine「Services」(服務) 頁面：
在表格中選取服務，然後按一下「刪除」。
gcloud
執行以下指令：
gcloud app services delete SERVICE
取代：
- SERVICE 改為您的服務名稱。