1 概述

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

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

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

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

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

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

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

2 架構(gòu)

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

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

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

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

• 可擴展計算實例（AWS EC2）

• 可擴展存儲（AWS S3）

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

• 可擴展的分布式數(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ò)，已針對存儲和流傳輸大尺寸視頻進行了優(yōu)化。這些 OCA 服務(wù)器放置在世界各地的互聯(lián)網(wǎng)服務(wù)提供商（ISP）和互聯(lián)網(wǎng)交換位置（IXP）網(wǎng)絡(luò)內(nèi)。OCA 負(fù)責(zé)將視頻直接流傳輸?shù)娇蛻舳恕?/span>

2.1 Playback 架構(gòu)

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

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

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

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

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

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

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

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

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

2.2 后端架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

3  組件

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

3.1 客戶端

Netflix 技術(shù)團隊投入了大量精力來開發(fā)能在筆記本、臺式機或移動設(shè)備上運行得更快、更智能的客戶端應(yīng)用。即使在某些沒有專用 Netflix 客戶端的智能電視上，Netflix 仍然可以通過自己提供的 SDK 來控制設(shè)備的性能表現(xiàn)。實際上，任何設(shè)備環(huán)境都需要安裝 Netflix Ready Device Platform（NRDP），以實現(xià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ù)器，以獲得更好的觀看體驗。之所以客戶端能實現(xiàn)所有這些目標(biāo)，是因為其上的 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 實例上，以提高 Netflix 服務(wù)的可用性。圖 4 展示了開源的 Zuul，這是 Netflix 團隊創(chuàng)建的 API 網(wǎng)關(guān)的實現(xiàn)。

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

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

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

• 出站過濾器（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ù)端點上，等等。

 

應(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 團隊花了很多時間設(shè)計應(yīng)用程序 API 組件，因為它對應(yīng) Netflix 的核心業(yè)務(wù)功能。它還需要在高請求量下具有可擴展和高可用性。當(dāng)前，應(yīng)用程序 API 分為三類：用于非會員請求（例如注冊、下單和免費試用等）的注冊（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 實現(xiàn)的最新更新中，播放 API 和微服務(wù)之間的網(wǎng)絡(luò)協(xié)議是 gRPC/HTTP2，它“允許通過協(xié)議緩沖區(qū)定義 RPC 方法和實體，并自動以多種語言生成客戶端庫 /SDK”。此項更改使應(yīng)用程序 API 可以通過雙向通信與自動生成的客戶端進行適當(dāng)集成，并“盡可能減少跨服務(wù)邊界的代碼重用”。

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

由于應(yīng)用程序 API 必須處理大量請求并構(gòu)造適當(dāng)?shù)捻憫?yīng)，因此其內(nèi)部處理工作需要高度并行運行。Netflix 團隊發(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 運行。一旦調(diào)用的微服務(wù)完成或超時，上述專用線程將構(gòu)造對應(yīng)的響應(yīng)。

 

微服務(wù)

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

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

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

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

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

• 每個微服務(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ù)存儲，可處理大量讀取請求，而沒有單點故障。為了優(yōu)化大規(guī)模寫請求的延遲，Netflix 使用了 Cassandra，因為它具有最終的一致性能力。

 

流處理管道

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

Netflix 的 Keystone 流處理平臺

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

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

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

  
  

3.3 Open Connect

Open Connect 是一個全球內(nèi)容交付網(wǎng)絡(luò)（CDN），負(fù)責(zé)存儲 Netflix 電視節(jié)目和電影并將其交付給全世界的訂戶。Netflix 為了讓人們想要觀看的內(nèi)容盡可能靠近他們想要觀看的位置，而構(gòu)建和運營了 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)交換點（IX 或 IXP）合作，以在這些合作伙伴的網(wǎng)絡(luò)內(nèi)部部署稱為 Open Connect Appliances（OCA）的專用設(shè)備。

將 OCA 部署到 IX 或 ISP 站點

OCA 是經(jīng)過優(yōu)化的服務(wù)器，用于存儲來自 IX 或 ISP 站點的大型視頻文件，并直接流式傳輸?shù)接啈舻募抑?。這些服務(wù)器會定期向 AWS 上的 Open Connect 控制平面（Control Plane）服務(wù)報告自己的運行狀況指標(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 站點上的 OCA 服務(wù)器上。這些 OCA 服務(wù)器將應(yīng)用緩存填充（cache fill），將這些文件傳輸?shù)狡渥泳W(wǎng)下 ISP 站點上的 OCA 服務(wù)器上。

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

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

  OCA 之間的填充模式

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

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

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

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

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

• 支持高請求量的可擴展性。

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

4.1 高可用性

根據(jù)定義，系統(tǒng)的可用性是用一段時間內(nèi)對請求的響應(yīng)有多少次來衡量的，但不能保證響應(yīng)包含了信息的最新版本。在我們的系統(tǒng)設(shè)計中，流服務(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)用所花費的時間超出預(yù)期，則它可以使用緩存中的數(shù)據(jù)響應(yīng)播放 AI。

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

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

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

4.2 低延遲

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

正如我在應(yīng)用程序 API 組件部分中所述，播放 API 不會永遠(yuǎn)等待微服務(wù)的執(zhí)行，因為它使用 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īng)做出了兩個重要的權(quán)衡：

• 用一致性換取低延遲

• 用一致性換取高可用性

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

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

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

6 彈性

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

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

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

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

連接到實例或服務(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)故障并將故障點與其他服務(wù)隔離開來。

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

7 可擴展性

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

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

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

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

8 總結(jié)

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

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

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

作者：Cao Duc Nguyen

來源：https://medium.com/swlh/a-design-analysis-of-cloud-based-microservices-architecture-at

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝