拆分流量

您可以使用流量拆分功能，自行指定分配的比例，藉此將流量拆分給同一服務中的不同版本。流量拆分功能可讓您對不同版本執行 A/B 測試，並提供控管機制，以便您掌握功能發布的進度。

流量拆分功能可應用於未明確指定版本的網址。 舉例來說，以下網址所指定的目標是該項服務中所有的可用版本，因此會拆分流量：

• https://PROJECT_ID.REGION_ID.r.appspot.com：將流量分配至 default 服務的不同版本。
• https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com：將流量分配至 [SERVICE_ID] 服務的不同版本。

如要瞭解系統如何將要求指向特定版本，請參閱要求的轉送方式。

事前準備

透過設定將流量分配至特定版本前，請先確認您的使用者帳戶具備必要權限。

避免快取問題

啟用流量拆分功能前，請留意潛在的快取問題。任何 App Engine 應用程式都可能存在快取問題，特別是部署新版本時。流量拆分功能通常會讓原本難以察覺的快取問題一一浮現。

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

如要避免快取問題：

• 如果是動態資源，請同時設定 Cache-Control 和 Expires 標頭。這些標頭會告訴 Proxy 此為動態資源。由於並非所有的 Proxy 伺服器都能完整支援 HTTP/1.1 Cache-Control 標頭，因此建議您同時設定這兩個標頭。

  如要進一步瞭解快取相關資訊，請參閱 HTTP/1.1 RFC 中的標頭欄位說明和 Web 基礎知識中的 HTTP 快取概覽。

• 對於會隨著不同版本改變的可快取靜態資源，請在每個版本中使用不同的資源網址。如果靜態資源是由不同網址提供，兩個版本即可共存於 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 拆分功能。

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

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 拆分功能

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

停用流量拆分

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