拆分流量

您可以透過流量拆分功能,指定某一服務內兩個版本或多個版本之間的流量分配百分比。流量拆分功能可讓您在版本之間執行 A/B 版本測試,並提供控管機制來協助您掌握功能發佈進度。

流量拆分功能適用於沒有明確指定版本的網址。舉例來說,下列的網址指定了特定服務中的所有可用版本,因此會將流量分開:

  • [MY_PROJECT].appspot.com:將流量分配至 default 服務的多個版本。
  • [MY_SERVICE].[MY_PROJECT].appspot.com:將流量分配至 [MY_SERVICE] 服務的多個版本。

如要瞭解系統如何把要求送達特定版本,請參閱要求的轉送方式

事前準備

在您設定傳送至版本的流量之前,請確認您的使用者帳戶含有必要權限

避免快取問題

在啟用流量拆分功能前,您可能需要留意潛在的快取問題。任何 App Engine 應用程式都可能出現快取問題,特別是在部署新版本時。而流量拆分功能通常會讓細微的快取問題變得更明顯。

舉例來說,假設您要拆分 A 和 B 兩個版本之間的流量,而一些外部可快取資源在兩個版本之間有所變更 (例如 CSS 檔案)。我們現在假設有個用戶端提出要求,且回應內容含有快取檔案的外部參照。無論快取的檔案版本及傳送回應的應用程式版本為何,只要快取中有該檔案,本機 HTTP 快取皆會進行擷取。快取資源可能會與回應內容中傳送的資料不相容。

如要避免快取問題:

  • 如為動態資源,請同時設定 Cache-ControlExpires 標頭,這些標頭會讓 Proxy 知道這是動態資源。由於並非所有 Proxy 伺服器都能適當支援 HTTP/1.1 Cache-Control 標頭,因此建議兩個標頭都設定。

    如要整體深入瞭解有關快取的資訊,請參閱 HTTP/1.1 RFC 中的標頭欄位瀏覽器資安手冊的文件快取

  • 如為隨版本改變的可快取靜態資源,請根據不同版本變更資源的網址。如果靜態資源是由不同網址提供,那麼兩個版本可共存於 Proxy 伺服器和瀏覽器快取中。

您也可以為應用程式設定 Vary: Cookie 標頭,以便系統合併要求的 Cookie 和網址,避免重複計算資源。然而,這個方法會增加快取伺服器的負擔。GOOGAPPUID 有 1000 個可能值,因此應用程式的每個網址可能會有 1000 個項目。這樣可能會降低快取成功率,視使用者和應用程式之間的 Proxy 負載而定。另請注意,在新的一批使用者加入某一版本後的 24 小時內,使用者仍可能會看見快取資源。不過,您可以使用 Vary: Cookie 輕鬆將會隨著版本變更內容的靜態資源重新命名。

Vary: Cookie 技術不一定適用於所有情況。一般來說,如果您的應用程式使用 Cookie 進行其他用途,則必須考量這個方法對 Proxy 伺服器負載造成的影響。如果 codeninja 本身的 Cookie 有 100 個可能值,則所有可能的快取項目數量會變得非常龐大 (100 * 1000 = 100,000)。最糟的狀況是每位使用者都有專屬的 Cookie。Google Analytics (分析) (__utma) 和 SiteCatalyst (s_vi) 是兩種這情況的常見範例。在這些範例中,每位使用者各有一個不重複的複本,因此快取效能會嚴重降低,且應用程式耗用的可計費執行個體時數可能也會隨之增加。

拆分多個版本的流量

當您指定兩個或多個版本來拆分流量時,必須選擇拆分流量的方式是使用 IP 位址或 HTTP Cookie。設定 IP 位址拆分較為容易,但使用 Cookie 拆分會比較準確。詳情請參閱 IP 位址拆分功能Cookie 拆分功能

主控台

如要在 GCP 主控台中拆分流量,請前往「版本」頁面:

前往版本頁面

  1. 選取您要拆分流量的一或多個版本。
  2. 按一下 [拆分流量] 並指定:
    • 拆分流量使用的方法。
    • 每個版本應接收的流量百分比。

gcloud

安裝 Google Cloud SDK 後,請執行以下指令拆分多個版本的流量,例如:

gcloud app services set-traffic [MY_SERVICE] --splits [MY_VERSION1]=[VERSION1_WEIGHT],[MY_VERSION2]=[VERSION2_WEIGHT] --split-by [IP_OR_COOKIE]

如需詳細資訊和其他選項,請參閱 gcloud app services set-traffic 參考資料。

API

如要透過程式遷移流量,您可以使用 Admin API,詳情請參閱遷移和拆分流量

IP 位址拆分功能

如果您選擇使用 IP 位址拆分送向應用程式的流量,當應用程式收到要求時,會雜湊 IP 位址來產生介於 0 至 999 的值,然後使用該數字轉送要求。

IP 位址拆分功能有一些重要的限制:

  • IP 位址通常會維持不變,但並非永久固定。如果使用者透過手機連線,IP 位址在單一工作階段期間可能會改變。同樣地,如果筆記型電腦的使用者從家中移到咖啡館工作,IP 位址也會一同變動。因此,使用者在使用您的應用程式時,可能會因 IP 位址變動而導致使用體驗不一致。
  • 由於 IP 位址是獨立分配至各個版本,因此流量拆分的結果會跟您指定的設定稍有不同。然而,隨著應用程式接收的流量增加,實際的拆分結果就會越接近您的目標。舉例來說,如果您要求將 5% 流量傳送至另一版本,則該版本的初期流量百分比實際上可能介於 3% 至 7% 之間,但最後平均會趨近於您設下的 5% 目標。
  • 如果您需要在應用程式之間傳送內部要求,則應改用 Cookie 拆分功能。對於在 Google 雲端基礎架構上執行的應用程式,如果應用程式之間傳送的要求是來自少量的 IP 位址,系統可能會將這些位址全都分配給同一個版本。因此,所有內部要求的運作方式可能會跟單一 IP 位址傳送的要求相同,代表這些要求全都會轉送至同一個版本。因此,內部要求不會完全符合以 IP 位址流量拆分方法所設定的百分比。舉例來說,如果您設定讓某版本接收應用程式總流量的 1%,而且 Google 雲端基礎架構位址恰巧都指派給該版本,則實際結果可能遠超過 1%,這是因為所有的內部要求會一律轉送至指派版本所導致。如果要求是從 Google 雲端基礎架構以外的地方傳送至應用程式,由於要求源自於不同的 IP 位址分配,因此會出現合乎預期的運作方式。

如果您選擇使用 Cookie 拆分送向應用程式的流量,應用程式會在 HTTP 要求標頭中找出名為 GOOGAPPUID 的 Cookie,其中含有介於 0 至 999 的值:

  • 如果該 Cookie 存在,系統會使用該值來轉送要求。
  • 如果該 Cookie 不存在,系統會隨機轉送要求。

如果回應內容不包含 GOOGAPPUID Cookie,應用程式會先新增 GOOGAPPUID Cookie,當中內含一個介於 0 至 999 的隨機值,接著再傳送回應。

使用 Cookie 拆分流量能輕鬆將使用者正確指派到各個版本。流量轉送的準確度可跟拆分目標只相差 0.1%。然而,Cookie 拆分功能有下列限制:

  • 如果您要撰寫行動應用程式或執行電腦版用戶端,應用程式必須管理 GOOGAPPUID Cookie。舉例來說,當使用 Set-Cookie 回應標頭時,您必須儲存 Cookie,並在每個後續要求中加入這個 Cookie。在瀏覽器中運作的應用程式會自動以這個方式管理 Cookie。

  • 拆分內部要求需要額外作業。針對所有從 Google 雲端基礎架構內傳送的使用者要求,您必須在每個要求中一同轉送使用者的 Cookie。舉例來說,在從應用程式傳送至其他應用程式或該應用程式本身的要求中,您都必須轉送使用者的 Cookie。請注意,如果這類要求並非來自於使用者,則不建議傳送內部要求。

停用流量拆分功能

如要停用流量拆分功能,您可以將所有流量遷移至單一版本

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

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

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