本文摘要：【编者的话】Netflix的微服务架构为其提供全球视频流服务，本篇文章将对此架构举行全面的系统设计分析。1. 简介Netflix多年来一直是全球最精彩的在线订阅制的视频流服务之一，其占世界互联网带宽容量的15%以上。 2019年，Netflix已经获得了凌驾1.67亿的订阅用户，每个季度新增用户凌驾500万，服务涵笼罩全球200多个国家或地域。更详细点说，Netflix的用户天天要花费凌驾1.65亿小时寓目4000多部影戏和47000多集电视剧。

【编者的话】Netflix的微服务架构为其提供全球视频流服务，本篇文章将对此架构举行全面的系统设计分析。1. 简介Netflix多年来一直是全球最精彩的在线订阅制的视频流服务之一，其占世界互联网带宽容量的15%以上。

2019年，Netflix已经获得了凌驾1.67亿的订阅用户，每个季度新增用户凌驾500万，服务涵笼罩全球200多个国家或地域。更详细点说，Netflix的用户天天要花费凌驾1.65亿小时寓目4000多部影戏和47000多集电视剧。

这些令人印象深刻的数据从工程设计的角度来看，Netflix的技术团队已经设计了一个惊人的视频流系统，其具有高可用性和可扩展性，以服务其全球客户。然而，这可是其技术团队花费了凌驾8年的时间才将他们的IT系统升级到现在的规模。事实上，Netflix的基础架构转型始于2008年8月，触发点是其时数据中心的服务中断导致整个DVD租赁服务关闭了三天。

Netflix意识到它需要一个没有单点故障的更可靠的基础架构。为此，它做出了两个重要的决议：将IT基础架构从其数据中心迁移到公有云，并使用微服务架构的小型可治理软件组件替换其单体应用法式。

这两个决议直接塑造了Netflix今天的乐成。Netflix选择AWS Cloud来迁移其IT基础架构，因为AWS可以在全球规模提供高度可靠的数据库、大规模云存储和多个数据中心。

通过使用AWS建设和维护的云基础架构，Netflix不再去做那些建设数据中心时需要去做的重复的繁重的事情，而是越发专注于他们的焦点业务——提供高质量视频流以及提高用户体验。只管它必须重新构建整个技术，使其能够在AWS云上平稳运行，但Netflix的可扩展性和服务可用性获得了相当显著地改善。Netflix也是微服务架构背后的首要驱动者之一。

微服务通过引入关注点分散来解决单体软件设计的问题，其中通过模块化和数据封装将大法式剖析为更小的组件。微服务还可以通过水平扩展和事情负载分区资助提高可扩展性。

通过接纳微服务，Netflix的工程师可以很容易地改变任何能加速部署速度的服务。更重要的是，他们可以跟踪每个服务的性能，并快速地将某个问题与其他正在运行的服务隔脱离。

本研究中，我比力有兴趣去相识Netflix的云架构及其在差别事情负载和网络限制下的性能。详细来说，我想从可用性、延迟、可扩展性和对网络故障或系统中断的弹性方面分析系统设计。本研究如下：第二部门将形貌从种种在线资源中学习到的可能的Netflix系统架构。

然后在第3节中，将讨论更详细的系统组件。在第4、5、6、7节中，我将针对上述设计目的对系统举行分析。

最后，我将总结从这一分析中获得的教训以及可能后续需要接纳的革新。2. 架构Netflix运营在基于亚马逊云盘算服务（AWS）和其自研的内容交付网络Open Connect上。

这两个系统必须无缝互助，才气在全球提供高质量的视频流服务。从软件架构的角度来看，Netflix包罗三个主要部门：客户端、后端和内容分发网络（CDN）。客户端指的是条记本或台式机上支持的任何浏览器，或智能手机或智能电视上的Netflix应用法式。

Netflix开发了自己的iOS和Android应用法式，为每一个客户端和设备提供最佳的寓目体验。通过SDK控制其应用法式和其他设备，在某些情况下Netflix可以透明地调整其流服务，如网速慢或服务器过载。

后端包罗完全在AWS云上运行的服务、数据库和存储。后台基本上除了不涉及流视频，它处置惩罚一切事务。后台部门组件及其相应的AWS服务如下：可伸缩的盘算实例（AWS EC2）可扩展存储（AWS S3）业务逻辑微服务（Netflix特有的框架）可扩展的漫衍式数据库（AWS DynamoDB, Cassandra）大数据处置惩罚和分析事情（AWS EMR、Hadoop、Spark、Flink、Kafka和Netflix的其他专有工具）视频处置惩罚和代码转换（Netflix特有的工具)Open Connect CDN是一个名为Open Connect Appliance （OCA）的服务器网络，为存储和播放大型视频举行了优化。

这些OCA服务器被放置在世界各地的互联网服务提供商（ISP）和互联网交流中心（IXP）网络中。OCA卖力将视频直接传输给客户。

在接下来的章节中，我将形貌由以上三部门组成的Netflix云架构。在第2.1节中，一个整体的架构是，在用户点击他或她的应用法式上的播放按钮后，能够通过流播放视频，也被称为回放架构（Playback Architecture）。然后在第2.2节中，将形貌一个更详细的后端微服务架构，以演示Netflix如何在全球规模内处置惩罚可用性和可扩展性。

2.1 Playback架构当用户在他们的应用法式或设备上点击播放按钮时，客户端将与AWS上的后端和Netflix CDN上的OCA举行对话，以播放视频。下图展示了Playback历程的事情原理：图1 流视频Playback架构OCA不停发送有关其事情负载状态、可路由性和可用视频的康健陈诉，此陈诉发送给位于AWS EC2的缓存控制中心，以便Playback应用法式将最新且康健的OCA更新到客户端。播放请求从客户端设备发送到运行在AWS EC2上的Netflix播放应用法式服务，以获取流视频的URL。

播放应用法式服务必须确定播放请求将是有效的，才气检察特定的视频。这些验证将检查订阅者的订阅计划、差别国家的视频许可等。Playback应用服务与在AWS EC2中运行的引导服务对话，以获得所请求视频的最合适的OCA服务器的列表。

引导服务使用客户端IP地址和ISP信息来识别一组最适合该客户端的OCA。从Playback应用服务返回的10个差别的OCA服务器列表中，客户端测试到这些OCA的网络毗连质量，并选择最快、最可靠的OCA来请求流传输。所选的OCA服务器接受来自客户端的请求并开始流传输视频。在上图中，Playback应用服务、引导服务缓和存控制服务完全在基于微服务架构的AWS云上运行。

在下一节中，我将先容Netflix后端微服务架构，该架构提高了当前服务的可用性和可扩展性。2.2 后端架构如前所述，后端险些处置惩罚所有内容，从注册、登录、计费到更庞大的处置惩罚任务，如视频转码和个性化推荐等。

为了支持在同一底层基础架构上运行的轻量级和重型事情负载，Netflix为其基于云的系统选择了微服务架构。图2展示了Netflix可能使用的微服务架构，这是我从几个在线资源分析后总结的：图2 基于多种泉源的后端架构参考客户端向AWS上运行的后端发送播放请求。

该请求由AWS负载平衡（ELB）处置惩罚AWS ELB将该请求转发给运行在AWS EC2实例上的API网关服务。该组件名为Zuul，是由Netflix团队构建的，提供动态路由、流量监控和宁静性，以及对云部署的边缘故障提供恢复能力。该请求将应用于一些与业务逻辑相对应的预界说过滤器上，然后转发给应用法式（Application）API做进一步处置惩罚。

Application API组件是Netflix运营背后的焦点业务逻辑。有几种类型的API对应于差别的用户运动，如注册API和用于检索视频推荐的推荐API。在这个场景中，来自API网关服务的转发请求由Play API处置惩罚。

播放（Play） API将挪用一个微服务或一系列微服务来满足请求。图1中的Playback应用法式服务、指导服务缓和存控制服务可以在该图中视为微服务。

微服务大多是无状态的小法式，也可以相互挪用。为了控制其级联故障并启用弹性，每个微服务都通过Hystrix与挪用方历程隔离。其运行后的效果可以缓存在基于内存的缓存中，以便更快速的会见那些关键的低延迟请求。

整个流程里，微服务可以生存数据或从数据存储获取数据。微服务可以将用于跟踪用户运动的事件或其他数据发送到流处置惩罚管道（Stream Processing Pipeline），以便实时处置惩罚个性化推荐或批处置惩罚业务智能任务。来自流处置惩罚管道的数据可以持久化到其他数据存储，如AWS S3、Hadoop HDFS、Cassandra等。

上述架构可以资助我们归纳综合相识系统的各个部门如何组织和协同事情以流传输视频。然而，要分析架构的可用性和可扩展性，我们需要深入研究每个重要的组件，以相识它在差别事情负载下的执行情况。

这将在下一节中详细讨论。3. 组件在本节中，我将研究第2节中界说的组件，以分析其可用性和可扩展性。在形貌每个组件时，我还会说明它是如何满足这些设计目的。

在以后的章节中，将会对整个系统举行更深入的设计分析。3.1 客户端Netflix的技术团队投入了大量精神来开发运行在条记本、台式机或移动设备上的更快、更智能的客户端应用法式。甚至在一些智能电视上，Netflix并没有建设一个专门的客户端，Netflix仍然通过自己的SDK来控制它的性能。事实上，任何设备情况都需要安装Netflix停当设备平台（Netflix Ready Device Platform NRDP），以实现最佳的Netflix寓目体验。

一个典型的客户端结构组件如图3所示。图3 客户端应用法式组件客户端应用法式为内容发现和内容播放分散成两种类型的后端毗连。

客户端使用NTBA协议处置惩罚Playback请求，以确保其OCA服务器位置的宁静性，并消除新毗连的SSL/TLS握手引起的延迟。在流传输视频时，如果网络毗连过载或泛起错误，客户端应用法式会智能降低视频质量或切换到差别的OCA服务器。纵然毗连的OCA过载或失败，客户端应用法式也可以轻松切换到另一个OCA服务器，以获得更好的寓目体验。之所以这些能够实现，是因为客户端上的Netflix平台SDK一直跟踪从Playback Apps服务中检索到的最新的康健OCA列表。

3.2 后端3.2.1 API网关服务API网关服务组件与AWS负载平衡器通信，以解决来自客户端的所有请求。该组件可以跨差别区域部署到多个AWS EC2实例，以提高Netflix服务的可用性。图4中的图展示了一个开源的Zuul，这是一个由Netflix团队建立的API网关的实现。图4 Zuul网关服务组件入站过滤器（Inbound Filter）可用于身份验证、路由和装饰请求。

端点过滤器（Endpoint Filter）可用于返回静态资源或将请求路由到适当的源或应用法式API举行进一步处置惩罚。出站过滤器（Outbound Filter）可用于跟踪指标、装饰对用户的响应或添加自界说头。Zuul能够通过与服务发现组件Eureka集成来发现新的应用法式API。Zuul广泛用于针对种种需求的流量路由，如新应用法式API的加载、负载测试、在大事情负载下路由到差别的服务端点。

3.2.2 应用法式API应用法式API充当Netflix微服务的编配层。API提供了一种逻辑，根据所需的顺序组合对底层微服务的挪用，以及来自其他数据存储的分外数据，以结构适当的响应。

Netflix团队已经花费了大量的时间来设计应用法式API组件，因为它与Netflix的焦点业务功效相对应。在高请求容量下具有高可用性和可扩展性。

现在，应用法式API被界说为三类：注册Signup API（用于非会员请求，如注册、计费、免费试用等）、搜索发现Discovery API （用于推荐请求）、和播放Play API（用于流播放和检察许可请求）。图5提供了应用法式API的详细结构组件图。图5 播放和发现应用法式API的分散在Play API的最新更新中，Play API和微服务之间的网络协议是gRPC/HTTP2，它“允许通过协议缓冲区界说RPC方法和实体，并以种种语言自动生成客户端库或SDK”。

这个改变允许应用法式API通过双向通信与自动生成的客户端适当地集成，并“尽可能淘汰跨服务界限的代码重用”。Application API还提供了基于Hystrix下令的通用弹性机制，以掩护其底层微服务。

由于Application API必须处置惩罚大量的请求并结构适当的响应，因此它的内部处置惩罚需要高度并行的方式运行。Netflix团队发现同步执行和异步I/O相联合才是正确的方式。

图6 Application API的同步执行和异步I/O来自API网关服务的每个请求将被放置到应用法式API的网络事件循环（Network Event Loop）中举行处置惩罚每个请求都将被一个专门的线程处置惩罚法式阻止，该法式将Hystrix下令（如getCustomerInfo、getDeviceInfo等）放入传失事件循环（Outgoing Event Loop）中。每个客户端都设置这个传失事件循环，并非以阻塞I/O运行。一旦挪用微服务完成或超时，上述专用线程将结构对应的响应。

3.2.3 微服务凭据Martin Fowler的界说，“微服务是一套小型服务，每个服务都在自己的历程中运行，并与轻量机制举行通信……”。相对于其他法式，这些小法式可以独立部署或升级，并拥有自己的封装数据。图7展示了Netflix的微服务组件的实现。

图7 微服务的结构组件微服务可以独立事情，也可以通过REST或gRPC挪用其他微服务。微服务的实现可以类似于图6中形貌的Application API，在图6中，请求将被放入网络事件循环中，来自其他被挪用的微服务的效果将以异步非阻塞I/O的方式放入效果行列。

每个微服务可以有自己的数据存储和一些存放近期效果的内存缓存存储。EVCache是Netflix微服务缓存的主要选择。3.2.4 数据存储Netflix在将基础架构迁移到AWS云上时，使用了差别的数据存储（图8），包罗SQL和NoSQL，来完成差别的目的。

图8 在AWS上部署Netflix数据存储MySQL数据库用于影戏名治理和生意业务/下单目的。Hadoop用于基于用户日志的大数据处置惩罚。Elasticsearch为Netflix提供了标题搜索能力。

Cassandra是一个基于漫衍式的NoSQL数据存储，用于处置惩罚大量的读请求，没有单点故障。为了优化大规模写请求的延迟，Netflix使用了Cassandra，因为它具有最终一致性的能力。

3.2.5 流程处置惩罚管线（Stream Processing Pipeline）流处置惩罚数据管道已经成为Netflix的业务分析和个性化推荐任务的数据支柱。它卖力生成、收集、处置惩罚、和汇总所有微服务事件，并险些实时地移动到其他数据处置惩罚器上。图9显示了该平台的各个部门。图9 Netflix的Keystone流处置惩罚平台流处置惩罚平台天天处置惩罚数万亿级的事件和PB级的数据。

它还会随着用户数量的增加而自动扩展。路由器模块支持路由到差别的数据吸收器（sink）或应用法式，同时Kafka卖力路由消息以及对下游系统的缓冲。流处置惩罚即服务（Stream Processing as a Service SPaaS）允许数据工程师构建和监控他们自建的托管流处置惩罚应用法式，而平台将卖力可扩展性和日常运维。

3.3 Open ConnectOpen Connect是一个全球内容交付网络（Content Delivery Network CDN），卖力存储和传送Netflix的电视节目和影戏到世界各地的用户。Netflix通过将人们想要寓目的内容尽可能的靠近他们的物理位置，构建建设和运营了这一个高效的Open Connect网络。为了将寓目Netflix视频的流量定位到客户的网络，Netflix已经与全球互联网服务提供商（ISP）和互联网交流点（IX或IXP）互助，在他们的网络中部署名为Open Connect Appliances（OCA）的专用设备。

图10 将OCA部署到IX或ISP站点OCA是经由优化的服务器，用于存储大型视频文件并将其从IX或ISP站点直接传输到订阅者的家中。这些服务器定期向AWS的Open Connect 控制平面（Control Plane）陈诉他们从IXP/ISP网络学到的康健指标最佳门路，以及他们在SSD磁盘上存储什么视频。作为回报，控制平面服务将获取这些数据，凭据文件可用性、服务器运行状况和与客户端网络的靠近水平，自动将客户端设备定向到最佳的OCA。

控制平面服务还控制在OCA上添加新文件或更新文件的填充（filling）行为。填充行为如图11所示。当新的视频文件乐成转码并存储在AWS S3上时，AWS上的控制平面服务将把这些文件传输到IXP站点上的OCA服务器。

这些OCA服务器将应用缓存填充（Cache Fill）来将这些文件传输到其子网下ISP站点的OCA服务器上。当OCA服务器乐成存储视频文件时，如果需要，它将能够启动对等填充（Peer Fill），将这些文件复制到同一站点内的其他OCA服务器上。

在两个可以看到相互IP地址的差别站点之间，OCA可以应用层填充（Tier Fill）流程，而不是通例的缓存填充。图11 OCA中的填充模式4. 设计目的在前面的小节中，我已经详细形貌了Netfilx视频流业务的云架构及其组件。在这一节和后面的几节中，我想更深入地分析这个设计架构。

首先列出最重要的设计目的，如下：确保流服务在全球规模内的高可用性。弹性处置惩罚网络故障和系统中断。在种种网络条件下，最小化每个设备的流延迟。

支持高请求量的可扩展性。在下面的小节中，我将分析流服务的可用性及其相应的最佳延迟。

第6节更深入地分析了诸如混沌工程（Chaos Engineering）之类的弹性机制，而第7节则先容了流服务的可扩展性。4.1 高可用性凭据界说，系统的可用性是凭据在一段时间内的请求被满足的次数来怀抱的，而不需要保证它包罗信息的最新版本。在我们的系统设计中，流服务的可用性取决于后端服务和服务器二者的可用性。

后端服务的目的是通过缓存或执行某些微服务获得与最靠近指定客户端最康健的OCA的列表。因此，它的可用性取决于涉及Playback请求的种种组件：负载平衡器（AWS ELB）、署理服务器（API网关服务）、播放API、微服务执行、缓存存储（EVCache）和数据存储（Cassandra）：负载平衡器可以通过将流量路由到差别的署理服务器来提高可用性，以防止事情负载过载。播放API通过Hystrix下令使用超时（timeout）来控制微服务的执行，从而防止级联故障影响其他服务。微服务可以使用缓存中的数据来响应播放API，以防对外部服务或数据存储的挪用花费比预期更多的时间。

复制缓存以便用户可以更快地会见。当从后端吸收到OCA服务器列表时，客户端将网络探测到这些OCA并选择要毗连的最佳OCA。如果该OCA在流历程中过载或失败，则客户端切换到另一个好OCA，否则平台SDK将请求其他OCA。

因此，它的可用性与ISPs或IXPs中所有OCA的可用性高度相关。Netflix流服务的高可用性是以庞大的多区域AWS运维和服务以及OCA服务器的冗余为价格的。4.2 低延迟流服务的延迟主要取决于Play API剖析康健OCA列表的速度，以及客户端与所选OCA服务器的毗连情况。正如我在Application API组件一节中所形貌的，Play API不会永远等候微服务的执行，因为它使用Hystrix下令来获取到效果之前要等候的时间，一旦超时立刻从缓存获取非最新的数据。

这样做可以把延迟控制在可接受的规模，并停止级联故障影响更多服务。如果当前选定的OCA服务器泛起网络故障或该服务器过载，客户端将立刻切换到其他四周且网络可靠的OCA服务器。当发现网络毗连欠好，还可以降低视频质量以匹配网络质量。

5. 权衡（Trade-offs）在上面形貌的系统设计中，有两个突出的权衡点已经被仔细地实现了：低延迟凌驾一致性高可用性高于一致性在后端服务的架构设计中就已经选择了用一致性来换取低延迟。Play API可以从EVCache存储或最终一致的数据存储如（Cassandra）中获取过时的数据。类似地，所谓用一致性换取高可用性的权衡就是，系统希望以可接受的延迟提倡响应，而不会对像Cassandra这样的数据存储中的最新数据执行微服务。

在可扩展性和性能之间还存在不太相关的权衡。在这种权衡下，通过增加实例数量来处置惩罚更多的负载，从而提高可扩展性，这可能会导致系统在预期性能提高的情况下运行。这可能是架构设计的问题，在这些架构中，负载在可用的事情节点之间没有很好地平衡。

不外，Netflix已经解决了与AWS自动扩展的权衡问题。我们将在第7节中更详细地讨论这个方案。6. 弹性（Resilience）从迁移到AWS云服务的第一天起，设计一个能够从故障或停机中自我恢复的云系统就一直是Netflix的恒久目的。

本系统的一些常见故障如下：剖析服务依赖项失败。执行微服务的失败将导致对其他服务的级联失败。由于过载而无法毗连到某个API。毗连到实例或服务器（如OCA）的失败。

为了检测息争决这些故障，API网关服务Zuul具有内置的特性，例如自适应重试，从而限制对Application API的并发挪用。反过来，Application API使用Hystrix下令暂停对微服务的挪用，停止级联故障并将故障点与其他故障点隔脱离来。

Netflix的技术团队也以其在杂乱工程的实践而闻名。其思想是将伪随机错误注入生产情况，并构建解决方案来自动检测、隔离，并今后类故障中恢复。

错误可能是在执行微服务、杀死服务、停止服务器或实例、甚至导致整个区域的基础架构瘫痪的响应中增加延迟。通过有目的地将真实的生产故障引入到监控的情况中，并使用工具来检测息争决此类故障，Netflix可以在造成更大的问题之前提早发现这些缺陷。7. 可扩展性（Scalability）在本节中，我将分析Netflix流服务的可扩展性，包罗水平扩展、并行执行和数据库分区。其他部门如缓存和负载平衡也有助于提高可扩展性，这在第4节中已经提到过。

首先，Netflix的EC2实例的水平扩展是由AWS自动扩展服务（Auto Scaling Service）提供的。当请求量增加并关闭未使用的实例，AWS服务将自动生成更多的弹性实例。更详细地说，在数千个这样的实例之上，Netflix构建了一个开源容器治理平台Titus，每周可运行约莫300万个容器。

同样，我们的架构图2中的任何组件都可以部署在容器中。此外，Titus允许容器在世界各地差别大洲的多个区域运行。

其次，第3.2.2节中，通过允许在网络事件循环和异步传失事件循环上并行执行任务，Application API或微服务也提高了可扩展性。最后，像Cassandra这样的宽列存储和像ElasticSearch这样的键值存储也提供了高可用性和高可扩展性，同时没有单点故障。8. 结论此篇研究形貌了Netflix流服务的整个云架构。

它还分析了在可用性、延迟、可扩展性和对网络故障或系统中断的弹性方面的差别设计目的。简而言之，Netflix的云架构通过被自己的生产系统证明，它可以运行在数千台虚拟服务器上为数百万用户提供服务，并通过与AWS云服务的集成和全球规模的网络故障和系统中断的弹性能力，展示了具有最佳延迟的高可用性、强大的可扩展性。本文提到的大多数架构和组件都是通过互联网上可信的资源总结出来的。

只管网上没有太多形貌微服务的内部实现以及监控其性能的工具和系统的直接资源，但本研究可以作为如何构建典型生产系统的参考实现。

本文关键词：Netflix,基于,云的,博亚app最新入口,微,服务,架构,设计,分析,【

本文来源：博亚app最新入口-www.abc168gps.com