Netflix 是如何管理 2.38 億會員的-魔扣目錄

作者 | Surabhi Diwan

譯者 | 明知山

策劃 | Tina

她首先介紹了 Netflix 在十年前做出的一些定價和技術選擇，那是在她任職 Netflix 之前。然后，她轉到會員歷史記錄的用例研究，這是第二個持久存儲，可以知道任何一個人的訂閱所做的任意細粒度的變更。

“我相信你們大多數人都是 Netflix 的會員。如果不是的話，我將會在深入討論這個問題時向你們展示如何注冊。最后，我將嘗試回答一個問題：訂閱生態系統的演變是怎樣的？它有 2.38 億訂閱者。真的，這個過程會是怎樣的？如果你要再增加 500 萬訂閱者會是什么樣子？如果你要再增加 100 萬呢？”

會員系統工程

會員團隊對會員系統的主要關注點在于 Netflix 的注冊和流媒體這一關鍵路徑。他們負責一系列不同的微服務，而在會員這一塊總有幾十個。他們的中間層服務確保用戶可以無間斷訪問，承若四個 9 的可用性，直接影響著注冊流程和流媒體體驗。

這些服務處理大量的流量，根據具體的用例，例如訂閱或定價，可以擴展到每秒處理數百萬個請求。會員團隊討論了他們的技術決策，利用現成的技術來實現可伸縮性和可靠性。他們作為全球會員數據的權威來源，為 Netflix 的內外部下游分析提供了便利。簡言之，他們以精確的方式應對規?；膹碗s的分布式挑戰。

此外，會員團隊還負責管理 Netflix 的計劃和定價目錄，盡管它非常簡單——基本會員、標準會員、高級會員——但在用戶體驗中起著至關重要的作用。他們優先考慮訂閱詳情的準確性，確保正確的選擇計劃、賬單國家和支付狀態，確保服務質量和會員滿意度。

他們管理著整個會員生命周期——注冊、合作伙伴渠道整合、計劃變更、續訂和賬戶關閉。他們的職責包括處理支付問題（包括賬戶保持和取消）以及在整個會員過程中適當管理客戶數據來確保數據隱私合規性。

會員何時使用我們的流程？

這是我的團隊所涉及的流程。我想，作為最終用戶，如果你現在打開 Netflix 應用，你會關注這些東西。

流程突出了關鍵的用戶交互，例如加入成為會員和播放按鈕，這些按鈕將觸發由 Netflix 會員工程團隊管理的后端流程。流程圖畫出了在用戶開始觀看流媒體之前確保無縫會員體驗的各種服務。播放按鈕直接與會員系統交互，根據用戶選擇的計劃確定服務質量。由于每天會啟動數十億次的流媒體，這種交互產生了最高的流量。此外，賬戶頁面上的用戶操作，例如計劃變更或管理其他會員，也由會員服務提供支持。合作伙伴注冊，例如 Xfinity 的激活，也由會員團隊的后端服務負責編排。

我們是如何做到的？

我認為這是謎題的核心：確定我們做什么。這確實是我們如何做到的。有點難以解釋。

會員團隊管理著會員計劃和定價目錄，在全球范圍內存儲和管理計劃，在不同地區有不同的變化。這個服務還需要管理基于特定位置的產品規則。他們利用兩個 CockroachDB 數據庫支持計劃定價和代碼兌換，特別是在送禮的高峰期。會員定價服務為會員行為提供支持，例如計劃變更和添加額外的會員。

合作伙伴互動由專門的微服務負責處理，這些微服務負責捆綁包的激活和注冊，包括與平臺（如蘋果的應用商店）集成實現訂閱注冊。會員數據存儲在 Cassandra 數據庫中，為超過 2.38 億活躍會員的訂閱服務和歷史跟蹤提供支持。

會員團隊的關注點不僅限于當前的會員，還包括之前的會員和會員的重新加入。他們通過會員狀態和會員維持服務來管理會員狀態，確保使用 Casspactor 和 Apache Spark 等工具進行大數據處理的數據庫之間的平穩運行。這些數據，例如消息和分析，對于下游的消費者獲得有關注冊和收入預測的見解來說至關重要。

注冊流程

當用戶開始 Netflix 的旅程時，他們就會遇到由會員系統驅動的選擇計劃選項，這個系統每秒處理數百萬個請求。由于貨幣、定價和計劃選項存在地理上的差異，正確呈現這個頁面就變得至關重要。會員團隊管理著這些規則，綠色方框代表會員服務的職責，白色方框代表與姊妹團隊的協作。

這個過程從選擇計劃開始。應用程序從會員計劃和定價服務（由 CockroachDB 提供支持）查詢所選的計劃，獲取計劃的定價細節。確認后，點擊“開始會員”，這將觸發會員狀態和歷史服務中的操作，更新相關信息（如計劃、價格級別和國家）。標志會員激活的事件被發送出去，觸發歡迎電子郵件的消息管道，并通知下游團隊進行分析。盡管這個解釋很簡單，但這個過程在分布式系統中大規模發生，需要強大的錯誤處理機制。

會員團隊的技術足跡

Netflix 運行在一個分布式系統架構上，針對高 RPS（每秒讀請求）進行了優化。他們使用 gRPC 進行 HTTP 層通信。他們的主要編程語言是 JAVA，并正在過渡到使用 Kotlin 編寫應用程序，所有這些都與 Spring Boot 結合在一起。Kafka 在消息傳遞和與其他團隊的通信接口中發揮重要作用，例如消息傳遞和下游分析。此外，Netflix 還在大數據方面使用了 Spark 和 Flink 進行離線對賬任務，我們將在稍后更詳細地探討。

運維和監控的技術選擇

除了編碼和生產環境部署之外，Netflix 會員工程團隊還負責值班，及時解決關鍵故障。他們使用輕量級事務，并嘗試通過使用像 Cassandra 這樣的工具確保在線系統的數據一致性。由 Spark 和 Kafka 提供支持的對賬作業確保了會員記錄系統之間的一致性，例如訂閱和會員歷史數據庫。這種準確性延伸到外部系統，保持整個生態系統的一致狀態。數據警報和修復作業負責監控和糾正不一致的地方，確保每個記錄都反映最新的信息。

在可觀察性方面，日志記錄、儀表盤和分布式跟蹤有助于快速檢測和解決錯誤，這在 Netflix 龐大的微服務生態系統中扮演著至關重要的角色。生產警報跟蹤操作指標，確保最佳的服務水平。操作數據還為機器學習模型提供動力，用于增強異常檢測和自動問題解決，保持會員的無間斷流媒體體驗。

用例研究

到目前為止，我們已經確定了 Netflix 會員工程團隊的地位、架構和核心運營流程。深入研究潛在的可改進領域和未來需要做好的準備至關重要。將系統設計比作國際象棋，要掌握它就需要理解規則和策略，并分析過去的走法以便做出改進。

從過去中學習——Netflix 定價的技術決策

十年前，Netflix 的定價架構非常簡單，只負責一些計劃和基本功能。最開始，一個輕量級的內存庫就可以滿足這些需求。然而，隨著 Netflix 在全球范圍內的擴張和業務的多樣化，這個庫的范圍和復雜性不斷增長，成為了跨多個應用程序的關鍵部分。隨著時間的推移，由于規模的增長和依賴關系變得日益復雜，運營方面的挑戰逐漸出現，因此需要過渡到更健壯的架構。

新的架構利用 CockroachDB 進行持久化，并使用 gRPC 服務來處理流量。盡管簡化了設計，但遷移遺留庫是一項涉及到眾多工程團隊和應用程序的工作，需要花費多年時間。這凸顯了面向未來的架構決策和及時解決技術債務以避免付出高昂代價是多么的重要。

雖然新架構是主要的解決方案，但舊庫的遺留組件仍然存在，需要持續進行遷移。這凸顯了在技術過渡期間考慮長期影響和主動處理遺留系統的必要性。

會員歷史

對會員歷史的研究深入探討了其在 Netflix 架構中的演變和關鍵作用。最初，會員歷史是通過應用級事件進行跟蹤的，但對細粒度數據的需求仍然存在。隨著 Netflix 在全球范圍內的擴張，會員數據的復雜性和重要性不斷增長，需要更健壯的解決方案。

新架構采用了變更數據捕獲模式，直接記錄操作數據源的增量變化。這種由 Cassandra 數據庫提供支持的追加日志系統提供了對會員事件的全面跟蹤能力。通過集中處理會員歷史事件流，Netflix 獲得了更好的可觀察性，并能夠在系統間協調數據。

這種架構的好處是多方面地。它支持調試、事件重放以及在數據損壞情況下的無縫對賬。此外，會員歷史讓客戶服務分析變得更加豐富，為下游分析、消息傳遞和會員數據系統提供了數據來源。

盡管實現這種架構花費了多年時間，但其回報卻是巨大的，突顯了在架構創新上投入對取得長期成功的重要性。

為未來做好準備——會員訂閱生態系統的演變

最后，我們來深入探討訂閱生態系統的演變。最初，我們只做了基本的架構選擇，并依靠 gRPC 服務和 Cassandra 數據庫這樣的現成組件來實現可伸縮性。然而，隨著用戶基數的增長，我們遇到了協調數據和容錯性方面的挑戰。

為了解決這些問題，我們實現了一個 Spark Casspactor 來管理備份和協調 Hive 表中的數據，實現更好的審計和自我修復。雖然這提高了調試能力并消除了單點故障，但可伸縮性仍然是一個問題。為了緩解這個問題，我們正在考慮使用 EVCache 作為緩存以實現更快的查找，盡管在一致性方面存在一些折衷。