Netflix体系结构解读

Netflix在AWS和Open Connect上运行。两个云需无缝连接，才能给用户带来流畅的视频体验。

Netflix有三个组成部分：
Open Connect（Netflix CDN）
后台
客户端

客户端包含任何能够播放Netflix视频的设备的用户界面，譬如TV，XBOX，笔记本和智能手机。任何与视频服务无关的功能都在AWS上实现。在用户点击播放之后的任何功能是由Open Connect实现。Open Connect是Netflix定制的CDN。

CND（内容传递网络）是一个分布式服务器系统。该系统根据用户的地理位置，网页和服务器的起点，将网页和其他网络内容传递给用户。当Netflix的视频被转码后，Open Connect将Netflix的视频存储与世界各地。

视频播放流程
当用户打开Netflix应用时，所有的请求都是由AWS来完成。譬如登录，推荐，主页，用户历史记录和客服等。当用户点击视频的播放按钮，Netflix应用会自动判定最佳的Open Connect服务器，最好的格式和比特率，以便让视频从附近的OCA流畅地传出。Netflix应用相当的智能，它能不间断地寻找流媒体服务器和比特率，并自动替换到能为用户带来更好体验的服务器。这些功能的实现得益于用户在AWS上的搜索，浏览，位置，设备，评论和收藏等数据。AWS使用映射-规约（Map-Reduce），机器学习等方式向用户推荐新视频。

ELB
Netflix使用亚马逊的ELB来把流量导向用户的客户端。Netflix对ELB进行如下设置：首先是区域间的负载平衡，然后是实例间的负载平衡。这是因为ELB的设置是有两级负载平衡方案：
第一层包含基本的基于域名服务的循环负载平衡。这使得客户端访问某一AWS端点，该端点存在于配置好的区域。
第二层包括在同一区域内的多个负载平衡实例，在多个负载平衡实例间实行循环负载平衡。

ZUUL
ZUUL是个边缘服务应用。ZUUL就像一个前门，把所有来自设备和网站的请求导向后台的流媒体服务。ZUUL实现了动态路由，监控，弹性和安全。并能将请求导向Amazon不同的自动缩放组（Auto Scaling Groups）。

ZUUL有几个组件：Netty handlers，inbound filters，endpoint filters和outbound filters。Netty filters存在于过滤器的前端和后端。其主要的功能是处理网络协议，网络服务器，连接管理和代理工作（proxing）。在内部工作细节被抽象化了以后，过滤器承担所有的重任。入站过滤器运行在代理请求之前，承担着认证，路由和对请求进行增减。端点过滤器即可返回静态响应，又可把请求导向后端服务。出站过滤器运行在响应被返回之后，承担着诸如压缩，指标和增减HTTP标头。

ZUUL的特性是：支持HTTP/2，传输层安全，自适应重试，起点协调保护。ZUUL能起到基于请求的参数，URL和路径的简易路由。应用的实际例子是能把用户导向特定的服务器集群。

ZUUL有如下优点。把服务的流量化整为零，可以创建路由规则来把不同的路径/前缀映射到不同的起点。开发人员能够通过把主机名映射到端点的方式添加新的设备。开发人员在进行载荷测试的时候可以把现有的部分流量导向小的集群，以确保应用的服务质量能够合理的降级。重构应用代码时，负责的组能够通过重建规则，把应用导向不同的起点，一次一个路径。测试组能够通过把少部分流量导向运行新代码的集群来进行测试。安全组可以通过创建基于路径或头文件的规则来拒绝恶意访问。

Hystris
Hystrix是个延迟和容错代码库，旨在把访问点和远程系统，服务和第三方代码库隔离开来。这样做的好处是：
阻止级联错误
实时监控配置变动
基于并行的请求缓存
基于请求崩溃的自动批处理，即一个微服务失败后的缺省响应和等待知道微服务恢复

微服务
APIs是如何获得响应的？Netflix使用微服务架构来驱动所有的APIs，来为网络应用服务。每个API调用其他的微服务来获取所需的数据和提供响应。这一架构的可靠性如何实现呢？一是以来Hystris，第二是分离关键服务。

关键微服务
依照Netflix的设计，当遇到级联失败时，至少用户还可以点击并播放推荐的视频。实现这一功能的微服务被称为关键微服务。关键微服务对其它服务没有很多依赖性。

无状态服务
Netflix的一个设计目标是无状态服务。无状态服务的理念是任一服务实例都能按时地服务任一请求。这使得任一服务器失败的话都无关紧要。在失败的情况下请求可以被路由到另外一服务实例，或者启动一个新的服务器来取代失败的服务器。

EV缓存
当一个节点失败后，节点上的缓存也会跟着失败。这样就会有性能损失，除非所有数据都有缓存。Netflix的解决方案是使用EV缓存。这是基于Memcached上的一个封装。又不是简单的封装，是有冗余度的分片集群。所以在存操作时，所有的分片都被更新。在读操作的情况下，是从最近的缓存或节点读取数据。当最近的节点失败，则会从其它的节点读取。EV缓存能够处理每天三千万的请求，并具有毫秒级的线性扩展性。

数据库（部署在EC2上的MySQL）
EC2 MySQL是计费和用户信息的最终选择。Netflix甚至还有基于主机的“同步复制协议”。该协议用以确保主机上写操作完成的前提条件是写操作在主机和远程终端都完成。这样做的好处是，单个节点的丢失不会造成数据的丢失。读操作副本在本地和远程设立。ETL工作的读流量被导向读操作副本，以便于主数据库免于繁重的批处理操作。在主数据库失败的情况下，故障转移会在已经有了复制的次节点上进行。当次节点能够胜任主数据库的工作时，route53上DNS的条目就会指向新的次节点。

Cassandra
在Netflix，Cassandra用来存储用户的阅读历史数据。随着用户阅读量的大增，Netflix的Cassandra集群也经历了重新设计。重新设计的理念是：更小的存储，在用户阅读量增加情况下的一致的读写性能。解决方案就是：压缩旧的数据。数据被分成两类：
实时阅读历史（LiveVH）：频繁被更新的少量的最近阅读的数据。数据以未被压缩的形式存储
压缩阅读历史（CompressedVH）：很少被更新的大量的旧的阅读数据。数据被压缩以减少存储空间。压缩阅读历史被存储在基于行密匙的单个列里。

Apache Chukwa
这是一个开源的监控大规模分布式系统的数据采集系统。Apache Chukwa是基于Hadoop HDFS和映射-规约架构。这使其继承了Hadoop的可扩展性和稳健性。Apache Chukwa还包含功能强大的显示，监控和分析功能的工具包，以充分利用收集的数据。Kafka的路由服务负责把数据从Kafka 的前端移动到不同的目的地：S3，Elasticsearch和次级Kafka。这个路由服务叫Apache Samza。当Chukwa把流量发给Kafka，既可以是全部数据流，也可以是过滤流。

Elastic Search
Elastic search在Netflix被越来越广泛的应用。最基本的实例是差错和客服。譬如一个用户想要播放一个视频但却没有成功，该用户向客服查询。客服是如何进行差错的呢？客服是通过elastic search来查询数据（日志）来深入研究问题出在哪里。

AWS应用自动缩放功能 - TITUS
Titus的目的是启动简易和可靠的部署应用程序的容器。Titus的目的是：
允许容器化的应用与AWS，Netflix个其它云服务无缝连接
可操作性上能够保证系统能运行关键任务载荷和服务水平协议
可扩展性上保证成千上万的主机上能够运行成千上万个容器，来实现众多的运行实例

Titus是一个基于Apache Mesos的框架，是连接众多主机资源的集群管理系统。Titus包括一个可复制的，提供领导选择的调度器。该调度器叫做Titus Master。Titus Master负责将容器放置到EC2虚拟机的一个大池子里。该EC2虚拟机亦叫Titus Agents，负责单个容器的生命周期。Zookeeper管理领导选择，Cassandra存储Titus Master的数据。

Titus的一个最大的功能是自动缩放。那自动缩放是怎样工作的呢？例如，一个用户在东岸打开Netflix，Netflix 的服务自动扩大业务来满足该用户的视频需求。该设计基于AWS自动缩放引擎能够计算一个Titus服务的期望容量，把容量信息传递给Titus，从而使得Titus能够根据容量来启动或停止容器来调整载荷。该方案有几个优势：第一，充分利用经过检验的AWS自动缩放引擎。第二，Titus用户可以使用已经熟悉的EC2。第三，应用能够缩放自己的指标（譬如每秒请求和容器CPU利用率）和AWS的指标（譬如SQS队列深度）。第四，用户能够从AWS对自动缩放的完善中获益。

Titus的一个大的挑战是启动AWS自动缩放引擎调用Titus控制平台。为了解决之一问题，Netflix充分利用AWS的API网关。AWS的API网关是一个提供API访问前门的服务，以便AWS调用。同时也提供了后台来调用Titus。API网关提供了供AWS访问的API，以调整资源载荷和载荷状态，以便后台实现可扩展的资源。当Titus服务配置了自动缩放策略，Titus便在AWS上创建了一个可缩放目标。

媒体处理
Netflix花费很多时间验证视频。视频验证包括查找数字工件，颜色变化，由于前面转码步骤的数据丢失造成的帧丢失。在视频被验证后，就会被送入Netflix称作的媒体管道。处理几兆尺寸的一个文件并不现实，所以管道的第一步是把一个文件分割成若干个小块。接下来视频块被接通到管道，这样编码会并行处理。

Archer
Archer是具有映射-规约风格的媒体处理平台。Archer使用容器，这使得用户能够处理操作系统级别的依赖性。该平台可以进行通常的媒体处理步骤。开发人员需要写三个功能：分离，映射，收集。任何编程语言都可以使用。Archer创建的目的就是大规模进行简单媒体处理。这意味着平台知道媒体格式，并给予流行媒体模式优先处理。

SPARK在推荐上的应用
SPARK用于内容推荐和个性化。大多数会员个性化的机器学习管道是在大型SPARK管理集群上运行的。这些模型形成了推荐系统的基础，该推荐系统支持在Netflix应用上的不同个性化的画布，譬如标题相关排名，行选择，排序和艺术品个性化等。

下面是一个展示Netflix是如何利用数据分析能力来吸引用户观看更多的视频的。当用户浏览Netflix寻找视频时，你注意到每个视频都有一个显示图像了吗？这被称为标题图片。标题图片是用来吸引用户的。其想法是标题图片越生动，用户就越可能观看该视频。用户看的视频越多，就越不容易退订。用户会惊奇地发现标题图片像是为你量身定做。每个人看到的标题图片是不同的。那推荐和个性化是如何工作的呢？Netflix根据一些选项随机显示一张图像。Netflix记录一个视频被看了多少次，以及视频被选中时的画面。这就是数据驱动。

Netflix推荐系统工作原理
当用户访问Netflix 时，Netflix的推荐系统致力于用最小的努力为用户带来愉悦的体验。推荐系统考虑如下几点：
用户和Netflix的互动（用户的浏览历史，对视频的评分）
有相同品味和偏好的其它用户
有关标题的信息，譬如类型，类别，演员，发布年份等
除了了解用户在Netflix上观看了什么，个性化的推荐还需要考虑如下事项：
一天的观看时段
观看的设备
观看的时间
推荐有不同的算法。Netflix着眼于Collaborative Filtering（CF）和Content-based Filtering（CB）。Collaborative Filtering基于一个理念，即如果两个用户有相同的评级历史，那么这两个用户将来的行为也很相似。譬如，存在两个行为很像的用户，如果一个用户观看了一个视频并给出好的评价，那么预示着第二个用户会有着相同的模式。Content-based Filtering的理念是向用户推荐类似于点赞过的视频。CB和CF的不同之处在于，CB不仅基于评分相似度，更关乎视频提供的信息，譬如视频标题，年份，演员和类型。为了实现这一功能，必须获取每个视频的信息，和描述用户喜好的用户资料。目的是发现用户的喜好，并向用户推荐相关的产品。

混合过滤是CF和CB的组合。