拆分流量

您可以使用流量拆分功能,自行指定分配的比例,藉此將流量拆分給同一服務中的不同版本。流量拆分功能可讓您執行不同版本間的 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,應用程式會在傳送回應前先新增內含 0 至 999 隨機值的 GOOGAPPUID Cookie。

使用 Cookie 拆分流量可讓您輕鬆將使用者正確指派至不同版本。流量轉送準確度最高可達僅與拆分目標值相差 0.1%。然而,Cookie 拆分功能有下列限制:

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

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

停用流量拆分功能

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

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

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

這個網頁
Ruby 適用的 App Engine 彈性環境文件