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/"