Netflix 约占全球互联网带宽流量的 15%，它每月向全球提供超过 60 亿小时的内容。

构建一个强大、高度可扩展、可靠且高效的后端系统是一项不小的工程壮举，但 Netflix 青春蓬勃的团队已经证明已经解决这个问题。

本文提供了从在线资源研究的 Netflix 系统架构的分析。第 1 节将提供 Netflix 系统的简化概述。第 2 节概述了后端架构，第 3 节详细介绍了各个系统组件。

一、概述

Netflix 在两个云中分别运行 Amazon Web Services 和 Open Connect（Netflix CDN）。

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

• Open Connect Appliances (OCA) 

  
  

  Open Connect 是 Netflix 自建的全球内容交付网络 (CDN)。这些 OCA 服务器放置在世界各地的互联网服务提供商 (ISP) 和互联网交换位置 (IXP) 网络中，以便向用户提供 Netflix 内容。

  
  

• 客户端

  
  

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

  
  

  Netflix 支持多种不同设备，包括智能电视、Android、iOS 、游戏机等。所有这些应用程序都是使用特定于平台的代码开发。 例如Netflix Web 应用程序是使用 react编写的，它受几个因素的影响，其中一些因素包括启动速度、运行时性能与模块化。

• 后端

  
  

  这包括数据库、服务器、日志框架、应用程序监控、推荐引擎、后台服务等。当用户加载 Netflix 应用程序时，所有请求都由 AWS 中的后端服务器处理。

  
  

  例如：登录、推荐、主页，用户历史，计费，客户支持。其中一些后端服务包括（AWS EC2 实例、AWS S3、AWS DynamoDB、Cassandra、Hadoop、Kafka 等）。

  
  

二.后端架构

1. 客户端将播放请求发送到在 AWS 上运行的后端。Netflix 使用 Amazon 的 Elastic Load Balancer (ELB) 服务将流量路由到微服务侧。

2. AWS ELB 将该请求转发给 API Gateway 服务。Netflix 使用 Zuul 作为 API 网关，该网关旨在支持动态路由、流量监控和安全性以及云部署边缘计算的故障恢复能力。

3. 应用 API 组件是 Netflix 运营背后的核心业务逻辑。有几种类型的 API 对应于不同用户活动，例如 Signup API、Discovery/Recommendation API 用于检索与视频推荐。其它情况下，由 API Gateway Service 的转发请求由 Play API 处理。

4. Play API 将调用一个微服务或一系列微服务来完成请求。

5. 微服务大多是无状态的小程序，可以有数千个这样的服务相互通信。

6. 在此过程中，微服务可以保存或从数据存储中获取数据。

7. 微服务可以将用于跟踪用户活动，或者将其它数据的事件发送到流处理管道，以实时处理个性化推荐或批处理商业智能任务。

8. 来自流处理管道的数据可以持久保存到其它数据存储中，例如 AWS S3、Hadoop HDFS、Cassandra 等。

三.后端组件

Open Connect

1. OCA 对 AWS 实例执行 ping 操作，然后报告它们的运行状况、它们的路由以及所拥有的文件。

2. 客户端设备上的用户请求从 AWS 中的 Netflix 应用程序播放节目标题（电视节目或者电影）。

3. Netflix Play Service 播放服务会检查用户的授权、许可和权限，然后考虑当前网络速度和客户端分辨率等情况匹配选择为客户端服务的文件。

4. 指导服务选择提供文件的 OCA，为这些 OCA 生成 URL，然后将其交回播放服务。

5. 播放服务将 OCA 的 URL 移交给客户端，客户端从该 OCA 请求视频文件。

Zuul2-API 网关

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

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

Netflix 的 Cloud Gateway 团队运行着 80 多个 Zuul 2 集群，向大约 100 个（并且还在不断增长的）后端服务集群发送流量，相当于每秒超过 100 万个请求。

过滤器前后的 Netty 处理程序负责处理网络协议、Web 服务器、连接管理与代理工作。随着这些内部工作的抽象化，过滤器完成了这些繁重的工作：

• 入站过滤器在代理请求之前运行，用于身份验证、路由或包装请求。

• 节点过滤器用于返回静态响应或将请求代理指给后端服务。

• 出站过滤器在响应返回后运行，可用于添加/删除自定义标头等内容。

• Zuul 2 API 网关将请求转发到相应的应用程序 API。

  
  

  
  

  Application API

  
  

目前，Application API 定义为三类：

• Signup API - 用于非会员请求，例如注册、计费、免费试用等；

• Discovery API - 用于搜索、推荐请求

• Play API - 用于流式传输、查看许可请求等。例如当用户单击注册时，Zuul 会将请求路由到注册 API。

注册请求映射到注册后端服务，播放请求（除了一些例外）仅映射到播放后端服务。与之类似，发现 API 映射到发现服务。

Hystrix - 分布式 API 服务管理

在任何分布式环境（具有大量依赖项）中，不可避免地会有一些服务依赖项出错。

随着越来越多的服务被启动并且一些服务可能会被关闭或崩溃，监视所有服务的运行状况和状态是比较难于管理的。

Hystrix 通过提供用户友好的仪表板来给开发者和运维者提供帮助。Hystrix 库用于通过添加一些允许延迟和容错逻辑来控制这些分布式服务之间的交互。

举 Netflix 的这个例子，它们有一个微服务，可以向用户提供定制的电影列表。如果某个微服务崩溃，它会重新路由流量到另一个提供简单内容的微服务，该微服务只返回前 10 部适合家庭观看的电影。

所以，他们有这个安全的故障转移，用户可以无察觉得继续播放电影，这是一个出现断路的经典例子。

注意：

Netflix Hystrix 现在不再处于活跃开发阶段，目前为维护模式。Netflix团队正在使用resilience4j 构建一些内部项目。其GitHub为：

https://github.com/resilience4j/resilience4j

Titus-容器管理

Titus 是 Apache Mesos 上的一个框架。Apache Mesos 是一个集群管理系统，可以在一组机器上代理可用资源。

Titus 在 Netflix 的生产环境中运行，管理着数千个 AWS EC2 实例，并每天为批处理和服务工作负载启动数十万个容器。

我们可将Titus 视为 Kubernetes 的 Netflix 版本。

值得一提的是：Titus 每周运行大约 300 万个容器。

数据存储与 EVCache

缓存的主要目的是通过减少访问底层较慢存储层的需要来提高数据检索性能。以容量换取速度，缓存通常临时存储数据子集。

EVCache

缓存的两个经典用例是：

• 提供对经常存储的数据的快速访问。

• 提供对计算（内存）数据的快速访问。Netflix 的微服务依靠缓存来快速、可靠地访问多种类型的数据，例如会员的观看历史、评分以及个性化推荐。

  
  

  

  EVCache 架构图

EVCache 是一种基于 memcached 和 spymemcached 的缓存解决方案，主要用于 AWS EC2 基础设施，用于缓存常用数据。

EVCache 是以下技术的缩写：

• 短暂的 - 存储的数据是由其 TTL（生存时间）指定的时间。

• 易失性 - 数据可以随时消失。

• 缓存 - 在内存中以键值（Key/Value）存储

用于缓存的 SSD

传统上，缓存是在内存（RAM）上完成的。你知道，在 RAM 上存储大量数据非常昂贵，因此 Netflix 决定将一些缓存数据移动到 SSD。

基于 SSD 的现代磁盘技术提供了对数据的快速访问，它与 RAM 相比成本要低得多。在 SSD 上存储 1 TB 数据的成本远低于使用 RAM 存储相同数量的数据。

应用数据缓存的演进

MySQL

Netflix 将 MYSQL 的 AWS EC2 实例用于其计费基础设施。计费基础设施负责管理 Netflix 会员的计费状态。包括跟踪未结/已付款的计费周期、会员帐户的信用额度、管理会员的付款状态、发起收费请求以及会员已付款的日期等。

Apache Cassandra

Cassandra 是一个免费和开源的分布式宽列存储 NoSQL 数据库，旨在处理跨许多商品服务器的大量数据，提供高可用性而没有单点故障。

Netflix 使用 Cassandra 的原理是其良好的可扩展性、没有单点故障和跨区域部署。实际上，单个全球 Cassandra 集群可以同时为应用程序提供服务并在多个地理位置异步复制数据。

Netflix 在其 Cassandra 数据库实例中存储各种数据。所有用户收集的指标事件都存储在 Cassandra 上。

随着用户数据的不断增加，需要一种更有效的方式来管理数据存储。Netflix 重新设计的数据存储架构，它有两个主要目标：

• 更小的存储空间。

• 随着每个成员的观看次数增加，要有一致的读/写性能。

大数据问题的解决方案是压缩旧记录。大数据分为两类：

• Live Viewing History (LiveVH)：少量最近的观看记录和经常观看的记录。数据以未压缩的形式存储。

• 压缩观看历史记录 (CompressedVH)：大量较旧的观看记录，很少更新。数据被压缩以减少存储空间。压缩的查看历史记录存储在每个行键的单个字段中。

  

  压缩查看历史记录

流处理管道

大家知道，Netflix 可以为用户提供个性化的电影和相关作品。用户会惊讶地发现为每个视频显示的图片是专门为用户定制的，不是每个人都看到相同的图像。

Netflix 会尝试根据从用户的观看历史和兴趣中了解到用户的数据，选择突出视频和最相关方面的作品推送给用户。

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

流式数据是由数千个数据源连续生成，这些数据源通常同时发送数据记录，并且尺寸很小（以K字节为单位）。流数据包括各种各样的数据，例如客户使用的移动或 Web 应用程序生成的日志、电商购买订单、游戏内玩家活动、社交网络、金融交易或地理空间服务的信息，还有来自连接的遥测数据中心的设备或仪器数据等。

什么是流数据？

这些数据要在逐个记录的基础上或在滑动时间窗口上按顺序与增量处理，并用于各种分析，包括相关性、聚合、过滤和采样。

从此类分析中获得的信息使公司能够了解其业务和用户活动的许多方面。例如——服务使用（用于计量/计费）、服务器活动、网站点击以及设备、人员和实物的地理位置——并支持运营迅速应对新出现的情况。

例如，企业可以通过持续分析社交媒体流来跟踪公众对其品牌和产品的情绪变化，并在必要时及时做出响应。

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

查看历史记录服务捕获会员播放的所有视频

Beacon 是其中一项服务，它捕获 Netflix 内的所有印象事件和用户活动，查看历史记录和 Beacon 服务收集的所有数据都发送到 Apache 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 后端架构的详细分析，希望对各位开发者、架构师提供一些帮助。

相关参考：

• Titus 简介

• https://netflix.github.io/titus/overview/

• Zuul2开源说明

• https://netflixtechblog.com/open-sourcing-zuul-2-82ea476cb2b3

• OpenConnect概述

• https://openconnect.netflix.com/Open-Connect-Overview.pdf

• Netflix后端是如何运行的

• https://www.nexsoftsys.com/articles/how-netflix-backend-system-operates.html

• Hystrix为什么牛？
  

• https://riteeksrivastava.medium.com/hystrix-what-is-it-and-why-is-it-used-f84614c8df5e

• Netflix 工程权衡与API架构
  

• https://netflixtechblog.com/engineering-trade-offs-and-the-netflix-api-re-architecture-64f122b277dd

• 使用SSD的缓存架构
  

• https://netflixtechblog.com/application-data-caching-using-ssds-5bf25df851ef

• 应用数据缓存从内存到SSD的革命
  

• https://netflixtechblog.com/evolution-of-application-data-caching-from-ram-to-ssd-a33d6fa7a690

• 优化Netflix API

• https://netflixtechblog.com/optimizing-the-netflix-api-5c9ac715cf19

作者：洛逸