要求的處理方式

本文件說明 App Engine 應用程式如何接收要求及傳送回應。詳情請參閱要求標頭和回應參考資料

如果您的應用程式使用這些服務,則可以設定要求的位址,將要求傳送到特定服務或該服務的特定版本。如要進一步瞭解服務的轉送功能,請參閱要求的轉送方式

處理要求

您的應用程式負責啟動網路伺服器和處理要求。您可以使用任何適用於您的開發語言的網路架構。

App Engine 會執行應用程式的多個執行個體,每個執行個體都有自己專用的網路伺服器來處理要求。每個要求均有可能轉送至任何一個執行個體,因此來自同一個使用者的連續要求不一定會送到相同的執行個體。執行個體可以並行處理多個要求,而執行個體的數量能夠隨流量自動調整。您也可以在 app.yaml 檔案中設定 max_concurrent_requests 元素,藉此變更執行個體可以處理的並行要求數量。

App Engine 的 Go 執行階段使用標準的 http 套件做為 Go 程式與 App Engine 伺服器之間的介面。當 App Engine 收到應用程式的網路要求時,會叫用與要求網址相關的 http.Handler

以下範例為向使用者輸出硬式編碼 HTML 字串的完整 Go 應用程式:


package hello

import (
	"fmt"
	"net/http"
)

func init() {
	http.HandleFunc("/", hello)
}

func hello(w http.ResponseWriter, r *http.Request) {
	fmt.Fprintf(w, "<h1>Hello, world</h1>")
}

配額與限制

App Engine 會在流量增加時自動分配資源給您的應用程式。然而這項作業會受到下列限制:

  • App Engine 會為了低延遲時間 (回應要求的時間不到一秒) 的應用程式,保留自動調整資源配置的容量。如為具有高延遲時間 (例如在多個要求中,每個要求的回應時間超過一秒) 及高總處理量的應用程式,則需要白銀級、爍金級或白金級的支援。選用這類支援等級的客戶可與支援代表聯絡,要求提高總處理量上限。

  • 大幅受到 CPU 限制的應用程式可能也會產生一些額外的延遲時間,以便和相同伺服器上的其他應用程式有效率地共用資源。對靜態檔案的要求則不受這些延遲限制。

每個傳送至應用程式的要求均會計入「要求」限制,而回應要求所傳送的資料則會計入「連出頻寬 (可計費)」限制。

HTTP 及 HTTPS (加密連線) 要求均會計入「要求」、「連入頻寬 (可計費)」及「連出頻寬 (可計費)」的限制。GCP 主控台的「Quota」(配額) 詳細資料頁面也會個別回報「Secure Requests」(安全性要求)、「Secure Incoming Bandwidth」(安全連入頻寬) 與「Secure Outgoing Bandwidth」(安全連出頻寬) 的值,以供參考之用。僅有 HTTPS 要求會計入這些值。詳情請參閱配額頁面。

下列限制專門適用於要求處理常式:

限制 數量
要求大小 32 MB
回應大小 32 MB
要求持續時間 60 秒
檔案總數量的上限 (應用程式檔案和靜態檔案) 總計 10,000 個
每個目錄 1,000 個
應用程式檔案的大小上限 32 MB
靜態檔案的大小上限 32 MB
所有應用程式和靜態檔案的全部大小上限 前 1 GB 免費
前 1 GB 過後,每個月每 GB $ 0.026

回應限制

動態回應限制為 32MB。如果指令碼處理常式產生大於此上限的回應,伺服器會傳回空白回應並顯示「500 Internal Server Error」(內部伺服器錯誤) 狀態碼。這項限制不適用於從 Blobstore 或 Cloud Storage 提供資料的回應。

要求標頭

傳入 HTTP 要求包含用戶端傳送的 HTTP 標頭。基於安全性考量,部分標頭在送達應用程式之前會由中繼 Proxy 進行處理或修改。

詳情請參閱要求標頭參考資料

要求回應

App Engine 會使用 RequestResponseWriter 呼叫處理常式,然後等候處理常式寫入 ResponseWriter 並傳回。當處理常式傳回時,ResponseWriter 內部緩衝區的資料就會傳送給使用者。

這過程與編寫使用 http 套件的一般 Go 程式幾乎相同。

您產生的回應會受到一些限制,而且在傳回用戶端前可能已經過修改。

詳情請參閱要求回應參考資料

串流回應

針對在處理要求時以增量區塊傳送給用戶端的資料,App Engine 不支援其串流回應。系統會依上述方式收集所有來自您程式碼的資料,並做為單一 HTTP 回應傳送。

回應壓縮

如果用戶端傳送含有原始要求的 HTTP 標頭,指出用戶端可接受壓縮 (使用 gzip 格式壓縮) 的內容,App Engine 會自動壓縮處理常式回應資料,並附加適當的回應標頭。它會同時使用 Accept-EncodingUser-Agent 要求標頭,以判斷用戶端是否能穩定接收壓縮的回應。

自訂用戶端可使用 gzip 值來指定 Accept-EncodingUser-Agent 標頭,藉此指出他們能夠接收壓縮的回應。回應的 Content-Type 也可用來判斷壓縮是否適當;一般來說,系統會壓縮文字內容類型,但不會壓縮二進位內容類型。

App Engine 自動壓縮回應時,會將 Content-Encoding 標頭新增至回應中。

指定要求期限

要求處理常式通常要在大約 60 秒的時間限制內對要求產生並傳回回應。期限一到,要求處理常式就會中斷。 當 Go 要求處理常式超過期限時,系統便會終止其處理作業,而執行階段環境會將「HTTP 500 Internal Server Error」(內部伺服器錯誤) 傳回用戶端。

雖然要求的回應時間最長可達 60 秒,但 App Engine 會針對要求停留時間短暫的應用程式進行最佳化,尤其是回應要求只需耗費數百毫秒的應用程式。效率良好的應用程式能夠針對大部分的要求快速回應。而無法快速回應的應用程式,將無法隨著 App Engine 的基礎架構妥善調整規模。

如要瞭解常見的 DeadlineExceededError 肇因和建議的解決方法,請參閱處理 DeadlineExceededErrors 一文。

記錄

記錄套件包含 DebugfInfofWarningfErrorfCriticalf 函式,能夠將訊息寫入應用程式的記錄內。您可以使用 Stackdriver Logging。在 GCP 主控台查看及分析記錄。

下列範例示範可建構 appengine.Context (透過 *http. Request) 及記錄要求網址的 HTTP 處理常式。


package hello

import (
	"net/http"

	"google.golang.org/appengine"
	"google.golang.org/appengine/log"
)

func init() {
	http.HandleFunc("/", Logger)
}

func Logger(w http.ResponseWriter, r *http.Request) {
	ctx := appengine.NewContext(r)
	log.Infof(ctx, "Requested URL: %v", r.URL)
}

環境

Go 執行階段提供環境資訊的存取權,方法是透過 appengine.Context 的介面。詳情請參閱 appengine 套件參考資料。

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

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

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