Netflix 系统架构(上）

Netflix 是全球最大的在线视频网站之一，它是怎么设计的呢？这篇文章介绍了 Netflix 系统架构的设计方案。原文：Netflix System Architecture^[1]

我们来讨论一下如何设计 Netflix。

相信每个人都会通过某些网站或应用在线追剧或者看电影，而 Netflix 是我最喜欢的在线视频网站，不过今天我不推荐任何电影，相反，我想展示的是 Netflix 背后令人惊艳的系统逻辑。

功能性需求

1. 创建帐户、登录、删除帐户
   
2. 订阅或取消订阅不同的计划
   
3. 允许用户拥有和处理多个帐户
   
4. 允许用户观看视频
   
5. 允许用户下载视频并离线观看
   
6. 允许用户通过视频标题搜索和发现视频
   
7. Netflix 制作人可以从后台上传视频并在平台上展示
   
8. 平台可以显示趋势、最受欢迎的视频和分类，以方便用户选择
   
9. 可以选择不同语言的字幕，这样用户即使听不懂这些语言，也可以观看视频
   
10. 视频分组（剧集、娱乐节目、电影，单独处理每个视频）
    
11. 根据用户行为进行分析，为用户推荐类似的视频
    
12. 在同一账号下的不同设备之间进行同步，用户可以使用不同的设备继续观看同一视频而无需重播
    
13. 支持全天候（24/7）回放
    
14. 支持回退

非功能性需求

1. 用户可以观看实时视频流，没有任何卡顿或延迟问题
   
2. 系统是高度可靠的
   
3. 高可用
   
4. 可扩展
   
5. 视频数据持久化且易于访问
   

容量预估

我们可以基于一些数学计算来估计所需的带宽和存储空间。

假设

1. 日活用户总数 = 1 亿
   
2. 日活峰值用户：1 亿 * 3 = 3 亿
   
3. 3 个月最大日活峰值用户：3 亿 * 2 = 6 亿
   
4. 每个用户每天平均观看的视频数 = 5
   
5. 视频平均大小 = 500 MB
   
6. 后台平均每天上传的视频数 = 1000
   
7. 每天观看的总视频数 = 1 亿*5 = 5 亿
   
8. 每天观看的总视频峰值 = 15 亿
   
9. 每天观看的最大视频峰值 = 30 亿
   
10. 每天总出口流量 = 5 亿* 500 MB = 250 PB (Peta Byte)
    
11. 出口带宽 = 29.1 GB/秒
    
12. 每天上传总入口流量 = 1000 * 500MB = 500 GB
    
13. 入口带宽 = 5.8 MB/秒
    
14. 5 年所需的总存储空间 = 500 GB * 5 * 365 = 912.5 TB（请注意，Netflix 会为每个视频准备多种格式和分辨率的版本，可针对不同类型设备进行优化，所以存储空间将超过 912.5 TB）。
    

系统组件

系统组件详细设计

1. 客户端应用

• 手机（iOS，Android，华为，等等）
  
• 平板（iPad，Android，Windows）
  
• 电视
  
• 电脑
  

基于 React.js 实现的前端可以拥有较好的加载/启动速度、持久性/模块化和运行时性能。

2. 后端

Netflix 从 2011 年开始实施微服务架构，完全基于云来管理工作负载。通过小型、可管理的 API 组件支持并处理来自应用程序和网站的请求，微服务内部通过请求和获取数据而相互依赖。后端技术栈包括了 Java, MySQL, Gluster, Apache Tomcat, Chukwa, Cassandra, KAFKA 和 Hadoop。后端系统不单单需要处理流媒体视频，还需要处理其他所有事情，比方说数据处理、加载新内容、网络流量管理、全球资源分发等。Netflix 目前部署在 AWS 之上。

数据处理涉及点击视频后发生的所有事件，系统需要在几纳秒的时间内处理完视频并将其传输给用户。整个系统每天大约需要处理 6000 亿个事件，产生 1.5PB 的数据，在高峰期（傍晚和夜间）每秒大约需要处理 800 万个事件。这些事件包括 UI 活动、视频查看活动、日志错误、故障排除、诊断事件、处理事件和性能事件等。所有这些事件都是通过 Kafka 和 Apache Chukwe 完成的。

Kafka 和 Apache Chukwe

• 从系统的不同部分获取产生的数据。
  
• Apache Chukwe 是一个开源数据收集系统，用于从分布式系统中收集日志或事件。它建立在 HDFS 和 Map-reduce 框架之上，具有 Hadoop 的可伸缩性和健壮性特性。此外，它还包含许多功能强大、灵活的工具箱，用于显示、监控和分析结果。Chukwe 从系统的不同部分收集事件，并提供仪表盘帮助我们进行事件的查看、监控和分析。Chukwe 以 Hadoop 文件序列格式（S3）写入事件，大数据团队可以处理这些 S3 Hadoop 文件，并以 Parque 格式将数据写入 Hive。这个过程被称为批处理，基本上以每小时或每天的频率扫描整个数据。为了将在线事件上传到 EMR/S3, Chukwa 还向 Kafka（实时数据处理的入口）提供流量。Kafka 负责将数据从前端 Kafka 注入到不同的后端: S3, Elasticsearch 和下游 Kafka，消息的路由可以通过 Apache Samja 框架完成。通过 Chukwe 发送的流量既可以是完整的流也可以是过滤过的流，所以有时候你可能需要对 Kafka 流量进行进一步过滤，这就是我们需要考虑将流量从一个 Kafka topic 路由到另一个 Kafka topic 的原因。
  

Elastic Search

• Netflix 目前有大约 150 个 Elastic Search 集群，其实例分布在 3500 个主机上。
  
• Netflix 通过 Elastic Search 来实现数据的可视化、客户支持以及系统中的错误检测。例如，如果客户无法播放视频，那么客户服务主管将利用 Elastic Search 来解决问题。回放团队会去 Elastic Search 搜索该用户，试图找到为什么视频不能在用户设备上播放的原因。他们可以了解特定用户所发生的所有信息和事件，知道是什么导致了视频流出错。系统管理员还可以基于 Elastic Search 跟踪某些信息，比如跟踪资源使用情况、检测注册或登录问题等。
  

后端服务

• 用户和认证服务（主要负责用户认证和配置文件）。数据存储在关系型数据库中，如 MySQL 或 PostgreSQL。
  
• 订阅管理服务（管理用户的订阅）。由于该服务处理的数据本质上是高度事务性的，因此 RDBMS 是一个合适的选择。
  
• 视频服务（向终端用户提供视频）。这个服务将视频元数据存储在 RDBMS 中，比如 MySQL 或 PostgreSQL。为了获得更快的响应时间，该服务将使用 Redis 或 Memcached 这样的内存缓存来实现绕写（write-around）缓存。
  
• 转码服务（检查上传视频的质量，用不同的编解码器压缩视频，创建不同分辨率版本）。一旦视频被上传到 Transcoder 服务，它将把视频上传到内部分布式存储，比如 S3，并向数据库添加条目。Kafka 或 RabbitMQ 在队列中处理消息，后端工作组件收到队列的消息，内部 S3 下载视频，并将其转码为不同的格式。转码完成后，后端工作组件将视频上传到外部 S3，并将数据库中的视频状态更新为 active，供终端用户查看。后端工作组件还会在支持全文搜索的搜索数据库中添加视频元数据条目，这样终端用户就能够使用标题或摘要搜索视频。外部 S3 存储的视频也将通过 CDN 缓存，以减少延迟，提高播放性能。
  
• 全球搜索服务（允许终端用户使用元数据，如标题、摘要等搜索视频）。元数据存储在 Elastic Search 数据库中，因此可以基于 Elasticsearch 或 Solr 支持全文搜索，用户可以根据标题搜索电影、剧集或与视频相关的任何元数据。该服务还可以根据最近观看、评论、推荐和流行程度对结果进行排名，以获得更好的用户体验。此外，Elastic Search 可以在失败的情况下跟踪用户事件，客户服务团队可以使用 Elastic Search 来解决问题。
  

3. 云

• Netflix 将其 IT 基础设施迁移到公共云上。使用的云服务是 AWS 和 Open connect (Netflix 的定制 CDN)。这两种云服务并行工作，用于视频处理和向终端用户分发内容。
  

4. CDN

一个全球分布的服务器网络集群。当我们播放视频的时候，设备上显示的视频将从最近的 CDN 服务器获取，从而极大降低响应时间。

• CDN 在多个地方复制内容，这样视频可以更贴近用户，传输距离更短。
  
• CDN 机器大量使用缓存，所以即使没有从服务器上找到视频，也可以从缓存中获取。
  
• CDN 不会缓存不太受欢迎的视频（比方说每天只有不到 20 次观看量的视频）
  

5. Open connect^[2]

Netflix 的内部定制全球 CDN，负责向全球 Netflix 用户存储和传送电影和电视节目。当我们按下播放按钮，视频就会从全球不同位置的 Open connect 服务器中传输给我们。如果视频已经缓存在 Open connect 服务器上，客户端可以轻松访问到，而如果视频没有被缓存，Netflix 必须从 AWS 的 S3 存储中获取并处理该视频，然后 Open connect 才可以将该视频流推送到客户端应用程序。

6. 缓存

Redis 和 Memcached 以键值对的方式缓存数据库中的数据，可以有效减少对数据库的访问。客户端通过服务器访问数据库之前，系统会检查缓存中是否有数据，如果有，就可以绕过数据库访问。但是，如果数据不在缓存中，必须访问数据库并获取数据，并在缓存中填充相同的数据。因此，随后的请求就不需要访问数据库了。这种缓存策略称为绕写（write-around）缓存。我们使用最近最少使用（LRU）策略作为缓存数据的驱逐策略，最早获取的缓存将会被丢弃。

• EV 缓存实际上是 Memcached 的包装器
  

Netflix 在 AWS EC2 上部署了很多集群，这些集群包含有很多 Memcached 节点以及缓存客户端。数据在同一个分区的集群中共享，多个缓存副本存储在分片节点中。每次当客户端写入数据时，所有集群中的所有节点都会被更新，但当读取数据时，读取操作只会被发送到最近的集群及其节点上，如果某个节点不可用，则从另一个可用节点读取。这种方法提高了性能、可用性和可靠性。

7. 可扩展性

• 水平扩展——在负载均衡器后面增加更多的应用服务器，以增加服务的容量。
  
• 数据库备份——关系数据库配置为主从关系，写操作发生在主数据库上，从从数据库读取数据。读操作不会因为写操作而被锁住，因此可以提高读查询的性能。当数据写入主数据库并复制到从数据库时，会有轻微的复制延迟（几毫秒）。
  
• 数据库分片——将数据分布到多个服务器上，以便高效的进行读写操作。比方说，我们可以使用 video_id 对视频元数据数据库进行分片，哈希函数把每个 video_id 随机映射到一个服务器上，从而存储对应的视频元数据。
  
• 缓存分片——将缓存分发到多个服务器上。Redis 支持跨多个实例划分数据，为数据分布使用一致的哈希算法确保在一个实例消失时保持负载均匀分布。
  
• 搜索数据库分片——Elasticsearch 原生支持分片和备份。通过在多个分片上并行运行分片，有助于改进查询运行时。
  

8. 安全

• HTTPS——通过 HTTPS 加密客户端和服务器之间的通信，确保中间没有人能够看到数据（特别是密码）。
  
• 身份验证——每个 API 请求必须完成登录验证，通过检查授权 HTTP 报头中 auth_token 的有效性来进行身份验证，确保请求是合法的。
  

9. 弹性

• 备份——通过主从部署备份数据库。如果一个节点宕机，其他节点将按预期提供服务并继续运行。
  
• 队列——在处理上传的视频时使用。
  

10. 负载均衡

• 一个负载均衡器后面有多个服务器，包括冗余资源。负载均衡器将持续对其背后的服务器进行健康检查，如果发现任意一个服务器停止工作，负载均衡器将停止向它转发流量，并将其从集群中移除，从而确保请求不会因为服务器没有响应而失败。
  

负载均衡器负责将流量路由到前端服务。ELB（Elastic load balancing，弹性负载均衡）执行两层负载均衡方案，首先基于区域（zone）进行负载均衡，然后对实例（服务器）进行负载均衡。

• 第一级由基础 DNS 组成，提供基于轮询的负载均衡（Round Robin Balancing）。当请求到达第一个负载均衡器时，它会根据配置选择一个区域（使用轮询机制）。
  
• 第二级是一组负载均衡器实例，执行轮询负载均衡，将请求分发到位于同一区域的多个业务实例中。
  

11. Geo-redundancy

• 在跨多个地理位置的数据中心部署服务的精确副本，一旦某个数据中心无法提供服务，仍然可以由其他数据中心提供服务。
  

12. ZUUL

提供动态路由、监控、弹性和安全性，支持基于查询参数、URL 路径的简单路由。

• Netty 服务器负责处理网络协议、web 服务、连接管理和代理工作。当请求到达 Netty 服务器时，它负责将请求转发到入口过滤器。
  
• 入口过滤器（The inbound filter）负责身份验证、路由或装饰请求。然后将请求转发给端点过滤器。
  
• 端点过滤器（Endpoint filter）用于返回静态响应，或者将请求转发到后端服务。一旦它从后端服务接收到响应，就将请求发送到出口过滤器。
  
• 出口过滤器（Outbound filter）用于压缩内容、计算指标或添加/删除自定义标头。在此之后，响应被发送回 Netty 服务器，然后发送给客户端。
  

优势：

1. 可以创建规则，将流量的不同部分分配到不同的服务器，从而实现对流量的分片。
   
2. 开发人员可以在某些机器上对新部署的集群进行负载测试，可以在这些集群上路由部分现网流量，并检查特定服务器可以承受多少负载。
   
3. 可以用于测试新服务。当我们需要升级服务并希望检查该服务如何处理实时 API 请求时，可以将特定服务部署在一台服务器上，并将部分流量重定向到新服务，以便实时检查该服务状态。
   
4. 可以通过在端点过滤器或防火墙上设置自定义规则来过滤恶意请求。
   

13. Hystrix

在一个复杂的分布式系统中，一个服务器可能依赖于另一个服务器的响应。这些服务器之间的依赖关系可能会造成延迟，如果其中一个服务器在某个时刻不可避免的出现故障，整个系统可能都会停止工作。为了解决这个问题，可以将主机应用程序与这些外部故障隔离开来。Hystrix 库就是为此而设计的，通过添加延迟容忍和容错逻辑，帮助我们控制分布式服务之间的交互。Hystrix 通过隔离服务、远程系统和第三方库之间的访问点来实现这一点。Hystrix 可以帮助我们实现：

• 阻止复杂分布式系统中的级联故障。
  
• 控制由于第三方客户端访问（通常通过网络）依赖项带来的延迟和故障。
  
• 快速失败、快速恢复。
  
• 在可能的情况下，回滚以及优雅降级。
  
• 启用近实时监控、警报和运维控制。
  
• 并发感知的请求缓存，通过请求崩溃实现自动批处理
  

数据库组件

Netflix 使用不同的 DB 来存储不同类型的文件，例如用于不同目的的 SQL 和 NoSQL。

1. MySQL

• 符合 ACID，因此可用于管理影片标题、计费和事务用途。
  
• 在 AWS EC2 上部署 MySQL 来存储数据
  
• MySQL 配置为主主模式，在大型 AWS EC2 实例上使用 InnoDB 引擎构建。
  
• 设置遵循“同步复制协议（Synchronous replication protocol）”。数据复制是同步完成的，表明节点之间存在主主关系，只有当数据由本地和远程节点同步以确保高可用性时，才会认为主节点上的任何写操作已经完成。读查询不是由主节点处理，而是由副本处理，只有写查询是由主数据库处理。在故障转移的情况下，副节点将作为主节点，并将负责处理写操作。