江苏龙网

  1. 主页 > 生活百科 > >

Netflix 是如何管理 2.38 亿会员的( 二 )

Netflix


会员团队的技术足迹
Netflix 运行在一个分布式系统架构上，针对高 RPS（每秒读请求）进行了优化 。他们使用 gRPC 进行 HTTP 层通信 。他们的主要编程语言是 JAVA，并正在过渡到使用 Kotlin 编写应用程序，所有这些都与 Spring Boot 结合在一起 。Kafka 在消息传递和与其他团队的通信接口中发挥重要作用，例如消息传递和下游分析 。此外，Netflix 还在大数据方面使用了 Spark 和 Flink 进行离线对账任务，我们将在稍后更详细地探讨 。
运维和监控的技术选择
除了编码和生产环境部署之外，Netflix 会员工程团队还负责值班，及时解决关键故障 。他们使用轻量级事务，并尝试通过使用像 Cassandra 这样的工具确保在线系统的数据一致性 。由 Spark 和 Kafka 提供支持的对账作业确保了会员记录系统之间的一致性，例如订阅和会员历史数据库 。这种准确性延伸到外部系统 ， 保持整个生态系统的一致状态 。数据警报和修复作业负责监控和纠正不一致的地方，确保每个记录都反映最新的信息 。
在可观察性方面，日志记录、仪表盘和分布式跟踪有助于快速检测和解决错误，这在 Netflix 庞大的微服务生态系统中扮演着至关重要的角色 。生产警报跟踪操作指标，确保最佳的服务水平 。操作数据还为机器学习模型提供动力，用于增强异常检测和自动问题解决，保持会员的无间断流媒体体验 。
用例研究
到目前为止，我们已经确定了 Netflix 会员工程团队的地位、架构和核心运营流程 。深入研究潜在的可改进领域和未来需要做好的准备至关重要 。将系统设计比作国际象棋 ， 要掌握它就需要理解规则和策略，并分析过去的走法以便做出改进 。
从过去中学习——Netflix 定价的技术决策
十年前，Netflix 的定价架构非常简单 ， 只负责一些计划和基本功能 。最开始，一个轻量级的内存库就可以满足这些需求 。然而，随着 Netflix 在全球范围内的扩张和业务的多样化 ， 这个库的范围和复杂性不断增长，成为了跨多个应用程序的关键部分 。随着时间的推移，由于规模的增长和依赖关系变得日益复杂，运营方面的挑战逐渐出现，因此需要过渡到更健壮的架构 。
新的架构利用 CockroachDB 进行持久化，并使用 gRPC 服务来处理流量 。尽管简化了设计 ， 但迁移遗留库是一项涉及到众多工程团队和应用程序的工作，需要花费多年时间 。这凸显了面向未来的架构决策和及时解决技术债务以避免付出高昂代价是多么的重要 。

Netflix 是如何管理 2.38 亿会员的

文章插图
虽然新架构是主要的解决方案，但旧库的遗留组件仍然存在 ， 需要持续进行迁移 。这凸显了在技术过渡期间考虑长期影响和主动处理遗留系统的必要性 。
会员历史
对会员历史的研究深入探讨了其在 Netflix 架构中的演变和关键作用 。最初，会员历史是通过应用级事件进行跟踪的，但对细粒度数据的需求仍然存在 。随着 Netflix 在全球范围内的扩张，会员数据的复杂性和重要性不断增长，需要更健壮的解决方案 。
新架构采用了变更数据捕获模式 ， 直接记录操作数据源的增量变化 。这种由 Cassandra 数据库提供支持的追加日志系统提供了对会员事件的全面跟踪能力 。通过集中处理会员历史事件流，Netflix 获得了更好的可观察性，并能够在系统间协调数据 。
这种架构的好处是多方面地 。它支持调试、事件重放以及在数据损坏情况下的无缝对账 。此外，会员历史让客户服务分析变得更加丰富，为下游分析、消息传递和会员数据系统提供了数据来源 。
尽管实现这种架构花费了多年时间，但其回报却是巨大的，突显了在架构创新上投入对取得长期成功的重要性 。
为未来做好准备——会员订阅生态系统的演变
最后，我们来深入探讨订阅生态系统的演变 。最初，我们只做了基本的架构选择，并依靠 gRPC 服务和 Cassandra 数据库这样的现成组件来实现可伸缩性 。然而 ， 随着用户基数的增长，我们遇到了协调数据和容错性方面的挑战 。
为了解决这些问题，我们实现了一个 Spark Casspactor 来管理备份和协调 Hive 表中的数据，实现更好的审计和自我修复 。虽然这提高了调试能力并消除了单点故障，但可伸缩性仍然是一个问题 。为了缓解这个问题，我们正在考虑使用 EVCache 作为缓存以实现更快的查找，尽管在一致性方面存在一些折衷 。


推荐阅读


上一篇：耗资2.5亿，甄子丹换成张学友，我断言：谢霆锋新片暑期档要炸了

下一篇：移动版 Outlook 解锁新技能，可验证登录 OneDrive 等微软服务