Netflix 系统设计-后端架构

2025-05-24

Netflix 系统设计-后端架构

Unsplash上的封面照片由Alexander Shatov拍摄

Netflix 约占全球互联网带宽流量的 15%,每月向全球几乎所有国家/地区提供超过 60 亿小时的内容。构建一个强大、高度可扩展、可靠且高效的后端系统并非易事,但 Netflix 雄心勃勃的团队已经证明,问题确实存在,亟待解决。

本文根据在线资料分析了 Netflix 的系统架构。第 1 部分简要概述了 Netflix 系统。第 2 部分概述了后端架构,第 3 部分详细介绍了各个系统组件。如需了解现代系统设计的完整指南,您可以尝试学习“面向工程师的现代系统设计”课程。

1.概述

Netflix 在两个云平台 Amazon Web Services 和 Open Connect(Netflix 内容交付网络)上运营。
Netflix 高级系统架构

Netflix 整体系统主要由三个部分组成。

  • Open Connect Appliances(OCA) - Open Connect 是 Netflix 定制的全球内容分发网络 (CDN)。这些 OCA 服务器部署在世界各地的互联网服务提供商 (ISP) 和互联网交换中心 (IXP) 网络中,用于向用户分发 Netflix 内容。

  • 客户端——客户端是指播放 Netflix 视频的任何设备。它包括所有与 Netflix 服务器交互的应用程序。

Netflix 支持多种设备,包括智能电视、Android 和 iOS 平台、游戏机等等。所有这些应用均使用特定平台的代码编写。Netflix 的 Web 应用使用 ReactJS 编写,这受到多种因素的影响,其中包括启动速度、运行时性能和模块化。

  • 后端- 包括数据库、服务器、日志框架、应用程序监控、推荐引擎、后台服务等。当用户加载 Netflix 应用时,所有请求都由后端服务器处理,包括 AWS 登录、推荐、主页、用户历史记录、计费和客户支持。这些后端服务包括(AWS EC2 实例、AWS S3、AWS DynamoDB、Cassandra、Hadoop、Kafka 等)。

2.后端架构

Netflix 是微服务架构的主要推动者之一。其系统的每个组件都是由松散耦合、相互协作的服务组成的集合。微服务架构能够快速、频繁且可靠地交付大型复杂应用程序。下图是后端架构的概览。
后端

后端架构
  1. 客户端向在 AWS 上运行的后端发送播放请求。Netflix 使用 Amazon 的弹性负载均衡器 (ELB) 服务将流量路由到其服务。
  2. AWS ELB 会将该请求转发到 API 网关服务。Netflix 使用 Zuul 作为其 API 网关,该网关旨在实现动态路由、流量监控、安全性以及云部署边缘故障的恢复能力。
  3. 应用程序 API 组件是 Netflix 运营背后的核心业务逻辑。多种类型的 API 对应不同的用户活动,例如注册 API 和用于检索视频推荐的发现/推荐 API。在本场景中,来自 API 网关服务的转发请求由 Play API 处理。
  4. Play API 将调用一个微服务或一系列微服务来满足请求。
  5. 微服务大多是无状态的小程序,成千上万个这样的服务可以相互通信。
  6. 在此过程中,微服务可以保存数据或从数据存储中获取数据。
  7. 微服务可以发送事件来跟踪用户活动或其他数据到流处理管道,以便实时处理个性化推荐或批量处理商业智能任务。
  8. 流处理管道数据可以持久保存到其他数据存储,例如 AWS S3、Hadoop HDFS、Cassandra 等。

3. 后端组件

打开连接

Open Connect 处理您点击视频播放后发生的所有事情。该系统负责将视频流式传输到您的设备。下图展示了播放过程的工作原理。
播放黑色过程

打开连接设计图像
  1. OCA 对 AWS 实例进行 ping 操作以报告其健康状况、所了解的路线以及其上拥有的文件。
  2. 客户端设备上的用户请求从 AWS 中的 Netflix 应用程序播放标题(电视节目或电影)。
  3. Netflix 播放服务会检查用户的授权、许可和执照,然后根据当前网络速度和客户端分辨率选择向客户端提供哪些文件。
  4. 转向服务选择应提供文件的 OCA,为这些 OCA 生成 URL,然后将它们交还给播放服务。
  5. 播放服务将OCA的URL交给客户端,客户端向该OCA请求视频文件。

Zuul2-API网关

Netflix 使用 Amazon 的弹性负载均衡器 (ELB) 服务将流量路由到各个服务。ELB 的设置方式是首先跨可用区进行负载均衡,然后再跨实例进行负载均衡。
AmazonELB

Amazon 弹性负载均衡器

该负载均衡器将请求路由到 API 网关服务;Netflix 使用 Zuul 作为其 API 网关;它处理所有请求并执行微服务应用程序的动态路由。它充当所有请求的前门。

例如,/api/products 映射到产品服务,/api/user 映射到用户服务。Zuul 服务器会动态地将请求路由到相应的后端应用程序。Zuul 提供了一系列不同类型的过滤器,使它们能够快速、灵活地将功能应用于边缘服务。

Netflix 的云网关团队运行并运营着 80 多个 Zuul 2 集群,向大约 100 个(并且还在不断增长)后端服务集群发送流量,每秒的请求量超过 100 万个。

开源-zuul-2
zuul2

Zuul 架构

过滤器前后的 Netty 处理程序主要负责处理网络协议、Web 服务器、连接管理和代理工作。将这些内部工作抽象出来后,过滤器便承担了所有繁重的工作。

  • 入站过滤器在代理请求之前运行,可用于身份验证、路由或装饰请求。
  • 端点过滤器可以返回静态响应,也可以将请求代理到后端服务。出站过滤器在响应返回后运行,可用于添加或删除自定义标头或指标。

Zuul 2 Api 网关将请求转发到适当的应用程序 API。

应用程序 API

目前,应用程序 API 分为三类:注册 API - 用于非会员请求,例如注册、计费、免费试用等;发现 API - 用于搜索、推荐请求;播放 API - 用于流媒体、查看许可请求等。例如,当用户单击注册时,Zuul 会将请求路由到注册 API。

以已订阅用户为例。假设用户点击播放《浴血黑帮》最新一集,请求将被路由到播放 API。该 API 会调用后台的多个微服务。其中一些调用可以并行执行,因为它们彼此不依赖。其他调用则必须按特定顺序排序。API 包含所有必要的逻辑,用于对调用进行排序和并行化。反过来,设备无需了解客户点击“播放”时后台进行的任何编排。
Api archi

Netflix API 架构

注册请求映射到注册后端服务,播放请求(有一些例外)仅映射到播放后端服务,同样,发现 API 映射到发现服务。

Hystrix——分布式API服务管理

野猪
野猪

Hystrix架构

在任何分布式环境中(存​​在大量依赖关系),不可避免的是,众多服务依赖项中的一些会失败。随着越来越多的服务上线,监控所有服务的健康状况和状态可能变得难以管理,有些服务可能会被停用或直接崩溃。Hystrix 提供了一个用户友好的仪表板,可以提供帮助。Hystrix用于通过添加一些延迟容忍和容错逻辑来控制这些分布式服务之间的交互。

以 Netflix 为例:他们有一个微服务,可以向用户提供定制的电影列表。如果该服务发生故障,他们会将流量重新路由到另一个原生微服务,以规避故障,该微服务只返回排名前 10 的合家欢电影。因此,他们拥有一个安全的故障转移机制,这就是第一次熔断的经典示例。

笔记

Netflix Hystrix 已停止积极开发,目前处于维护模式。一些内部项目目前正在使用 Resilience4j 进行构建。

https://github.com/resilience4j/resilience4j

Titus-容器管理

Titus
Titus 是一个容器管理平台,提供可扩展、可靠的容器执行以及与 Amazon AWS 的云原生集成。
提图斯·阿奇

泰特斯建筑

它是一个基于 Apache Mesos 的框架,而 Mesos 是一个集群管理系统,负责在多台机器之间协调可用资源。Titus
在 Netflix 的生产环境中运行,管理着数千个 AWS EC2 实例,每天为批处理和服务工作负载启动数十万个容器。可以将其视为 Netflix 版的 Kubernetes。

Titus 每周运行约 300 万个集装箱。

数据存储

EVCache

缓存的主要目的是通过减少访问底层较慢存储层的需求来提高数据检索性能。为了兼顾容量和速度,缓存通常会暂时存储一部分数据
。EVCache

缓存的两个用例是:

  • 提供对经常存储的数据的快速访问。
  • 提供对计算(记忆)数据的快速访问。Netflix 的微服务依靠缓存来快速、可靠地访问多种类型的数据,例如会员的观看历史记录、评分和个性化推荐。
    EVCache
    EVCache 图

EVCache 是一个基于 Memcached 和 spymemcached 的缓存解决方案,主要用于在 AWS EC2 基础架构上缓存常用数据。EVCache
是以下内容的缩写:

  • 短暂的——数据的存储时间很短,由其 TTL(生存时间)指定。
  • 易失性——数据可能随时消失(被驱逐)。
  • 缓存——内存中的键值存储。

SSD 缓存

传统上,缓存是在 RAM 上完成的。在 RAM 上存储大量数据的成本很高,因此 Netflix 决定将部分缓存数据迁移到 SSD。

基于 SSD 的现代磁盘技术能够快速访问数据,但成本远低于 RAM。在 SSD 上存储 1 TB 数据的成本远低于在 RAM 上存储相同数量的数据。

应用程序数据缓存的演变

MySQL

Netflix 使用 AWS EC2 上的 MYSQL 实例作为其计费基础设施。计费基础设施负责管理 Netflix 会员的计费状态。这包括跟踪未结/已付款的计费周期、会员账户的信用额度、管理会员的付款状态、发起扣款请求以及会员的付款截止日期。

支付处理器需要 RDBMS 的 ACID 功能来处理收费交易。
Netflix 数据存储

Netflix 数据存储

阿帕奇卡桑德拉

Cassandra 是一个免费的开源分布式宽列存储系统。该 NoSQL 数据库旨在跨多台商用服务器处理海量数据,提供高可用性,且无单点故障。

Netflix 使用 Cassandra 是因为它的可扩展性、缺乏单点故障以及跨区域部署。”实际上,单个全球 Cassandra 集群可以同时为应用程序提供服务,并跨多个地理位置异步复制数据。

Netflix 在其 Cassandra DB 实例中存储所有类型的数据,包括所有用户收集的事件指标。

随着用户数据的增加,需要一种更有效的方式来管理数据存储。Netflix 重新设计了数据存储架构,主要考虑了两个目标:

  • 更小的存储占用空间。
  • 随着每个成员的观看次数增加,读/写性能保持一致。

解决大数据问题的方法是压缩旧行。数据分为两种类型:

  • 实时观看历史记录 (LiveVH):少量近期观看记录,且更新频繁。数据以未压缩形式存储。
  • 压缩观看历史记录 (CompressedVH):大量较旧的观看记录,很少更新。数据经过压缩以减少存储空间。压缩观看历史记录按行键存储在单个列中。
    压缩VH
    压缩观看历史记录

流处理管道

您知道 Netflix 会为您量身定制电影封面吗?您可能会惊讶地发现,每部视频的图片都是为您精心挑选的。每个人看到的图片都不一样。Netflix 会根据您了解的数据(例如您的观看历史和兴趣),尝试选择能够凸显视频最相关元素的封面。
陌生事物

流处理数据管道已成为 Netflix 业务分析和个性化推荐任务的数据主干。它负责近乎实时地生成、收集、处理、聚合所有微服务事件并将其移动到其他数据处理器。

流数据是由数千个数据源持续生成的数据,这些数据源通常会同时发送小规模(以千字节为单位)的数据记录。流数据涵盖各种数据,例如客户使用您的移动或 Web 应用程序生成的日志文件、电子商务购买记录、游戏内玩家活动、来自社交网络、金融交易大厅或地理空间服务的信息,以及来自数据中心内连接设备或仪器的遥测数据。

AWS-什么是流数据?

这些数据需要按记录逐条或在滑动时间窗口内按顺序和增量进行处理,并用于各种分析,包括关联、聚合、过滤和采样。

通过此类分析获得的信息,企业能够洞察其业务和客户活动的方方面面,例如服务使用情况(用于计量/计费)、服务器活动、网站点击情况以及设备、人员和实物商品的地理位置,从而能够迅速应对突发情况。例如,企业可以通过持续分析社交媒体信息流并根据需要迅速做出响应,来追踪公众对其品牌和产品的情绪变化。

流处理平台每天处理数万亿个事件和数PB的数据。
流媒体

观看历史记录服务会捕获会员播放的所有视频。Beacon 是另一项服务,用于捕获 Netflix 内的所有展示事件和用户活动。观看历史记录和 Beacon 服务收集的所有数据都会发送到 Kafka。

Apache Kafka - 分析流数据

Kafka 是一款开源软件,提供存储、读取和分析流数据的框架。

Netflix 将 Apache Kafka® 作为其事件处理、消息传递和流处理需求的实际标准。Kafka 充当了所有点对点以及整个 Netflix Studio 通信的桥梁。

Netflix 如何使用 Kafka
卡夫卡

Apache Chukwe - 分析流数据

Apache Chukwe 是一个开源数据收集系统,用于从分布式系统收集日志或事件。它基于 HDFS 和 Map-reduce 框架构建,并具备 Hadoop 的可扩展性和稳健性。它包含许多强大而灵活的工具包,用于显示、监控和分析数据。Chukwe 从系统的不同部分收集事件;您可以通过 Chukwe 进行监控和分析,也可以使用仪表板查看事件。Chukwe 将事件写入 Hadoop 文件序列格式 (S3)。

Apache Spark - 分析流数据

Netflix 使用 Apache Spark 和机器学习来推荐电影。Apache Spark 是一个用于大规模数据处理的开源统一分析引擎。

在用户实时请求时,聚合的播放热度(视频播放次数)和观看率(特定视频的播放次数占曝光次数的比例)数据,以及其他显式信号(例如会员的观看历史记录和过往评分)将用于为用户计算个性化内容。下图展示了用于构建用户电影推荐的端到端基础架构。
数据处理器引擎

数据处理引擎

Elastic Search - 错误日志记录和监控

Netflix 使用弹性搜索在系统中实现数据可视化、客户支持和错误检测。

Elasticsearch 是一个基于 Lucene 库的搜索引擎。它提供了一个分布式、支持多租户的全文搜索引擎,并带有 HTTP Web 界面和无模式 JSON 文档。

通过弹性搜索,他们可以轻松监控系统状态并排除错误日志和故障。

结论

本文详细分析了 Netflix 后端架构。为了测试您对 Netflix 系统设计的了解程度,请尝试一下这个关于 Netflix 设计的互动测验。更多信息,请参阅下文中的参考资料。

如果您正在寻找系统设计的详细指南,请查看此系统设计面试准备

关注我这里和我的社交媒体获取更多内容,例如Linkedin . Twitter

参考

  1. 提图斯
  2. 开源 Zuul
  3. 打开连接
  4. Netflix 后端如何运作
  5. Netflix 基于云的微服务架构设计分析
  6. Netflix系统设计
  7. Hystrix 是什么以及为什么使用它
  8. 工程权衡和 Netflix API 重构
  9. 使用 SSD 进行应用程序数据缓存
  10. 应用程序数据缓存从 RAM 到 SSD 的演变
  11. Netflix 计费迁移至 AWS
  12. 优化Netflix API
  13. Netflix 上的热门内容
  14. Netflix 数据管道的演变
  15. Zuul API 网关
  16. CAP定理
  17. 按下播放键后会发生什么
  18. 扩展时间序列数据存储(第一部分)
  19. Netflix 高级系统架构
  20. Netflix 如何使用 Kafka
  21. Netflix 消耗了全球 15% 的互联网带宽
  22. 软件工程师面试中最常见的 14 个系统设计问题
  23. Netflix 系统设计测验
文章来源:https://dev.to/gbengelebs/netflix-system-design-backend-architecture-10i3
PREV
使用 fp-ts 与非功能性代码的互操作性
NEXT
我的 Vim 故事 Vimfiles