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