拆分流量

您可以使用流量拆分功能,自行指定分配的比例,藉此將流量拆分給同一服務中的不同版本。流量拆分功能可讓您執行不同版本間的 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 主控台中拆分流量,請前往「Versions」(版本) 頁面:

前往「Versions」(版本) 頁面

  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。請注意,如果這類要求並非來自於使用者,則不建議傳送內部要求。

停用流量拆分

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

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

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

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