IDEA激活码本文对Netflix在增强其全球视频流服务的架构设计方面进行了全方位的系统分析。
1、摘要
多年来，Netflix一直是世界上最好的在线订阅视频流媒体服务之一，占世界互联网带宽容量的15%以上。 2019年，Netflix已经获得了超过1.67亿用户，每个季度新增用户超过500万，在200多个国家运营。更具体地说，Netflix的用户每天花费超过1.65亿小时观看4000多部电影和47000集电视剧。这些令人印象深刻的数据表明，从工程的角度来看，Netflix的技术团队已经设计了一个非常棒的视频流媒体系统，具有非常高的可用性和可扩展性，以便为全球客户提供服务。
然而，这其中花了技术团队超过8年的时间才使他们的IT系统成为现在规模([1])。事实上，Netflix的IT基础设施切换始于2008年8月，当时它自己的数据中心服务中断，整个DVD租赁服务中断了三天。Netflix意识到，它需要一个更可靠的基础设施，没有单点故障。因此，它做出了两个重要的决定:将IT基础设施从其数据中心迁移到公有云，用微服务架构中的小型可管理软件组件替换单体服务。这两个决定直接影响了Netflix今天的成功。
Netflix选择AWS云([4])来迁移其IT基础设施，因为AWS可以在全球提供高可靠的数据库、大规模云存储和多个数据中心。通过利用AWS建立和维护的云基础设施，Netflix没有做自建设数据中心这种单调繁重的工作，而是更多地专注于提供高质量用户体验更好的视频流核心业务。尽管Netflix不得不重建整个技术以使其在AWS云上平稳运行，但Netflix在可扩展性和服务可用性方面的改进获得了显著的回报。
Netflix也是微服务架构背后的第一个主要推动者。微服务在解决单体服务存在的问题方面，采用模块化架构，各模块管理自己的数据存储。 微服务通过水平扩展和负载分区来提高可伸缩性。通过采用微服务，Netflix的工程师可以轻松更改任何服务，从而加快部署速度。更重要的是，它们可以跟踪每个服务的性能，并快速地将其问题与其他正在运行的服务隔离开来。
在本文中，我感兴趣的是了解Netflix的云架构以及它在不同的工作负载和网络限制下的性能。具体来说，我想从可用性、延迟、可伸缩性和对网络故障或系统中断的弹性等方面对其系统设计进行分析。文章的组织如下。第2节将描述从各种在线资源中学到的Netflix系统架构。然后在第3节中，将讨论更详细的系统组件。在第4、5、6、7节中，我将针对上述设计目标对系统进行分析。最后，我总结了从这次分析中学到了什么，以及接下来可能需要采取的改进步骤。
架构
Netflix的运营基于亚马逊云计算服务(AWS)和其自身的内容分发网络Open Connect。这两个系统必须无缝衔接，在全球范围内提供高质量的视频流服务。从软件架构的角度来看，Netflix由三个主要部分组成:客户端、后端和内容分发网络(CDN)。
客户端：包含笔记本电脑或台式电脑上支持的浏览器，或智能手机、智能电视上的Netflix App。Netflix开发了自己的iOS和Android应用程序，为每个客户端和设备提供最佳的观看体验。通过其SDK控制他们的应用程序和其他设备，Netflix可以在某些情况下无感知地调整其流媒体服务，如网络缓慢或服务器过载。
后端包括所有运行在AWS云上的服务、数据库和存储。基本上后台会处理一切请求，不包括流媒体视频。后端部分组件及其对应的AWS服务如下所示:
- 可伸缩的计算实例(AWS EC2
- 可扩展存储(AWS S3)
- 业务逻辑微服务(由Netflix专门构建的框架)
- 可扩展的分布式数据库(AWS DynamoDB, Cassandra)
- 大数据处理和分析工作(AWS EMR、Hadoop、Spark、Flink、Kafka等Netflix专用工具)
- 视频处理和转码(Netflix专用工具)
开放连接CDN是一个被称为Open Connect Appliances (OCAs)的服务器网络，用于存储和推送大型视频。这些OCAs服务器被放置在世界各地的互联网服务提供商(isp)和互联网交换(IXPs)网络中。OCAs负责直接向客户提供流媒体视频。
在下面的章节，我将描述由以上3部分组成的Netflix云架构。在2.1节中，订阅者在其应用程序上点击Play按钮后，整个架构能够播放视频，称为回放架构。然后在2.2节中，将描述一个更详细的后端微服务架构，以演示Netflix如何在全球范围内处理可用性和可伸缩性。】
2.1视频回放架构
当用户点击他们的应用程序或设备上的播放按钮，客户端将与AWS上的后端和Netflix CDN上的OCAs流媒体视频服务连接([7])。下图说明了回放过程是如何工作的:
1、OCAs不断向AWS EC2中运行的缓存控制服务发送有关其工作负载状态、可路由性和可用视频的运行状况报告，以便回放应用程序将最新的运行状况OCAs更新到客户端。
2、播放请求从客户端设备发送到运行在AWS EC2上的Netflix的播放应用程序服务，以获取流媒体视频的url。
3、要查看特定的视频，播放应用程序服务必须确定播放请求是有效的。这些验证将检查用户的请求，视频在不同国家的是否许可等。
4、Playback Apps服务与同样运行在AWS EC2中的Steering服务通信，以获得所请求视频的可用OCAs服务器列表。steering服务使用客户的IP地址和ISP信息来为客户端选择一组最适合的OCAs服务器（一般就近获取速度快）。
5、 从Playback Apps服务返回的10个不同的OCAs服务器列表中，客户端测试这些OCAs的网络连接质量，并选择最快、最可靠的OCA来请求流媒体视频文件。
6、所选的OCA服务器接受来自客户端的请求并开始播放视频。
在上图中，播放应用程序服务、steering服务和缓存控制服务完全运行在基于微服务架构的AWS云中。在下一节中，我将描述Netflix后端微服务架构，该架构提高了运行服务的可用性和可伸缩性。
2.2后端架构
正如我在前几节中所描述的，后端几乎处理所有事情，从注册、登录、计费到更复杂的处理任务(如视频转码和个性化推荐)。为了支持在相同的底层基础设施上运行的轻量级和重型工作负载，Netflix为他们的云系统选择了微服务架构。图2是我根据网络上提供的信息，给出了Netflix的微服务架构:
1、客户端发送一个播放请求到运行在AWS的后端。该请求由AWS负载均衡器(ELB谈性负载均衡)处理。
2、AWS ELB将把该请求转发给运行在AWS EC2实例上的API网关服务。这个名为Zuul的组件由Netflix团队构建，用于实现动态路由、流量监控和安全，以及故障恢复能力。请求将转发到预先定义的具有业务逻辑的过滤器，然后转发给应用程序 API进行进一步处理。
3、应用程序API组件是Netflix运营背后的核心业务逻辑。有几种不同类型的API对应不同的用户活动，如注册API，视频推荐检索API。在播放场景中，来自API网关服务的转发请求由Play API处理。
4、播放 API将调用一个微服务或一系列微服务来满足请求。图1中的Playback Apps服务、Steering服务和Cache Control服务可以看作是这个图中的微服务。
5、微服务大多是无状态的小程序，也可以相互调用。为了控制级联故障并实现弹性，Hystrix将每个微服务与调用进程隔离。请求的结果可以缓存在基于内存的缓存中，以便更快地访问那些关键的低延迟请求。
6、微服务可以在数据存储过程中保存数据或从数据存储中获取数据。
7、微服务可以发送事件来跟踪用户行为或发送其他数据到流处理进行实时分析然后进行业务个性化推荐。
8、 来自流处理后的数据可以持久化到其他数据存储，如AWS S3、Hadoop HDFS、Cassandra等。
上面所描述述的架构帮助我们大致了解不同微服务是如何组织和一起工作来提供流媒体服务的。然而，为了分析架构的可用性和可伸缩性，我们需要深入研究每个重要组件，以了解它在不同工作负载下的性能。这将在下一节中讨论。
