写点什么

Netflix 是如何管理 2.38 亿会员的

作者:Surabhi Diwan

  • 2024-04-24
    北京
  • 本文字数:3697 字

    阅读完需:约 12 分钟

大小:1.81M时长:10:33
Netflix是如何管理2.38亿会员的

Netflix 高级软件工程师 Surabhi Diwan在 2023 年旧金山 QCon 大会上发表了题为 管理 Netflix 的 2.38 亿会员 的演讲。她在演讲中分享了 Netflix 的会员团队为满足 Netflix 不断增长的会员需求是如何实现分布式系统的:架构选型、技术决策和运营语义。


她首先介绍了 Netflix 在十年前做出的一些定价和技术选择,那是在她任职 Netflix 之前。然后,她转到会员历史记录的用例研究,这是第二个持久存储,可以知道任何一个人的订阅所做的任意细粒度的变更。


“我相信你们大多数人都是 Netflix 的会员。如果不是的话,我将会在深入讨论这个问题时向你们展示如何注册。最后,我将尝试回答一个问题:订阅生态系统的演变是怎样的?它有 2.38 亿订阅者。真的,这个过程会是怎样的?如果你要再增加 500 万订阅者会是什么样子?如果你要再增加 100 万呢?”


会员系统工程


会员团队对会员系统的主要关注点在于 Netflix 的注册和流媒体这一关键路径。他们负责一系列不同的微服务,而在会员这一块总有几十个。他们的中间层服务确保用户可以无间断访问,承若四个 9 的可用性,直接影响着注册流程和流媒体体验。


这些服务处理大量的流量,根据具体的用例,例如订阅或定价,可以扩展到每秒处理数百万个请求。会员团队讨论了他们的技术决策,利用现成的技术来实现可伸缩性和可靠性。他们作为全球会员数据的权威来源,为 Netflix 的内外部下游分析提供了便利。简言之,他们以精确的方式应对规模化的复杂的分布式挑战。


此外,会员团队还负责管理 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 作为缓存以实现更快的查找,尽管在一致性方面存在一些折衷。



这里的关键教训是没有哪个系统可以无限扩展,不断在创新和架构演进上进行投入是关键,避免遭遇系统限制和意外停机。


总结


从 Netflix 的定价决策中得到的关键教训是,技术选择必须面向未来,并在必要时积极调整或调整。同样,会员历史案例说明了在架构上大胆投入可能带来潜在的巨大回报,勇敢追求重大创新至关重要。


会员订阅的演变是一个持续的过程。这一持续挑战让 Diwan 想起了计算机科学领域的一句名言:


计算机科学领域只有两件难事:缓存失效和命名。


原文链接

https://www.infoq.com/articles/managing-memberships-netflix/

2024-04-24 08:007074

评论

发布
暂无评论
发现更多内容

阿里云前端专家冯军:前端用户体验该如何优化

云布道师

阿里云

JS继承有哪些,你能否手写其中一两种呢?

helloworld1024fd

JavaScript

极狐GitLab与欧拉操作系统完成兼容认证,开源产业自主创新再突破!

openEuler

Linux 开源 操作系统 openEuler 资讯

前端二面手写面试题总结

helloworld1024fd

JavaScript

【双机热备小知识】两台服务器可以做双机热备吗?

行云管家

高可用 双机热备

程序员面试中一面、二面、三面有什么区别?

小小怪下士

Java 程序员 java面试

明天 9 点!Doris Summit 2022 拉开序幕,立即报名年度技术盛会!

SelectDB

数据湖 云原生 实时数仓 湖仓一体 数据库·

一文详解RocketMQ的存储模型

华为云开发者联盟

开发 华为云 企业号 1 月 PK 榜

华为云发布CodeArts TestPlan测试管理平台 守护产品质量之魂

科技热闻

2022 Apache APISIX 年度记忆

API7.ai 技术团队

api 网关 APISIX 年终盘点 apache 社区

TiDB 6.5 LTS 发布 企业级关键能力跃升

Geek_2d6073

DTALK直播预约 | 金融行业嘉宾分享:金融机构数据治理实践路径

袋鼠云数栈

前端高频vue面试题总结

bb_xiaxia1998

Vue

软件测试/测试开发丨iOS 自动化测试踩坑(一): 技术方案、环境配置与落地实践

测试人

ios xcode 软件测试 自动化测试 测试开发

云原生安全系列 4:6个 Kubernetes 安全最佳实践

HummerCloud

Kubernetes 云原生安全

旅游业复苏在即,区块链赋能智慧旅游新体验

旺链科技

区块链 区块链技术 区块链技术应用

2022大厂投资盘点:最大的投资就是减少投资

ToB行业头条

海量数据同步首选 SeaTunnel Zeta 引擎正式发布!

Apache SeaTunnel

大数据 开源 apache 社区 Apache SeaTunnel 数据集成平台

ZooKeeper 避坑实践:SnapCount 设置不合理导致磁盘爆满,服务不可用

阿里巴巴云原生

zookeeper 阿里云 云原生

腾讯前端二面高频手写面试题总结

helloworld1024fd

JavaScript

读 NebulaGraph源码 | 查询语句 LOOKUP 的一生

NebulaGraph

图数据库 源码解读

喜报!SelectDB 携手中航信移动科技有限公司、四川大数据技术服务中心,双双入选大数据“星河(Galaxy)”优秀案例

SelectDB

数据库 大数据 数据湖 云原生 云上架构

高并发环境下构建缓存服务,你需要注意这6点

华为云开发者联盟

高并发 开发 华为云 企业号 1 月 PK 榜

js函数柯里化-面试手写版

helloworld1024fd

JavaScript

ChatGPT的一小步,NLP范式转变的一大步

OneFlow

人工智能 深度学习

OneFlow源码解析:静态图与运行时

OneFlow

人工智能 深度学习

Serverless时代的微服务开发指南:华为云提出七大实践新标准

华为云开发者联盟

微服务 云原生 后端 华为云 企业号 1 月 PK 榜

一线大厂面试官力荐: Spring Security Oauth2.0 认证授权全彩笔记

架构师之道

编程 微服务 架构师

基于云基础设施快速部署 RocketMQ 5.0 集群

Apache RocketMQ

RocketMQ 云原生 消息队列

技术管理 之 跨功能需求管理

码猿外

技术管理 非功能性需求 跨功能性需求

双机热备的优点简单分析-行云管家

行云管家

高可用 双机热备

Netflix是如何管理2.38亿会员的_架构_InfoQ精选文章