點(diǎn)擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

后臺回復(fù)"書"，獲取

來源：22j.co/dz54

1?概述

數(shù)年來，Netflix 一直是全球體驗(yàn)最好的在線訂閱制視頻流媒體服務(wù)，其流量占全球互聯(lián)網(wǎng)帶寬容量的 15％以上。?在過去的2019 年，Netflix 已經(jīng)有 1.67 億名訂閱用戶，平均每個季度新增 500 萬訂戶，服務(wù)覆蓋全球 200 多個國家 / 地區(qū)。

Netflix 用戶每天在 4000 多部電影和 47000 集電視劇上花費(fèi)超過 1.65 億小時的時間。從工程角度看，這些統(tǒng)計(jì)數(shù)據(jù)向我們展示了 Netflix 的技術(shù)團(tuán)隊(duì)設(shè)計(jì)出了多么優(yōu)秀的視頻流系統(tǒng)，而這套系統(tǒng)具有很高的可用性和可擴(kuò)展性，能為全球用戶提供服務(wù)。

實(shí)際上，Netflix的技術(shù)團(tuán)隊(duì)是花了超過 8 年時間方打造出今天這樣強(qiáng)大的 IT 系統(tǒng)。

實(shí)Netflix 的基礎(chǔ)架構(gòu)轉(zhuǎn)型始于 2008 年 8 月，那時這家公司的數(shù)據(jù)中心遇到了Web服務(wù)中斷的故障，導(dǎo)致整個 DVD 租賃服務(wù)關(guān)閉3天，損失較大。Netflix 的技術(shù)團(tuán)隊(duì)如夢方醒，它需要一個沒有單點(diǎn)故障的更可靠的基礎(chǔ)架構(gòu)。因此技術(shù)團(tuán)隊(duì)管理層做出兩個重要決定，將 IT 基礎(chǔ)架構(gòu)從自己的IDC遷移到公共云上，通過改造成微服務(wù)架構(gòu)，用較小的易管理軟件組件替換單體程序。

以上這兩個決定為今天 Netflix 的成功打下了堅(jiān)實(shí)基礎(chǔ)。

Netflix 之所以選擇 AWS 云來遷移其 IT 基礎(chǔ)架構(gòu)，是由于 AWS 可以在全球范圍內(nèi)提供高度可靠的數(shù)據(jù)庫、大規(guī)模云存儲和眾多數(shù)據(jù)中心。Netflix 利用了由 AWS 構(gòu)建和維護(hù)的云基礎(chǔ)架構(gòu)，從而免去自建數(shù)據(jù)中心的繁重重復(fù)勞動，并將更多精力放在提供高質(zhì)量視頻流體驗(yàn)的核心業(yè)務(wù)上。盡管 Netflix 需要重構(gòu)整個技術(shù)體系，以使其能在 AWS 云上平穩(wěn)運(yùn)行，但作為回報，系統(tǒng)的可擴(kuò)展性和服務(wù)可用性得到明顯地提高。

Netflix 還是微服務(wù)架構(gòu)背后的首批主要推動者之一。微服務(wù)鼓勵關(guān)注點(diǎn)分離來解決單體軟件設(shè)計(jì)存在的問題。在這種架構(gòu)中，大型程序通過模塊化和獨(dú)立的數(shù)據(jù)封裝被分解為許多較小的軟件組件。微服務(wù)還通過水平擴(kuò)展和工作負(fù)載分區(qū)來提升可擴(kuò)展性。采用微服務(wù)后，Netflix 工程師可以輕松更改任何服務(wù)，從而加快部署速度。更重要的是，他們能跟蹤每個服務(wù)的性能水平，并在其出現(xiàn)問題時與其他正在運(yùn)行的服務(wù)快速隔離開來。

2 架構(gòu)

Netflix 基于亞馬遜云計(jì)算服務(wù)（AWS云），及公司內(nèi)部的內(nèi)容交付網(wǎng)絡(luò)：Open Connect 運(yùn)營。兩套系統(tǒng)必須無縫協(xié)作才能在全球范圍內(nèi)提供高質(zhì)量的視頻流服務(wù)。

從軟件架構(gòu)的角度來看，Netflix 包括三大部分：客戶端、后端和內(nèi)容交付網(wǎng)絡(luò)（CDN）。

客戶端是用戶筆記本電腦或臺式機(jī)上所有受支持的瀏覽器，或者智能手機(jī) / 智能電視上的 Netflix 應(yīng)用。Netflix 開發(fā)了自己的 iOS 和 Android 應(yīng)用，試圖為每個客戶端和每臺設(shè)備都能提供最佳的觀看體驗(yàn)。Netflix 可以通過其 SDK 控制自己的應(yīng)用和其他設(shè)備，從而在某些場景下（例如網(wǎng)絡(luò)速度緩慢或服務(wù)器超載）透明地調(diào)整流服務(wù)。

后端包括完全在 AWS 云上運(yùn)行的服務(wù)、數(shù)據(jù)庫和存儲。后端基本上可以處理不涉及流視頻的所有內(nèi)容。后端的某些組件及其對應(yīng)的 AWS 服務(wù)列舉如下：

• 可擴(kuò)展計(jì)算實(shí)例（AWS EC2）

• 可擴(kuò)展存儲（AWS S3）

• 業(yè)務(wù)邏輯微服務(wù)（Netflix 專用框架）

• 可擴(kuò)展的分布式數(shù)據(jù)庫（AWS DynamoDB、Cassandra）

• 大數(shù)據(jù)處理和分析作業(yè)（AWS EMR、Hadoop、Spark、Flink、Kafka 和一些 Netflix 專用工具）

• 視頻處理和轉(zhuǎn)碼（Netflix 專用工具）

Open Connect CDN 是稱為 Open Connect Appliances（OCAs）的服務(wù)器網(wǎng)絡(luò)，已針對存儲和流傳輸大尺寸視頻進(jìn)行了優(yōu)化。這些 OCA 服務(wù)器放置在世界各地的互聯(lián)網(wǎng)服務(wù)提供商（ISP）和互聯(lián)網(wǎng)交換位置（IXP）網(wǎng)絡(luò)內(nèi)。OCA 負(fù)責(zé)將視頻直接流傳輸?shù)娇蛻舳恕?/p>

2.1 Playback 架構(gòu)

當(dāng)訂閱者單擊應(yīng)用或設(shè)備上的播放按鈕時，客戶端將與 AWS 上的后端和 Netflix CDN 上的 OCA 對話以流傳輸視頻。下圖說明了 playback 流程的工作機(jī)制：

用于流視頻的 playback 架構(gòu)：

OCA 不斷將關(guān)于其負(fù)載狀態(tài)、可路由性和可用視頻的運(yùn)行狀況報告發(fā)送到在 AWS EC2 中運(yùn)行的緩存控制（Cache Control）服務(wù)上，以便 Playback 應(yīng)用向客戶端更新最新的健康 OCA。

播放（Play）請求從客戶端設(shè)備發(fā)送到在 AWS EC2 上運(yùn)行的 Netflix 播放應(yīng)用服務(wù)，以獲取流視頻的 URL。

Playback 應(yīng)用服務(wù)必須確定播放請求是有效的，才能觀看特定視頻。這里的驗(yàn)證流程將檢查用戶的訂閱計(jì)劃，以及在不同國家 / 地區(qū)的視頻許可等。

Playback 應(yīng)用服務(wù)會與同在 AWS EC2 中運(yùn)行的引導(dǎo)（Steering) 服務(wù)對話，以獲取所請求視頻的合適的 OCA 服務(wù)器列表。引導(dǎo)服務(wù)使用客戶端的 IP 地址和 ISP 信息來確定一組最適合該客戶端的 OCA。

客戶端從 Playback 應(yīng)用服務(wù)返回的 10 個 OCA 服務(wù)器的列表中測試這些 OCA 的網(wǎng)絡(luò)連接質(zhì)量，并選擇最快、最可靠的 OCA 來請求視頻文件，進(jìn)行流傳輸。

選定的 OCA 服務(wù)器接受來自客戶端的請求并開始流傳輸視頻。

在上圖中，Playback 應(yīng)用服務(wù)、引導(dǎo)服務(wù)和緩存控制服務(wù)完全在基于微服務(wù)架構(gòu)的 AWS 云中運(yùn)行。在下一節(jié)中我將介紹 Netflix 后端微服務(wù)架構(gòu)，該架構(gòu)可提高當(dāng)前服務(wù)的可用性和可擴(kuò)展性。

2.2 后端架構(gòu)

如前所述，后端要處理幾乎所有內(nèi)容，從注冊、登錄、計(jì)費(fèi)到更復(fù)雜的處理任務(wù)，如視頻轉(zhuǎn)碼和個性化推薦等無所不包。為同時支持在同一底層基礎(chǔ)架構(gòu)上運(yùn)行的輕量與重量級負(fù)載，Netflix 為其基于云的系統(tǒng)選擇了微服務(wù)架構(gòu)。圖 2 展示了 Netflix 可能使用的微服務(wù)架構(gòu)，我從一些在線資源中總結(jié)出了這些架構(gòu)形態(tài)：

基于多種來源分析得出的后端架構(gòu)參考

客戶端向在 AWS 上運(yùn)行的后端發(fā)送一個播放請求。該請求由 AWS 負(fù)載均衡器（ELB）處理。

AWS ELB 會將請求轉(zhuǎn)發(fā)到在 AWS EC2 實(shí)例上運(yùn)行的 API 網(wǎng)關(guān)服務(wù)上。名為 Zuul 的組件是由 Netflix 團(tuán)隊(duì)構(gòu)建的，提供動態(tài)路由、流量監(jiān)控和安全性，以及對云部署邊緣故障的恢復(fù)能力。該請求將應(yīng)用在與業(yè)務(wù)邏輯對應(yīng)的一些預(yù)定義過濾器上，然后轉(zhuǎn)發(fā)到應(yīng)用程序（Application）API 做進(jìn)一步處理。

應(yīng)用程序 API 組件是 Netflix 運(yùn)營背后的核心業(yè)務(wù)邏輯。有幾種類型的 API 對應(yīng)不同的用戶活動，如注冊 API 和用于檢索視頻推薦的推薦 API 等。在這里，來自 API 網(wǎng)關(guān)服務(wù)的轉(zhuǎn)發(fā)請求由播放 API 處理。

播放 API 將調(diào)用一個或一系列微服務(wù)來滿足請求。圖 1 中的播放應(yīng)用服務(wù)、引導(dǎo)服務(wù)和緩存控制服務(wù)可以視為微服務(wù)。

微服務(wù)主要是無狀態(tài)的小型程序，并且也可以相互調(diào)用。為了控制其級聯(lián)故障并獲得彈性， Hystrix 將每個微服務(wù)與調(diào)用者進(jìn)程隔離開來。其運(yùn)行結(jié)果可以緩存在基于內(nèi)存的緩存中，以更快地訪問那些關(guān)鍵的低延遲請求。

微服務(wù)能在流程中保存到數(shù)據(jù)存儲或從數(shù)據(jù)存儲中獲取數(shù)據(jù)。

微服務(wù)可以將用于跟蹤用戶活動或其他數(shù)據(jù)的事件發(fā)送到流處理管道（Stream Processing Pipeline），以實(shí)時處理個性化推薦任務(wù)，或批處理業(yè)務(wù)智能任務(wù)。

來自流處理管道的數(shù)據(jù)能持久存儲到其他數(shù)據(jù)存儲中，如 AWS S3、Hadoop HDFS 和 Cassandra 等。

上述架構(gòu)可以幫助我們概括了解系統(tǒng)的各個部分如何組織和協(xié)同工作以流傳輸視頻。但要分析這一架構(gòu)的可用性和可擴(kuò)展性，我們需要深入研究每個重要組件，以了解其在不同負(fù)載下的性能表現(xiàn)。下一節(jié)將具體介紹這部分內(nèi)容。

3? 組件

本節(jié)會深入研究第 2 節(jié)中定義的組件，以分析其可用性和可擴(kuò)展性。在介紹每個組件時，我還將說明它們是如何滿足這些設(shè)計(jì)目標(biāo)的。在后面的章節(jié)中將對整個系統(tǒng)進(jìn)行更深入的設(shè)計(jì)分析。

3.1 客戶端

Netflix 技術(shù)團(tuán)隊(duì)投入了大量精力來開發(fā)能在筆記本、臺式機(jī)或移動設(shè)備上運(yùn)行得更快、更智能的客戶端應(yīng)用。即使在某些沒有專用 Netflix 客戶端的智能電視上，Netflix 仍然可以通過自己提供的 SDK 來控制設(shè)備的性能表現(xiàn)。實(shí)際上，任何設(shè)備環(huán)境都需要安裝 Netflix Ready Device Platform（NRDP），以實(shí)現(xiàn)最佳的觀看體驗(yàn)。圖 3 展示了一個典型的客戶端結(jié)構(gòu)組件。

客戶端應(yīng)用組件

• 客戶端應(yīng)用（Client App）會將自己與后端的連接分為 2 種類型，分別用于內(nèi)容發(fā)現(xiàn)（Content discovery）和內(nèi)容播放。客戶端對播放請求使用 NTBA 協(xié)議，以確保其 OCA 服務(wù)器位置具有更高的安全性，并消除了新連接的 SSL/TLS 握手引起的延遲。

• 在流傳輸視頻時，如果網(wǎng)絡(luò)連接過載或出現(xiàn)錯誤，客戶端應(yīng)用會智能地降低視頻質(zhì)量或切換到其他 OCA 服務(wù)器上。即使連接的 OCA 過載或出現(xiàn)故障，客戶端應(yīng)用也可以輕松切換為其他 OCA 服務(wù)器，以獲得更好的觀看體驗(yàn)。之所以客戶端能實(shí)現(xiàn)所有這些目標(biāo)，是因?yàn)槠渖系?Netflix Platform SDK 一直在跟蹤從播放應(yīng)用服務(wù)中檢索到的最新健康 OCA 列表。

3.2 后端

?API 網(wǎng)關(guān)服務(wù)

API 網(wǎng)關(guān)服務(wù)（API Gateway Service）組件與 AWS 負(fù)載均衡器（Load Balancer）通信以解析來自客戶端的所有請求。該組件可以部署到位于不同區(qū)域的多個 AWS EC2 實(shí)例上，以提高 Netflix 服務(wù)的可用性。圖 4 展示了開源的 Zuul，這是 Netflix 團(tuán)隊(duì)創(chuàng)建的 API 網(wǎng)關(guān)的實(shí)現(xiàn)。

Zuul 網(wǎng)關(guān)服務(wù)組件

• 入站過濾器（Inbound Filter）可用于身份驗(yàn)證、路由和裝飾請求。

• 端點(diǎn)過濾器（Endpoint Filter）可用于返回靜態(tài)資源或?qū)⒄埱舐酚傻竭m當(dāng)?shù)?Origin 或應(yīng)用程序 API 做進(jìn)一步處理。

• 出站過濾器（Outbound Filter）可用于跟蹤指標(biāo)、裝飾對用戶的響應(yīng)或添加自定義標(biāo)頭。

• Zuul 集成了服務(wù)發(fā)現(xiàn)組件 Eureka ，從而能夠發(fā)現(xiàn)新的應(yīng)用程序 API。

• Zuul 被廣泛用于各種用途的流量路由任務(wù)上，例如啟用新的應(yīng)用程序 API、負(fù)載測試、在負(fù)載很大的情況下路由到不同的服務(wù)端點(diǎn)上，等等。

?

應(yīng)用程序 API

應(yīng)用程序 API 充當(dāng) Netflix 微服務(wù)的業(yè)務(wù)流程層（也稱編排層）。這種 API 提供了一種邏輯，按所需順序組裝對底層微服務(wù)的調(diào)用，并帶有來自其他數(shù)據(jù)存儲的額外數(shù)據(jù)以構(gòu)造適當(dāng)?shù)捻憫?yīng)。Netflix 團(tuán)隊(duì)花了很多時間設(shè)計(jì)應(yīng)用程序 API 組件，因?yàn)樗鼘?yīng) Netflix 的核心業(yè)務(wù)功能。它還需要在高請求量下具有可擴(kuò)展和高可用性。當(dāng)前，應(yīng)用程序 API 分為三類：用于非會員請求（例如注冊、下單和免費(fèi)試用等）的注冊（Signup）API，用于搜索和發(fā)現(xiàn)請求的發(fā)現(xiàn)（Discovery）API，以及用于流視頻和查看許可請求的播放 API。圖 5 提供了應(yīng)用程序 API 的詳細(xì)結(jié)構(gòu)組件圖。

播放和發(fā)現(xiàn)應(yīng)用程序 API 的分離

• 在播放 API 實(shí)現(xiàn)的最新更新中，播放 API 和微服務(wù)之間的網(wǎng)絡(luò)協(xié)議是 gRPC/HTTP2，它“允許通過協(xié)議緩沖區(qū)定義 RPC 方法和實(shí)體，并自動以多種語言生成客戶端庫 /SDK”。此項(xiàng)更改使應(yīng)用程序 API 可以通過雙向通信與自動生成的客戶端進(jìn)行適當(dāng)集成，并“盡可能減少跨服務(wù)邊界的代碼重用”。

• 應(yīng)用程序 API 還提供了一種基于 Hystrix 命令的通用彈性機(jī)制，以保護(hù)其底層微服務(wù)。

由于應(yīng)用程序 API 必須處理大量請求并構(gòu)造適當(dāng)?shù)捻憫?yīng)，因此其內(nèi)部處理工作需要高度并行運(yùn)行。Netflix 團(tuán)隊(duì)發(fā)現(xiàn)正確的方法是同步執(zhí)行和異步 I/O 相結(jié)合應(yīng)用。

應(yīng)用程序 API 的同步執(zhí)行和異步 I/O

• 來自 API 網(wǎng)關(guān)服務(wù)的每個請求都將放入應(yīng)用程序 API 的網(wǎng)絡(luò)事件循環(huán)（Network Event Loop）中處理；

• 每個請求將被一個專用的線程處理程序阻止，該處理程序?qū)?Hystrix 命令（如 getCustomerInfo 和 getDeviceInfo 等）放入傳出事件循環(huán)（Outgoing Event Loop）中。傳出事件循環(huán)是針對每個客戶端設(shè)置的，并以非阻塞 I/O 運(yùn)行。一旦調(diào)用的微服務(wù)完成或超時，上述專用線程將構(gòu)造對應(yīng)的響應(yīng)。

?

微服務(wù)

按照 Martin Fowler 的定義，“微服務(wù)是一組小型服務(wù)，每個小服務(wù)都在自己的進(jìn)程中運(yùn)行，并使用輕量機(jī)制通信……”。這些小型程序可以獨(dú)立部署或升級，并具有自己的封裝數(shù)據(jù)。

Netflix 上的微服務(wù)組件實(shí)現(xiàn)如圖 7 所示。

微服務(wù)的結(jié)構(gòu)化組件

• 微服務(wù)可以獨(dú)立工作，也能通過 REST 或 gRPC 調(diào)用其他微服務(wù)。

• 微服務(wù)的實(shí)現(xiàn)可以類似于圖 6 中描述的應(yīng)用程序 API 的實(shí)現(xiàn)：請求將被放入網(wǎng)絡(luò)事件循環(huán)中，而來自其他被調(diào)用的微服務(wù)的結(jié)果將放入異步非阻塞 I/O 中的結(jié)果隊(duì)列。

• 每個微服務(wù)能擁有自己的數(shù)據(jù)存儲和一些存放近期結(jié)果的內(nèi)存緩存存儲。EVCache 是Netflix 微服務(wù)緩存的主要選擇。

?

數(shù)據(jù)存儲

Netflix 將其基礎(chǔ)架構(gòu)遷移到 AWS 云時，針對不同的用途使用了不同的數(shù)據(jù)存儲（圖 8），包括 SQL 和 NoSQL。

部署在 AWS 上的 Netflix 數(shù)據(jù)存儲

• MySQL 數(shù)據(jù)庫用于電影標(biāo)題管理和交易 / 下單目的。

• Hadoop 用于基于用戶日志的大數(shù)據(jù)處理。

• ElasticSearch 為 Netflix 應(yīng)用提供了標(biāo)題搜索能力。

• Cassandra 是基于列的分布式 NoSQL 數(shù)據(jù)存儲，可處理大量讀取請求，而沒有單點(diǎn)故障。為了優(yōu)化大規(guī)模寫請求的延遲，Netflix 使用了 Cassandra，因?yàn)樗哂凶罱K的一致性能力。

?

流處理管道

流處理數(shù)據(jù)管道（Stream Processing Data Pipeline）已成為 Netflix 業(yè)務(wù)分析和個性化推薦任務(wù)的數(shù)據(jù)骨干。它負(fù)責(zé)實(shí)時生成、收集、處理和匯總所有微服務(wù)事件，并將其移動到其他數(shù)據(jù)處理器上。圖 9 展示了該平臺的各個部分。

Netflix 的 Keystone 流處理平臺

• 這一流處理平臺每天處理數(shù)以萬億計(jì)的事件和 PB 級的數(shù)據(jù)。隨著訂戶數(shù)量的增加，它也會自動擴(kuò)展。

• 路由（Router）模塊支持路由到不同的數(shù)據(jù) sink 或應(yīng)用程序上，而 Kafka 負(fù)責(zé)路由消息，并為下游系統(tǒng)提供緩沖。

• 流處理即服務(wù)（SPaaS）使數(shù)據(jù)工程師可以構(gòu)建和監(jiān)視他們自定義的可管理流處理應(yīng)用程序，而平臺將負(fù)責(zé)可擴(kuò)展性和運(yùn)維。

3.3 Open Connect

Open Connect 是一個全球內(nèi)容交付網(wǎng)絡(luò)（CDN），負(fù)責(zé)存儲 Netflix 電視節(jié)目和電影并將其交付給全世界的訂戶。Netflix 為了讓人們想要觀看的內(nèi)容盡可能靠近他們想要觀看的位置，而構(gòu)建和運(yùn)營了 Open Connect 這一高效率的網(wǎng)絡(luò)。為了將觀看 Netflix 視頻的流量導(dǎo)向到客戶的當(dāng)?shù)鼐W(wǎng)絡(luò)中，Netflix 已與世界各地的互聯(lián)網(wǎng)服務(wù)提供商（ISP）和互聯(lián)網(wǎng)交換點(diǎn)（IX 或 IXP）合作，以在這些合作伙伴的網(wǎng)絡(luò)內(nèi)部部署稱為 Open Connect Appliances（OCA）的專用設(shè)備。

將 OCA 部署到 IX 或 ISP 站點(diǎn)

OCA 是經(jīng)過優(yōu)化的服務(wù)器，用于存儲來自 IX 或 ISP 站點(diǎn)的大型視頻文件，并直接流式傳輸?shù)接啈舻募抑小＿@些服務(wù)器會定期向 AWS 上的 Open Connect 控制平面（Control Plane）服務(wù)報告自己的運(yùn)行狀況指標(biāo)，包括它們從 IXP/ISP 網(wǎng)絡(luò)學(xué)到的最佳路徑，以及自己的 SSD 上都存儲了哪些視頻等信息。反過來，控制平面服務(wù)將根據(jù)這些數(shù)據(jù)中反映的文件可用性、服務(wù)器健康狀況以及與客戶端的網(wǎng)絡(luò)距離等指標(biāo)，自動引導(dǎo)客戶端設(shè)備到最佳的 OCA 上。

控制平面服務(wù)還控制每晚在 OCA 上添加新文件或更新文件的填充（filling）行為。填充行為如圖 11 所示。

• 當(dāng)新的視頻文件已成功轉(zhuǎn)碼并存儲在 AWS S3 上時，AWS 上的控制平面服務(wù)會將這些文件傳輸?shù)?IXP 站點(diǎn)上的 OCA 服務(wù)器上。這些 OCA 服務(wù)器將應(yīng)用緩存填充（cache fill），將這些文件傳輸?shù)狡渥泳W(wǎng)下 ISP 站點(diǎn)上的 OCA 服務(wù)器上。

• 當(dāng) OCA 服務(wù)器成功存儲視頻文件后，它將能夠啟用對等填充（peer fill），以根據(jù)需要將這些文件復(fù)制到同一站點(diǎn)內(nèi)的其他 OCA 服務(wù)器上。

• 在可以看到彼此 IP 地址的 2 個不同站點(diǎn)之間，OCA 可以應(yīng)用層填充（tier fill）流程，而不是常規(guī)的緩存填充。

  OCA 之間的填充模式

4 設(shè)計(jì)目標(biāo)

在前面的章節(jié)中，我詳細(xì)介紹了為 Netflix 視頻流業(yè)務(wù)提供支持的云架構(gòu)及其組件。在本節(jié)和后續(xù)章節(jié)中，我想更深入地分析這種設(shè)計(jì)架構(gòu)。我會從最重要的設(shè)計(jì)目標(biāo)列表開始，如下所示：

• 確保全球范圍內(nèi)流服務(wù)的高可用性。

• 彈性處理網(wǎng)絡(luò)故障和系統(tǒng)中斷。

• 在各種網(wǎng)絡(luò)條件下，將每臺受支持設(shè)備的流傳輸延遲降至最低。

• 支持高請求量的可擴(kuò)展性。

在下面的小節(jié)中，我將分析流服務(wù)的可用性及其對應(yīng)的最佳延遲。第 6 節(jié)是關(guān)于彈性機(jī)制（例如混沌工程）的更深入分析，而第 7 節(jié)介紹了流服務(wù)的可擴(kuò)展性。

4.1 高可用性

根據(jù)定義，系統(tǒng)的可用性是用一段時間內(nèi)對請求的響應(yīng)有多少次來衡量的，但不能保證響應(yīng)包含了信息的最新版本。在我們的系統(tǒng)設(shè)計(jì)中，流服務(wù)的可用性是由后端服務(wù)和保存流視頻文件的 OCA 服務(wù)器的可用性共同決定的。

后端服務(wù)的目標(biāo)是通過緩存或某些微服務(wù)的執(zhí)行來獲取最接近特定客戶端的健康 OCA 列表。因此，其可用性取決于涉及播放請求的眾多組件：負(fù)載均衡器（AWS ELB）_ 代理服務(wù)器（API 網(wǎng)關(guān)服務(wù)）、播放 API、微服務(wù)的執(zhí)行、緩存存儲（EVCache）和數(shù)據(jù)存儲（Cassandra）：

• 負(fù)載均衡器可以將流量路由到不同的代理服務(wù)器上以幫助防止負(fù)載超載，從而提高可用性。

• 播放 API 通過 Hystrix 命令控制超時微服務(wù)的執(zhí)行，從而防止級聯(lián)故障影響其他服務(wù)。

• 如果微服務(wù)對外部服務(wù)或數(shù)據(jù)存儲的調(diào)用所花費(fèi)的時間超出預(yù)期，則它可以使用緩存中的數(shù)據(jù)響應(yīng)播放 AI。

• 緩存會被復(fù)制以加快訪問速度。

當(dāng)客戶端從后端接收到 OCA 服務(wù)器列表時會在網(wǎng)絡(luò)上探測這些 OCA，并選擇最佳的 OCA 進(jìn)行連接。如果該 OCA 在流處理過程中超載或失敗，則客戶端將切換到另一個狀態(tài)良好的 OCA 上，否則 Platform SDK 將請求其他 OCA。因此，其可用性與 ISP 或 IXP 中所有可用 OCA 的可用性高度相關(guān)。

Netflix 流服務(wù)的高可用性是以復(fù)雜的多區(qū)域 AWS 運(yùn)維和服務(wù)，以及 OCA 服務(wù)器的冗余為代價的。

4.2 低延遲

流服務(wù)的等待時間主要取決于播放 API 能多快地解析健康的 OCA 列表，以及客戶端與所選 OCA 服務(wù)器的連接健康水平。

正如我在應(yīng)用程序 API 組件部分中所述，播放 API 不會永遠(yuǎn)等待微服務(wù)的執(zhí)行，因?yàn)樗褂?Hystrix 命令來控制獲取到結(jié)果之前要等待的時間，一旦超時就會從緩存獲取非最新數(shù)據(jù)。這樣做可以將延遲控制在可接受的水平上，還能避免級聯(lián)故障影響更多服務(wù)。

如果當(dāng)前選定的 OCA 服務(wù)器出現(xiàn)網(wǎng)絡(luò)故障或超載，則客戶端將立即切換到其他具有最可靠網(wǎng)絡(luò)連接的 OCA 服務(wù)器上。如果發(fā)現(xiàn)網(wǎng)絡(luò)連接質(zhì)量下降，它也可以降低視頻質(zhì)量以使其與網(wǎng)絡(luò)質(zhì)量相匹配。

5 權(quán)衡

經(jīng)過認(rèn)真考慮，在上述系統(tǒng)設(shè)計(jì)中已經(jīng)做出了兩個重要的權(quán)衡：

• 用一致性換取低延遲

• 用一致性換取高可用性

該系統(tǒng)后端服務(wù)的架構(gòu)設(shè)計(jì)選擇了用一致性來換取低延遲。播放 API 可以從 EVCache 存儲或最終一致的數(shù)據(jù)存儲（如 Cassandra）中獲取過時的數(shù)據(jù)。

類似地，所謂用一致性換取高可用性的權(quán)衡是說，系統(tǒng)希望以可接受的延遲發(fā)起響應(yīng)，而不會對像 Cassandra 這樣的數(shù)據(jù)存儲中的最新數(shù)據(jù)執(zhí)行微服務(wù)。

在可擴(kuò)展性和性能之間還存在不完全相關(guān)的權(quán)衡。在這種權(quán)衡下，通過增加實(shí)例數(shù)量來處理更多負(fù)載來提高可擴(kuò)展性，可能會導(dǎo)致系統(tǒng)達(dá)不到預(yù)期的性能提升水平。對于那些無法在可用 worker 之間很好地平衡負(fù)載的設(shè)計(jì)架構(gòu)來說，這可能是個問題。但是，Netflix 通過 AWS 自動擴(kuò)展解決了這一矛盾。我們將在第 7 節(jié)中具體討論這個解決方案。

6 彈性

從遷移到 AWS 云的那一天起，設(shè)計(jì)一套能夠從故障或停機(jī)中自我恢復(fù)的云系統(tǒng)就一直是 Netflix 的長期目標(biāo)。該系統(tǒng)已解決的一些常見故障如下：

解析服務(wù)依賴項(xiàng)時失敗。

執(zhí)行微服務(wù)時的失敗，導(dǎo)致級聯(lián)失敗影響其他服務(wù)。

由于過載導(dǎo)致無法連接到某個 API 上。

連接到實(shí)例或服務(wù)器（如 OCA）時失敗。

為了檢測并解決這些故障，API 網(wǎng)關(guān)服務(wù) Zuul 提供了一些內(nèi)置功能，如自適應(yīng)重試和限制對應(yīng)用程序 API 的并發(fā)調(diào)用等。反過來說，應(yīng)用程序 API 使用 Hystrix 命令來使對微服務(wù)的調(diào)用超時，以停止級聯(lián)故障并將故障點(diǎn)與其他服務(wù)隔離開來。

Netflix 技術(shù)團(tuán)隊(duì)也以其在混沌工程上的實(shí)踐而聞名。這個想法是將偽隨機(jī)錯誤注入生產(chǎn)環(huán)境，并構(gòu)建解決方案以自動檢測、隔離這類故障，并從中恢復(fù)。這些錯誤可能會增加執(zhí)行微服務(wù)的響應(yīng)的延遲、殺死服務(wù)、停止服務(wù)器或?qū)嵗?#xff0c;甚至可能導(dǎo)致整個區(qū)域的基礎(chǔ)架構(gòu)癱瘓。通過有目的地使用檢測和解決此類故障的工具，將現(xiàn)實(shí)的生產(chǎn)故障引入受監(jiān)控的環(huán)境，Netflix 可以在這類缺陷造成較大問題之前提早發(fā)現(xiàn)它們。

7 可擴(kuò)展性

在本節(jié)中，我將介紹水平擴(kuò)展、并行執(zhí)行和數(shù)據(jù)庫分區(qū)這些 Netflix 的流服務(wù)可擴(kuò)展性要素。緩存和負(fù)載均衡等要素也有助于提高可擴(kuò)展性，它們已在第 4 節(jié)中提到了。

首先，AWS 自動擴(kuò)展（Auto Scaling）服務(wù)提供了 Netflix 上 EC2 實(shí)例的水平擴(kuò)展能力。當(dāng)請求量增加時，這個 AWS 服務(wù)將自動啟動更多彈性實(shí)例，并關(guān)閉未使用的實(shí)例。更具體地說，在成千上萬個此類實(shí)例的基礎(chǔ)上，Netflix 構(gòu)建了一個開源容器管理平臺 Titus，其每周可運(yùn)行約 300 萬個容器。同樣，圖 2 架構(gòu)中的任何組件都可以部署在容器內(nèi)。此外，Titus 允許容器運(yùn)行在全球各大洲的多個區(qū)域內(nèi)。

其次，第 3.2.2 節(jié)中應(yīng)用程序 API 或微服務(wù)的實(shí)現(xiàn)還允許在網(wǎng)絡(luò)事件循環(huán)和異步傳出事件循環(huán)上并行執(zhí)行任務(wù)，從而提高了可擴(kuò)展性。

最后，寬列存儲（如 Cassandra）和鍵值對象存儲（如 ElasticSearch）還提供了高可用性和高可擴(kuò)展性，同時沒有單點(diǎn)故障。

8 總結(jié)

本文研究描繪了 Netflix 流服務(wù)的整體云架構(gòu)圖景，另外還從可用性、延遲、可擴(kuò)展性和對網(wǎng)絡(luò)故障或系統(tǒng)中斷的適應(yīng)性方面分析了相應(yīng)的設(shè)計(jì)目標(biāo)。

總體來說，Netflix 的云架構(gòu)已經(jīng)過了其生產(chǎn)系統(tǒng)的驗(yàn)證，可以為在數(shù)千個虛擬服務(wù)器上運(yùn)行的數(shù)百萬個訂戶提供服務(wù)；該架構(gòu)還通過與 AWS 云服務(wù)的集成在全球范圍內(nèi)提供了高可用性、最佳延遲、強(qiáng)大的可擴(kuò)展性以及對網(wǎng)絡(luò)故障和系統(tǒng)故障的恢復(fù)能力。

本文提到的大多數(shù)架構(gòu)和組件都是通過互聯(lián)網(wǎng)上的可信在線資源學(xué)習(xí)總結(jié)出來的。盡管網(wǎng)上沒有太多資源能直接介紹這些微服務(wù)的內(nèi)部實(shí)現(xiàn)，以及監(jiān)視其性能表現(xiàn)的工具和系統(tǒng)，但本文的研究成果可以作為構(gòu)建典型生產(chǎn)系統(tǒng)的參考實(shí)現(xiàn)。

想知道更多？掃描下面的二維碼關(guān)注我后臺回復(fù)"技術(shù)"，加入技術(shù)群【精彩推薦】

• 超清晰的DNS入門指南

• 深入理解Java Stream流水線

• 干掉Swagger,試試這個

• 干掉GuavaCache：Caffeine才是本地緩存的王

• 如何用ELK搭建TB級的日志系統(tǒng)

• 深度好文：Linux系統(tǒng)內(nèi)存知識

• 日志系統(tǒng)新貴Loki，確實(shí)比笨重的ELK輕

• 日志采集系統(tǒng)都用到哪些技術(shù)？

• 面試官：為什么HashMap的加載因子是0.75？

• 原創(chuàng)|OpenAPI標(biāo)準(zhǔn)規(guī)范
  

點(diǎn)個贊+在看，少個 bug?????

總結(jié)

以上是生活随笔為你收集整理的深度好文：Netflix奈飞微服务架构设计解析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。