Netflix基于AWS架構(gòu)體系

Netflix是世界最大的收費(fèi)視頻網(wǎng)站，其整個架構(gòu)體系都是搭建在AWS之上，可以看做是一個云原生架構(gòu)。

同時相信大家都聽過SpringCloud體系下的一大撮Netflix相關(guān)的微服務(wù)組件，而了解Netflix是如何使用這些組件，對于進(jìn)一步掌握這些組件也很有必要。

先全局看下Netflix架構(gòu)：

架構(gòu)主要包含三部分：

1. Open Connect（Netflix CDN）；

2. 后臺；

3. 客戶端；

客戶端：定義為播放 Netflix 適配的用戶界面，如 TV、XBox、筆記本、智能手機(jī)。用戶點(diǎn)擊播放之后，任何功能都由 CDN 實現(xiàn)。

CND：是分布式服務(wù)器系統(tǒng)，根據(jù)用戶地理位置，網(wǎng)頁、服務(wù)器的起點(diǎn)。當(dāng) Netflix 的視頻被轉(zhuǎn)碼后，CDN 將 Netflix 視頻存儲到世界各地。

視頻播放流程

當(dāng)用戶打開Netflix應(yīng)用時，所有的請求都是由AWS來完成。譬如登錄，推薦，主頁，用戶歷史記錄和客服等。當(dāng)用戶點(diǎn)擊視頻的播放按鈕，Netflix應(yīng)用會自動判定最佳的Open Connect服務(wù)器，最好的格式和比特率，以便讓視頻從附近的OCA流暢地傳出。Netflix應(yīng)用相當(dāng)?shù)闹悄?，它能不間斷地尋找流媒體服務(wù)器和比特率，并自動替換到能為用戶帶來更好體驗的服務(wù)器。

ELB

Netflix對ELB進(jìn)行如下設(shè)置：首先是區(qū)域間的負(fù)載平衡，然后是實例間的負(fù)載平衡。這是因為ELB的設(shè)置是有兩級負(fù)載平衡方案：

1. 基于域名服務(wù)的循環(huán)負(fù)載平衡；

2. 同一區(qū)域內(nèi)多個負(fù)載實例平衡；

ZUUL

作為邊緣應(yīng)用網(wǎng)關(guān)，將所有設(shè)備、網(wǎng)站請求導(dǎo)向后臺的流媒體服務(wù)。

Zuul 實現(xiàn)了動態(tài)路由、監(jiān)控、彈性、安全。（基于 Netty 實現(xiàn)）。

Hystris

延遲與容錯代碼庫，可以防止級聯(lián)錯誤、實時監(jiān)控配置變動、基于并行請求緩存、基于請求崩潰自動批處理。

媒體處理

Netflix花費(fèi)很多時間驗證視頻。視頻驗證包括查找數(shù)字工件，顏色變化，由于前面轉(zhuǎn)碼步驟的數(shù)據(jù)丟失造成的幀丟失。在視頻被驗證后，就會被送入Netflix稱作的媒體管道。處理幾兆尺寸的一個文件并不現(xiàn)實，所以管道的第一步是把一個文件分割成若干個小塊。接下來視頻塊被接通到管道，這樣編碼會并行處理。

Archer

Archer是具有映射-規(guī)約風(fēng)格的媒體處理平臺。Archer使用容器，這使得用戶能夠處理操作系統(tǒng)級別的依賴性。該平臺可以進(jìn)行通常的媒體處理步驟。開發(fā)人員需要寫三個功能：分離，映射，收集。任何編程語言都可以使用。Archer創(chuàng)建的目的就是大規(guī)模進(jìn)行簡單媒體處理。這意味著平臺知道媒體格式，并給予流行媒體模式優(yōu)先處理。

微服務(wù)

Netflix使用微服務(wù)架構(gòu)來驅(qū)動所有的APIs。每個API調(diào)用其他的微服務(wù)來獲取所需的數(shù)據(jù)和提供響應(yīng)?？煽啃匀绾螌崿F(xiàn)呢？一是以來Hystris，第二是分離關(guān)鍵服務(wù)。

關(guān)鍵微服務(wù)

依照Netflix的設(shè)計，當(dāng)遇到級聯(lián)失敗時，至少用戶還可以點(diǎn)擊并播放推薦的視頻。實現(xiàn)這一功能的微服務(wù)被稱為關(guān)鍵微服務(wù)。關(guān)鍵微服務(wù)對其它服務(wù)沒有很多依賴性。

無狀態(tài)服務(wù)

Netflix的一個設(shè)計目標(biāo)是無狀態(tài)服務(wù)。也就是說任一服務(wù)器失敗的話都無關(guān)緊要。在失敗的情況下請求可以被路由到另外一服務(wù)實例，或者啟動一個新的服務(wù)器來取代失敗的服務(wù)器。

有狀態(tài)服務(wù)，數(shù)據(jù)庫（部署在EC2上的MySQL）

有狀態(tài)信息主要通過MySql存儲。基于主機(jī)的“同步復(fù)制協(xié)議”，確保主機(jī)上寫操作完成的定義是寫操作在主機(jī)和遠(yuǎn)程終端都完成。單個節(jié)點(diǎn)的數(shù)據(jù)丟失不會造成數(shù)據(jù)的丟失。ETL工作的讀流量被導(dǎo)向讀操作副本，以便于主數(shù)據(jù)庫免于繁重的批處理操作。在主數(shù)據(jù)庫失敗的情況下，故障轉(zhuǎn)移會在已經(jīng)有了復(fù)制的次節(jié)點(diǎn)上進(jìn)行。當(dāng)次節(jié)點(diǎn)能夠勝任主數(shù)據(jù)庫的工作時，route53上DNS的條目就會指向新的次節(jié)點(diǎn)。

KV緩存

當(dāng)一個節(jié)點(diǎn)失敗后，節(jié)點(diǎn)上的緩存也會跟著失敗，這樣就會有性能損失，除非所有數(shù)據(jù)都有緩存。Netflix的解決方案是使用KV緩存，一個基于Memcached的封裝。不是簡單的封裝，是有冗余度的分片集群。在存操作時，所有的分片都被更新。在讀操作的情況下，是從最近的緩存或節(jié)點(diǎn)讀取數(shù)據(jù)。當(dāng)最近的節(jié)點(diǎn)失敗，則會從其它的節(jié)點(diǎn)讀取。KV緩存每天能夠處理三千萬的請求，并具有毫秒級的線性擴(kuò)展性。

Cassandra

Cassandra用來存儲用戶的閱讀歷史數(shù)據(jù)的。Netflix的Cassandra集群也經(jīng)歷了重新設(shè)計。重新設(shè)計的理念是：更小的存儲，在用戶閱讀量增加情況下的一致的讀寫性能。對應(yīng)的解決方案就是：

1. 壓縮舊的數(shù)據(jù)。

2. 數(shù)據(jù)被分成兩類。

實時閱讀歷史（LiveVH）：頻繁被更新的少量的最近閱讀的數(shù)據(jù)，這部分?jǐn)?shù)據(jù)未被壓縮的形式存儲。

壓縮閱讀歷史（CompressedVH）：很少被更新的大量的舊的閱讀數(shù)據(jù)，這部分?jǐn)?shù)據(jù)被壓縮以減少存儲空間。壓縮閱讀歷史被存儲在基于行密匙的單個列里。

Apache Chukwa

一個開源的監(jiān)控大規(guī)模分布式系統(tǒng)的數(shù)據(jù)采集系統(tǒng)。基于Hadoop HDFS和映射-規(guī)約架構(gòu)。其繼承了Hadoop的可擴(kuò)展性和穩(wěn)健性。Apache Chukwa還包含功能強(qiáng)大的顯示、監(jiān)控、分析功能。Kafka的路由服務(wù)負(fù)責(zé)把數(shù)據(jù)從Kafka 的前端移動到不同的目標(biāo)節(jié)點(diǎn)：也就是S3、Elasticsearch、次級Kafka。這個路由服務(wù)叫Apache Samza。當(dāng)Chukwa把流量發(fā)給Kafka，既可以是全部數(shù)據(jù)流，也可以是過濾流。

Elastic Search

Elastic search在Netflix被越來越廣泛的應(yīng)用。如一個用戶想要播放一個視頻但卻沒有成功，該用戶向客服反饋?？头ㄟ^elastic search來查詢數(shù)據(jù)（日志）來深入研究問題出在哪里，并給與用戶反饋。

AWS應(yīng)用自動縮放功能 - TITUS

Titus的目的是快速啟動可靠的部署應(yīng)用程序?qū)?yīng)的容器。

主要目的如下：

• 允許容器化的應(yīng)用與AWS，Netflix個其它云服務(wù)無縫連接；

• 可操作性上能夠保證系統(tǒng)能運(yùn)行關(guān)鍵任務(wù)載荷和SLA；

• 可擴(kuò)展性上保證成千上萬的主機(jī)上能夠運(yùn)行成千上萬個容器，來實現(xiàn)眾多的運(yùn)行實例；

Titus是一個基于Apache Mesos開發(fā)的框架，是連接眾多主機(jī)資源的集群管理系統(tǒng)。

1. Titus包括一個可復(fù)制的，提供領(lǐng)導(dǎo)選擇的調(diào)度器。該調(diào)度器叫做Titus Master。

2. Titus Master負(fù)責(zé)將容器實例放置到EC2虛擬機(jī)的一個大池子里。該EC2虛擬機(jī)亦叫Titus Agents，負(fù)責(zé)管理單個容器的生命周期。

3. Zookeeper管理領(lǐng)導(dǎo)選擇，Cassandra存儲Titus Master的數(shù)據(jù)。

Titus的主要功能是實現(xiàn)容器的自動縮放。

自動縮放是怎樣工作的呢？例如，一個用戶在東岸打開Netflix，Netflix 的服務(wù)自動擴(kuò)大業(yè)務(wù)的服務(wù)實例來滿足該用戶的視頻需求。

功能實現(xiàn)是基于AWS自動縮放引擎實現(xiàn)的。其能夠計算一個Titus服務(wù)的期望容量，把容量信息傳遞給Titus，從而使得Titus能夠根據(jù)容量來啟動或停止容器來調(diào)整實例載荷。

該方案有幾個優(yōu)勢：

第一，充分利用經(jīng)過檢驗的AWS自動縮放引擎。

第二，Titus用戶可以使用已經(jīng)熟悉的EC2。

第三，應(yīng)用能夠縮放自己的指標(biāo)（譬如每秒請求和容器CPU利用率）和AWS的指標(biāo)（譬如SQS隊列深度）。

第四，用戶能夠從AWS對自動縮放的完善中獲益。

Titus的一個大的挑戰(zhàn)是啟動AWS自動縮放引擎調(diào)用Titus控制平臺。為了解決這個問題，Netflix充分利用AWS的API網(wǎng)關(guān)。

AWS的API網(wǎng)關(guān)是一個提供API訪問的服務(wù)，同時也提供了后臺服務(wù)來調(diào)用Titus。

API網(wǎng)關(guān)提供了供AWS訪問的API，以調(diào)整資源載荷和載荷狀態(tài)，以便后臺實現(xiàn)可擴(kuò)展的資源。當(dāng)Titus服務(wù)配置了自動縮放策略，Titus便在AWS上創(chuàng)建了一個可縮放目標(biāo)。

完。希望對你有用。