作者 | Jennifer Shin、Tejas Shikhare、Will Emmanuel
譯者 | Sambodhi
策劃 | Tina
導讀：本文介紹了.NETflix 在 2022 年將其移動應用程序遷移到 GraphQL 的過程。他們采用了 AB 測試、Replay 測試和 Sticky Canaries 策略來確保安全地進行遷移。
在 2022 年，Netflix 的 IOS 和 Android 應用程序發生了重大變化。我們將 Netflix 的移動應用程序遷移到了 GraphQL，并實現了零停機時間，這涉及了從客戶端到 API 層的全面改進。
直到最近，我們的移動應用程序使用的是內部 API 框架 Falcor。現在，它們使用了 Federated GraphQL，這是一種分布式的 API 方法，領域團隊可以獨立地管理和擁有特定部分的 API。
在不中斷數億用戶的情況下 安全地進行這項工作是極具挑戰性的，特別是考慮到所涉及的眾多變化維度。本博文將分享我們在進行這次遷移時使用的廣泛適用的技術（超出了 GraphQL 范疇）。今天我們將討論的三種策略是 AB 測試、Replay（回放）測試和 Sticky Canaries（金絲雀發布）。
遷移細節
在深入討論這些技術之前，讓我們簡要了解一下遷移計劃。
在使用 GraphQL 之前：API 團隊實施和維護的單體式 Falcor API：
在遷移到 GraphQL 之前，我們的 API 層由使用 Falcor 構建的單體服務器組成。一個 API 團隊同時維護 Falcor 框架的 JAVA 實現和 API 服務器。
階段 1
在我們現有的單體 Falcor API 之上創建了一個 GraphQL Shim 服務。
到 2020 年夏季，許多 UI 工程師已準備好開始使用 GraphQL。我們沒有選擇從頭到尾進行完整的遷移，而是在現有的 Falcor API 之上創建了一個 GraphQL shim。GraphQL shim 使得客戶端工程師能夠快速切換到 GraphQL，解決客戶端方面的問題，如緩存規范化，嘗試不同的 GraphQL 客戶端，并在不受服務器端遷移的阻礙下研究客戶端性能。為了安全地啟動第一階段，我們使用了 AB 測試。
階段 2
廢棄 GraphQL Shim 服務和傳統 API 單體，轉而采用由領域團隊擁有的 GraphQL 服務。
我們不希望傳統的 Falcor API 永遠存在，因此我們采用了 Federated GraphQL 來支持一個具有多個 GraphQL 服務器的單一 GraphQL API。
我們還可以通過聯合指令將 GraphQL Shim 的字段實現與 Video API 進行交換。為了安全地啟動第二階段，我們使用了 Replay 測試和 Sticky Canaries。
測試策略：概述
我們的測試策略受到兩個關鍵因素的影響：
- 功能需求與非功能需求
- 冪等性
如果我們正在測試數據準確性等 功能需求，并且請求是 冪等的，我們會依靠 Replay 測試。我們知道我們可以使用相同的查詢和相同的輸入進行測試，并始終期望得到相同的結果。
對于請求非冪等字段的 GraphQL 查詢或變更，我們無法進行 Replay 測試。
在 非功能需求（如緩存和記錄用戶交互）的情況下，我們肯定無法進行 Replay 測試。在這種情況下，我們并不測試響應數據，而是整體行為。因此，我們依賴于基于更高層次指標的測試： AB 測試和 Sticky Canaries。
讓我們詳細討論一下這三種測試策略。
工具：AB 測試
Netflix 傳統上使用 AB 測試來評估新產品功能是否符合客戶的需求。 在第一階段，我們利用 AB 測試框架將一個用戶群體分為兩組，總共 100 萬用戶。對照組的流量使用傳統的 Falcor 堆棧，而實驗組利用新的 GraphQL 客戶端，并指向 GraphQL Shim。為了確定對客戶的影響，我們可以比較各種指標，如錯誤率、延遲和渲染時間。
我們設置了一個客戶端 AB 實驗，測試 Falcor 與 GraphQL，并報告了粗粒度的用戶體驗指標（quality of experience metrics， QoE）。AB 實驗結果表明，GraphQL 的正確性達不到遺留系統的水平。在
接下來的幾個月，我們深入研究了這些高級指標，并修復了緩存 TTL、有缺陷的客戶端假設等問題。
優勢
高級健康指標：AB 測試為我們的整體客戶端 GraphQL 實現提供了所需的保證。這幫助我們在 6 個月內成功將移動首頁畫布上 100% 的流量遷移到 GraphQL。
注意事項
錯誤診斷：通過 AB 測試，我們可以看到粗粒度的指標，指出潛在的問題，但很難診斷出具體問題。
工具：Replay 測試 - 大規模驗證！
遷移的下一個階段是在一個以 GraphQL 為主的服務器（Video API Service）中重新實現我們現有的 Falcor API。Falcor API 已經成為一個邏輯復雜的單體，積累了十多年的技術債務。因此，我們必須確保重新實現的 Video API 服務器沒有錯誤，并且與已經產品化的 Shim 服務完全相同。
我們開發了一個 Replay 測試工具，以驗證 冪等的 API 是否從 GraphQL Shim 正確遷移到 Video API 服務中。
它是如何工作的？
Replay 測試框架利用 GraphQL 聯合中提供的 @override 指令。該指令告訴 GraphQL 網關將請求路由到一個 GraphQL 服務器而不是另一個。例如，以下是 Shim 服務和 Video 服務定義的兩個 GraphQL 模式：
在第一階段，GraphQL Shim 首先定義了 certificationRating 字段（例如 Rated R 或 PG-13）。在第二階段，我們建立了 VideoService，并定義了帶有 @override 指令的相同 certificationRating 字段。具有 @override 指令的相同字段的存在告知 GraphQL 網關將此字段的解析路由到新的 Video Service，而不是舊的 Shim Service。
Replay 測試工具從 Mantis 中抽樣原始流量。通過這些抽樣事件，該工具可以捕獲來自生產環境的實時請求，并對 GraphQL Shim 和新的 Video API 服務同時運行 相同的 GraphQL 查詢。然后，該工具比較結果并輸出響應負載中的任何差異。
注意：我們不會對個人身份信息進行 Replay 測試。它僅用于 Netflix 用戶界面上的非敏感產品功能。
測試完成后，工程師可以查看以展開的 JSON 節點形式顯示的差異。你可以在逗號左側的括號中看到對照值，而在右側則是實驗值。
優勢
- 對兩種 GraphQL 實現之間的一致性 充滿信心 。
- 在數據由于過于急切的超時而丟失的情況下， 能夠進行調優配置 。
- 測試了需要許多（未知）輸入和難以直觀判斷正確性的 業務邏輯 。
注意事項
- 不應 使用 Replay 測試來測試包含個人身份信息（PII）和非冪等 API，因此有必要有一種機制來防止這種情況發生。
- 手動構建的查詢 只能測試開發人員記得測試的功能。由于遺忘，我們最終會有一些未經測試的字段。
- 正確性 ：正確性的概念也可能令人困惑。例如，對于一個數組來說，空數組更正確還是 null 更正確，或者只是噪音？最終，我們盡可能與現有行為保持一致，因為驗證客戶端錯誤處理的魯棒性很困難。
盡管存在這些缺點， Replay 測試仍然是我們實現大多數冪等查詢的功能正確性的關鍵指標。
工具：Sticky Canary
雖然 Replay 測試驗證了新的 GraphQL API 的功能正確性，但它并不提供性能或業務指標的洞察，例如 用戶交互的整體感知健康狀況。用戶的點擊率是否相同？加載是否及時，以免用戶失去興趣？Replay 測試也不能用于非冪等 API 的驗證。為了增加信心，我們使用了 Netflix 的一種工具，稱為 Sticky Canary。
Sticky Canary 是一種基礎設施實驗，其中在整個實驗期間，客戶分配給金絲雀或基線主機。所有傳入的流量根據設備和配置文件分配給實驗或基線主機，類似于桶哈希。實驗主機部署為分配給實驗的所有客戶提供服務。您可以觀看我們在亞馬遜云科技 Reinvent 的混沌工程演講，了解更多關于 Sticky Canary 的信息。
在我們的 GraphQL API 案例中，我們使用了 Sticky Canary 實驗來 運行兩個 GraphQL 網關實例。基線網關使用現有的模式，將所有流量路由到 GraphQL Shim。 實驗網關使用新的提議模式，將流量路由到最新的 Video API 服務。我們的主要邊緣網關 Zuul根據實驗參數將流量分配給兩個集群之一。
然后，我們收集并分析兩個集群的性能。我們密切監測的一些關鍵績效指標包括：
- 中位數和尾部延遲
- 錯誤率
- 日志
- 資源利用率 - CPU、網絡流量、內存、磁盤
- 設備 QoE（用戶體驗質量）指標
- 流媒體健康度指標
我們從小規模開始，將客戶的分配量控制在一個小時的實驗范圍內。在驗證性能后，我們逐漸擴大范圍。我們增加了客戶分配的百分比，引入了多區域測試，并最終進行了長達 12 小時甚至整天的實驗。在整個過程中進行驗證非常重要，因為 Sticky Canary 會對實際生產流量產生影響，并持續地分配給特定客戶。
經過多次 Sticky Canary 實驗，我們確信第二階段的遷移改進了所有核心指標，可以放心地在全球范圍內推廣 GraphQL。
優勢
Sticky Canary 對于建立對我們新的 GraphQL 服務的信心至關重要。
- 非冪等 API ：這些測試與具有變異或非冪等特性的 API 兼容。
- 業務指標 ：Sticky Canary 驗證了我們在遷移后的核心 Netflix 業務指標的改善。
- 系統性能 ：對延遲和資源使用情況的了解幫助我們理解遷移后擴展配置的變化。
注意事項
- 對客戶造成負面影響 ：Sticky Canary 可能對真實用戶產生影響。在將某些客戶持續路由到新服務之前，我們需要對新服務有足夠的信心。這在一定程度上通過實時影響檢測得到緩解，該檢測將自動取消實驗。
- 短暫的 ：Sticky Canary 適用于短暫的實驗。對于長期的測試，應使用全面的 AB 測試。
總 結
技術不斷變化，作為工程師，我們在職業生涯中的大部分時間都在進行遷移。問題不在于我們是否進行遷移，而在于我們是否能夠安全、無停機時間地及時進行遷移。
在 Netflix，我們開發了一些工具，確保對每個特定的測試用例進行遷移的信心。我們介紹了 AB 測試、Replay 測試和 Sticky Canary這三個用于 GraphQL 遷移的工具。
作者介紹：
Jennifer Shin、Tejas Shikhare、Will Emmanuel均為 Netflix 高級軟件工程師。
原文鏈接：
https://netflixtechblog.com/migrating-netflix-to-graphql-safely-8e1e4d4f1e72
