作者：Cao Duc Nguyen
起源：https://medium.com/swlh/a-des…
概述
数年来，Netflix 始终是寰球体验最好的在线订阅制视频流媒体服务，其流量占寰球互联网带宽容量的 15%以上。在过来的 2019 年，Netflix 曾经有 1.67 亿名订阅用户，均匀每个季度新增 500 万订户，服务笼罩寰球 200 多个国家 / 地区。
Netflix 用户每天在 4000 多部电影和 47000 集电视剧上破费超过 1.65 亿小时的工夫。从工程角度看，这些统计数据向咱们展现了 Netflix 的技术团队设计出了如许优良的视频流零碎，而这套零碎具备很高的可用性和可扩展性，能为寰球用户提供服务。
实际上，Netflix 的技术团队是花了超过 8 年工夫方打造出明天这样弱小的 IT 零碎。
实 Netflix 的基础架构转型始于 2008 年 8 月，那时这家公司的数据中心遇到了 Web 服务中断的故障，导致整个 DVD 租赁服务敞开 3 天，损失较大。Netflix 的技术团队如梦方醒，它须要一个没有单点故障的更牢靠的基础架构。因而技术团队管理层做出两个重要决定，将 IT 基础架构从本人的 IDC 迁徙到公共云上，通过革新成微服务架构，用较小的易管理软件组件替换单体程序。
以上这两个决定为明天 Netflix 的胜利打下了坚实基础。
Netflix 之所以抉择 AWS 云来迁徙其 IT 基础架构，是因为 AWS 能够在寰球范畴内提供高度牢靠的数据库、大规模云存储和泛滥数据中心。Netflix 利用了由 AWS 构建和保护的云基础架构，从而免去自建数据中心的沉重重复劳动，并将更多精力放在提供高质量视频流体验的外围业务上。只管 Netflix 须要重构整个技术体系，以使其能在 AWS 云上安稳运行，但作为回报，零碎的可扩展性和服务可用性失去显著地进步。
架构
Netflix 基于亚马逊云计算服务（AWS 云），及公司外部的内容交付网络：Open Connect 经营。两套零碎必须无缝合作能力在寰球范畴内提供高质量的视频流服务。
从软件架构的角度来看，Netflix 包含三大部分：客户端、后端和内容交付网络（CDN）。
客户端是用户笔记本电脑或台式机上所有受反对的浏览器，或者智能手机 / 智能电视上的 Netflix 利用。Netflix 开发了本人的 iOS 和 Android 利用，试图为每个客户端和每台设施都能提供最佳的观看体验。Netflix 能够通过其 SDK 管制本人的利用和其余设施，从而在某些场景下（例如网络速度迟缓或服务器超载）通明地调整流服务。
后端包含齐全在 AWS 云上运行的服务、数据库和存储。后端基本上能够解决不波及流视频的所有内容。后端的某些组件及其对应的 AWS 服务列举如下：
- 可扩大计算实例（AWS EC2）
- 可扩大存储（AWS S3）
- 业务逻辑微服务（Netflix 专用框架）
- 可扩大的分布式数据库（AWS DynamoDB、Cassandra）
- 大数据处理和剖析作业（AWS EMR、Hadoop、Spark、Flink、Kafka 和一些 Netflix 专用工具）
- 视频解决和转码（Netflix 专用工具）
Open Connect CDN 是称为 Open Connect Appliances（OCAs）的服务器网络，已针对存储和流传输大尺寸视频进行了优化。这些 OCA 服务器搁置在世界各地的互联网服务提供商（ISP）和互联网替换地位（IXP）网络内。OCA 负责将视频间接流传输到客户端。
Playback 架构
当订阅者单击利用或设施上的播放按钮时，客户端将与 AWS 上的后端和 Netflix CDN 上的 OCA 对话以流传输视频。下图阐明了 playback 流程的工作机制：
用于流视频的 playback 架构：
- OCA 一直将对于其负载状态、可路由性和可用视频的运行状况报告发送到在 AWS EC2 中运行的缓存管制（Cache Control）服务上，以便 Playback 利用向客户端更新最新的衰弱 OCA。
- 播放（Play）申请从客户端设施发送到在 AWS EC2 上运行的 Netflix 播放应用服务，以获取流视频的 URL。
- Playback 应用服务必须确定播放申请是无效的，能力观看特定视频。这里的验证流程将检查用户的订阅打算，以及在不同国家 / 地区的视频许可等。
- Playback 应用服务会与同在 AWS EC2 中运行的疏导（Steering) 服务对话，以获取所申请视频的适合的 OCA 服务器列表。疏导服务应用客户端的 IP 地址和 ISP 信息来确定一组最适宜该客户端的 OCA。
- 客户端从 Playback 应用服务返回的 10 个 OCA 服务器的列表中测试这些 OCA 的网络连接品质，并抉择最快、最牢靠的 OCA 来申请视频文件，进行流传输。
- 选定的 OCA 服务器承受来自客户端的申请并开始流传输视频。
- 在上图中，Playback 应用服务、疏导服务和缓存管制服务齐全在基于微服务架构的 AWS 云中运行。在下一节中我将介绍 Netflix 后端微服务架构，该架构可进步以后服务的可用性和可扩展性。
后端架构
如前所述，后端要解决简直所有内容，从注册、登录、计费到更简单的解决工作，如视频转码和个性化举荐等无所不包。为同时反对在同一底层基础架构上运行的轻量与重量级负载，Netflix 为其基于云的零碎抉择了微服务架构。图 2 展现了 Netflix 可能应用的微服务架构，我从一些在线资源中总结出了这些架构状态：
客户端向在 AWS 上运行的后端发送一个播放申请。该申请由 AWS 负载均衡器（ELB）解决。
- AWS ELB 会将申请转发到在 AWS EC2 实例上运行的 API 网关服务上。名为 Zuul 的组件是由 Netflix 团队构建的，提供动静路由、流量监控和安全性，以及对云部署边缘故障的恢复能力。该申请将利用在与业务逻辑对应的一些预约义过滤器上，而后转发到应用程序（Application）API 做进一步解决。
- 应用程序 API 组件是 Netflix 经营背地的外围业务逻辑。有几种类型的 API 对应不同的用户流动，如注册 API 和用于检索视频举荐的举荐 API 等。在这里，来自 API 网关服务的转发申请由播放 API 解决。
- 播放 API 将调用一个或一系列微服务来满足申请。图 1 中的播放应用服务、疏导服务和缓存管制服务能够视为微服务。
- 微服务次要是无状态的小型程序，并且也能够互相调用。为了管制其级联故障并取得弹性，Hystrix 将每个微服务与调用者过程隔离开来。其运行后果能够缓存在基于内存的缓存中，以更快地拜访那些要害的低提早申请。
- 微服务能在流程中保留到数据存储或从数据存储中获取数据。
- 微服务能够将用于跟踪用户流动或其余数据的事件发送到流解决管道（Stream Processing Pipeline），以实时处理个性化举荐工作，或批处理业务智能工作。
- 来自流解决管道的数据能长久存储到其余数据存储中，如 AWS S3、Hadoop HDFS 和 Cassandra 等。
上述架构能够帮忙咱们概括理解零碎的各个局部如何组织和协同工作以流传输视频。但要剖析这一架构的可用性和可扩展性，咱们须要深入研究每个重要组件，以理解其在不同负载下的性能体现。下一节将具体介绍这部分内容。
组件
本节会深入研究第 2 节中定义的组件，以剖析其可用性和可扩展性。在介绍每个组件时，我还将阐明它们是如何满足这些设计指标的。在前面的章节中将对整个零碎进行更深刻的设计剖析。
客户端
Netflix 技术团队投入了大量精力来开发能在笔记本、台式机或挪动设施上运行得更快、更智能的客户端利用。即便在某些没有专用 Netflix 客户端的智能电视上，Netflix 依然能够通过本人提供的 SDK 来管制设施的性能体现。实际上，任何设施环境都须要装置 Netflix Ready Device Platform（NRDP），以实现最佳的观看体验。图 3 展现了一个典型的客户端结构组件。
- 客户端利用（Client App）会将本人与后端的连贯分为 2 种类型，别离用于内容发现（Content discovery）和内容播放。客户端对播放申请应用 NTBA 协定，以确保其 OCA 服务器地位具备更高的安全性，并打消了新连贯的 SSL/TLS 握手引起的提早。
- 在流传输视频时，如果网络连接过载或呈现谬误，客户端利用会智能地升高视频品质或切换到其余 OCA 服务器上。即便连贯的 OCA 过载或呈现故障，客户端利用也能够轻松切换为其余 OCA 服务器，以取得更好的观看体验。之所以客户端能实现所有这些指标，是因为其上的 Netflix Platform SDK 始终在跟踪从播放应用服务中检索到的最新衰弱 OCA 列表。
后端
API 网关服务
API 网关服务（API Gateway Service）组件与 AWS 负载均衡器（Load Balancer）通信以解析来自客户端的所有申请。该组件能够部署到位于不同区域的多个 AWS EC2 实例上，以进步 Netflix 服务的可用性。图 4 展现了开源的 Zuul，这是 Netflix 团队创立的 API 网关的实现。
- 入站过滤器（Inbound Filter）可用于身份验证、路由和装璜申请。
- 端点过滤器（Endpoint Filter）可用于返回动态资源或将申请路由到适当的 Origin 或应用程序 API 做进一步解决。
- 出站过滤器（Outbound Filter）可用于跟踪指标、装璜对用户的响应或增加自定义标头。
- Zuul 集成了服务发现组件 Eureka，从而可能发现新的应用程序 API。
- Zuul 被宽泛用于各种用处的流量路由工作上，例如启用新的应用程序 API、负载测试、在负载很大的状况下路由到不同的服务端点上，等等。
应用程序 API
应用程序 API 充当 Netflix 微服务的业务流程层（也称编排层）。这种 API 提供了一种逻辑，按所需程序组装对底层微服务的调用，并带有来自其余数据存储的额定数据以结构适当的响应。Netflix 团队花了很多工夫设计应用程序 API 组件，因为它对应 Netflix 的外围业务性能。它还须要在高申请量下具备可扩大和高可用性。以后，应用程序 API 分为三类：用于非会员申请（例如注册、下单和收费试用等）的注册（Signup）API，用于搜寻和发现申请的发现（Discovery）API，以及用于流视频和查看许可申请的播放 API。图 5 提供了应用程序 API 的具体结构组件图。
- 在播放 API 实现的最新更新中，播放 API 和微服务之间的网络协议是 gRPC/HTTP2，它“容许通过协定缓冲区定义 RPC 办法和实体，并主动以多种语言生成客户端库 /SDK”。此项更改使应用程序 API 能够通过双向通信与主动生成的客户端进行适当集成，并“尽可能减少跨服务边界的代码重用”。
- 应用程序 API 还提供了一种基于 Hystrix 命令的通用弹性机制，以爱护其底层微服务。
因为应用程序 API 必须解决大量申请并结构适当的响应，因而其外部解决工作须要高度并行运行。Netflix 团队发现正确的办法是同步执行和异步 I/O 相结合利用。
- 来自 API 网关服务的每个申请都将放入应用程序 API 的网络事件循环（Network Event Loop）中解决；
- 每个申请将被一个专用的线程处理程序阻止，该处理程序将 Hystrix 命令（如 getCustomerInfo 和 getDeviceInfo 等）放入传出事件循环（Outgoing Event Loop）中。传出事件循环是针对每个客户端设置的，并以非阻塞 I/O 运行。一旦调用的微服务实现或超时，上述专用线程将结构对应的响应。
微服务
依照 Martin Fowler 的定义，“微服务是一组小型服务，每个小服务都在本人的过程中运行，并应用轻量机制通信……”。这些小型程序能够独立部署或降级，并具备本人的封装数据。
Netflix 上的微服务组件实现如图 7 所示。
- 微服务能够独立工作，也能通过 REST 或 gRPC 调用其余微服务。
- 微服务的实现能够相似于图 6 中形容的应用程序 API 的实现：申请将被放入网络事件循环中，而来自其余被调用的微服务的后果将放入异步非阻塞 I/O 中的后果队列。
- 每个微服务能领有本人的数据存储和一些寄存近期后果的内存缓存存储。EVCache 是 Netflix 微服务缓存的次要抉择。
数据存储
Netflix 将其基础架构迁徙到 AWS 云时，针对不同的用处应用了不同的数据存储（图 8），包含 SQL 和 NoSQL。
- MySQL 数据库用于电影题目治理和交易 / 下单目标。
- Hadoop 用于基于用户日志的大数据处理。
- ElasticSearch 为 Netflix 利用提供了题目搜寻能力。
- Cassandra 是基于列的分布式 NoSQL 数据存储，可解决大量读取申请，而没有单点故障。为了优化大规模写申请的提早，Netflix 应用了 Cassandra，因为它具备最终的一致性能力。
流解决管道
流解决数据管道（Stream Processing Data Pipeline）已成为 Netflix 业务剖析和个性化举荐工作的数据骨干。它负责实时生成、收集、解决和汇总所有微服务事件，并将其挪动到其余数据处理器上。图 9 展现了该平台的各个局部。
- 这一流解决平台每天解决数以万亿计的事件和 PB 级的数据。随着订户数量的减少，它也会主动扩大。
- 路由（Router）模块反对路由到不同的数据 sink 或应用程序上，而 Kafka 负责路由音讯，并为上游零碎提供缓冲。
- 流解决即服务（SPaaS）使数据工程师能够构建和监督他们自定义的可治理流解决应用程序，而平台将负责可扩展性和运维。
Open Connect
Open Connect 是一个寰球内容交付网络（CDN），负责存储 Netflix 电视节目和电影并将其交付给全世界的订户。Netflix 为了让人们想要观看的内容尽可能凑近他们想要观看的地位，而构建和经营了 Open Connect 这一高效率的网络。为了将观看 Netflix 视频的流量导向到客户的当地网络中，Netflix 已与世界各地的互联网服务提供商（ISP）和互联网替换点（IX 或 IXP）单干，以在这些合作伙伴的网络外部部署称为 Open Connect Appliances（OCA）的专用设备。
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 地址的 2 个不同站点之间，OCA 能够应用层填充（tier fill）流程，而不是惯例的缓存填充。
设计指标
在后面的章节中，我具体介绍了为 Netflix 视频流业务提供反对的云架构及其组件。在本节和后续章节中，我想更深刻地剖析这种设计架构。我会从最重要的设计指标列表开始，如下所示：
- 确保寰球范畴内流服务的高可用性。
- 弹性解决网络故障和零碎中断。
- 在各种网络条件下，将每台受反对设施的流传输提早降至最低。
- 反对高申请量的可扩展性。
在上面的大节中，我将剖析流服务的可用性及其对应的最佳提早。第 6 节是对于弹性机制（例如混沌工程）的更深入分析，而第 7 节介绍了流服务的可扩展性。
高可用性
依据定义，零碎的可用性是用一段时间内对申请的响应有多少次来掂量的，但不能保障响应蕴含了信息的最新版本。在咱们的零碎设计中，流服务的可用性是由后端服务和保留流视频文件的 OCA 服务器的可用性独特决定的。
- 后端服务的指标是通过缓存或某些微服务的执行来获取最靠近特定客户端的衰弱 OCA 列表。因而，其可用性取决于波及播放申请的泛滥组件：负载均衡器（AWS ELB）_ 代理服务器（API 网关服务）、播放 API、微服务的执行、缓存存储（EVCache）和数据存储（Cassandra）：
- 负载均衡器能够将流量路由到不同的代理服务器上以帮忙避免负载超载，从而进步可用性。
- 播放 API 通过 Hystrix 命令管制超时微服务的执行，从而避免级联故障影响其余服务。
- 如果微服务对外部服务或数据存储的调用所破费的工夫超出预期，则它能够应用缓存中的数据响应播放 AI。
当客户端从后端接管到 OCA 服务器列表时会在网络上探测这些 OCA，并抉择最佳的 OCA 进行连贯。如果该 OCA 在流处理过程中超载或失败，则客户端将切换到另一个状态良好的 OCA 上，否则 Platform SDK 将申请其余 OCA。因而，其可用性与 ISP 或 IXP 中所有可用 OCA 的可用性高度相干。
Netflix 流服务的高可用性是以简单的多区域 AWS 运维和服务，以及 OCA 服务器的冗余为代价的。
低提早
流服务的等待时间次要取决于播放 API 能多快地解析衰弱的 OCA 列表，以及客户端与所选 OCA 服务器的连贯衰弱程度。
正如我在应用程序 API 组件局部中所述，播放 API 不会永远期待微服务的执行，因为它应用 Hystrix 命令来管制获取到后果之前要期待的工夫，一旦超时就会从缓存获取非最新数据。这样做能够将提早管制在可承受的程度上，还能防止级联故障影响更多服务。如果以后选定的 OCA 服务器呈现网络故障或超载，则客户端将立刻切换到其余具备最牢靠网络连接的 OCA 服务器上。如果发现网络连接品质降落，它也能够升高视频品质以使其与网络品质相匹配。
衡量
通过认真思考，在上述零碎设计中曾经做出了两个重要的衡量：
- 用一致性换取低提早
- 用一致性换取高可用性
该零碎后端服务的架构设计抉择了用一致性来换取低提早。播放 API 能够从 EVCache 存储或最终统一的数据存储（如 Cassandra）中获取过期的数据。
相似地，所谓用一致性换取高可用性的衡量是说，零碎心愿以可承受的提早发动响应，而不会对像 Cassandra 这样的数据存储中的最新数据执行微服务。
在可扩展性和性能之间还存在不齐全相干的衡量。在这种衡量下，通过减少实例数量来解决更多负载来进步可扩展性，可能会导致系统达不到预期的性能晋升程度。对于那些无奈在可用 worker 之间很好地均衡负载的设计架构来说，这可能是个问题。然而，Netflix 通过 AWS 主动扩大解决了这一矛盾。咱们将在第 7 节中具体探讨这个解决方案。
弹性
从迁徙到 AWS 云的那一天起，设计一套可能从故障或停机中自我复原的云零碎就始终是 Netflix 的长期指标。该零碎已解决的一些常见故障如下：
- 解析服务依赖项时失败。
- 执行微服务时的失败，导致级联失败影响其余服务。
- 因为过载导致无奈连贯到某个 API 上。
- 连贯到实例或服务器（如 OCA）时失败。
为了检测并解决这些故障，API 网关服务 Zuul 提供了一些内置性能，如自适应重试和限度对应用程序 API 的并发调用等。反过来说，应用程序 API 应用 Hystrix 命令来使对微服务的调用超时，以进行级联故障并将故障点与其余服务隔离开来。
Netflix 技术团队也以其在混沌工程上的实际而闻名。这个想法是将伪随机谬误注入生产环境，并构建解决方案以自动检测、隔离这类故障，并从中复原。这些谬误可能会减少执行微服务的响应的提早、杀死服务、进行服务器或实例，甚至可能导致整个区域的基础架构瘫痪。通过有目的地应用检测和解决此类故障的工具，将事实的生产故障引入受监控的环境，Netflix 能够在这类缺点造成较大问题之前提前发现它们。
可扩展性
在本节中，我将介绍程度扩大、并行执行和数据库分区这些 Netflix 的流服务可扩展性因素。缓存和负载平衡等因素也有助于进步可扩展性，它们已在第 4 节中提到了。
首先，AWS 主动扩大（Auto Scaling）服务提供了 Netflix 上 EC2 实例的程度扩大能力。当申请量减少时，这个 AWS 服务将主动启动更多弹性实例，并敞开未应用的实例。更具体地说，在成千上万个此类实例的根底上，Netflix 构建了一个开源容器治理平台 Titus，其每周可运行约 300 万个容器。同样，图 2 架构中的任何组件都能够部署在容器内。此外，Titus 容许容器运行在寰球各大洲的多个区域内。
其次，第 3.2.2 节中应用程序 API 或微服务的实现还容许在网络事件循环和异步传出事件循环上并行执行工作，从而进步了可扩展性。
最初，宽列存储（如 Cassandra）和键值对象存储（如 ElasticSearch）还提供了高可用性和高可扩展性，同时没有单点故障。
总结
本文钻研描述了 Netflix 流服务的整体云架构图景，另外还从可用性、提早、可扩展性和对网络故障或零碎中断的适应性方面剖析了相应的设计指标。
总体来说，Netflix 的云架构曾经过了其生产零碎的验证，能够为在数千个虚构服务器上运行的数百万个订户提供服务；该架构还通过与 AWS 云服务的集成在寰球范畴内提供了高可用性、最佳提早、弱小的可扩展性以及对网络故障和系统故障的恢复能力。
本文提到的大多数架构和组件都是通过互联网上的可信在线资源学习总结进去的。只管网上没有太多资源能间接介绍这些微服务的外部实现，以及监督其性能体现的工具和零碎，但本文的研究成果能够作为构建典型生产零碎的参考实现。
举荐
- 十分钟入门 RocketMQ
- Spring Boot 构建多租户 SaaS 平台核心技术指南
- Redis 缓存和 MySQL 数据一致性计划详解
- Nginx 限流配置
- 深刻探秘 Netty、Kafka 中的零拷贝技术！
学习材料分享
12 套 微服务、Spring Boot、Spring Cloud 核心技术材料，这是局部材料目录：
- Spring Security 认证与受权
- Spring Boot 我的项目实战（中小型互联网公司后盾服务架构与运维架构）
- Spring Boot 我的项目实战（企业权限治理我的项目））
- Spring Cloud 微服务架构我的项目实战（分布式事务解决方案）
- …
公众号后盾回复
arch028获取材料：：