做者按: html
Netflix(譯爲奈飛/網飛)公司自1997年創立以來,已發展成爲美國最大的互聯網流媒體服務商。它從2008到2015年間長達七年的將其全部IT系統從自有數據中心遷移到AWS之上的旅程,在當時可謂前無古人的創舉,對公有云的發展、傳統企業上雲及基於雲的業務轉型等都有很大的推進和促進做用。雖然已過去多年,有些東西已略微顯得過期,但奈飛上雲的理念、步驟、作法等,對當今企業上雲及用雲仍有很大的參考價值。 前端
所以,在接下來的幾周內,筆者打算花上些許時間,對奈飛的上雲之旅,及其雲上運行,基於網上公開資料,從上雲歷程、雲上架構、支撐團隊、雲上安全等維度作下梳理和總結,造成系列文章。它山之石,能夠攻玉。本文爲這系列文章的第一篇,介紹奈飛的整體上雲歷程。數據庫
本文目錄後端
零、公司簡介....................................... 1安全
1、發端.............................................. 4服務器
2、驗證.............................................. 6微信
3、進行.............................................. 8網絡
4、完成.............................................. 11 架構
5、筆者感覺分佈式
Netflix(https://www.netflix.com/)公司總部設在美國加利福尼亞州,是全世界最大的視頻流媒體平臺,在除中國大陸地區之外的全部國家和地區均提供視頻點播服務,至關於國內的愛奇藝、優酷和騰訊視頻等視頻網站。
1997年,當Reed Hastings和Marc Randolph建立 Netflix時,這家公司惟一業務是DVD郵購業務。2002年上市,股票發行價爲15美圓;2007年開始發展流媒體業務;2013年,發佈其首部原創電視劇《紙牌屋》;2016年宣佈全球化,全世界200多個國家和地區可訂閱Netflix觀看電影電視劇。 2017年,Netflix用戶數量超過美國有線電視用戶總數。現在,Netflix的股價是419美圓,已成爲世界上大型的電視劇和電影製片公司之1、美國最大的互聯網流媒體服務商,在世界範圍內擁有很強的影響力,高峯時刻佔據了互聯網流媒體流量的33%。
除了商業上很是成功外,Netflix在技術上也很是成功,它雖然是家娛樂公司,但其實是一家技術公司。從2008年開始,直到2015年末,它花了整整七年時間,把公司整套IT系統搬到了AWS上。這可謂前無來者。除此以外,Netflix在分佈式系統開源上具備巨大的影響力,其開源項目叫作Netflix OSS(Open Source Software),涵蓋範圍基本包括了業界絕大部分分佈式系統領域,包括但不限於:
· 公共運行時服務及庫,好比Eureka, Ribbon, Hystrix
· 大數據,好比Genie
· 構建和發佈工具,好比Asgard/Spinnaker
· 數據持久化,好比EVCache
· 可觀察性、可靠性和性能,好比Simian Army
Netflix的上雲之旅始於2008年8月。從公開資料來看,當時主要有兩個驅動力促使其上雲:
(1)發生了系統宕機。
當時,Netflix的IT系統運行在高端昂貴的IBM服務器、Oracle數據庫和SAN存儲搭建的平臺之上。某次,由於SAN存儲硬件故障致使的數據庫宕機,使得Netflix的DVD配送服務不得不中止了3天。這個故障使得公司管理層開始意識到,由IT團隊利用昂貴的平臺來保證系統可用性的作法存在問題,更應該從應用層面去保障系統可用性。所以,需考慮IT系統從傳統垂直擴展的帶有單點故障的架構,轉向高可用、水平擴展的分佈式架構。與此同時,他們開始思考是否能夠利用剛剛出現的低成本雲基礎設施來替代昂貴傳統IT基礎設施來支撐需具有高可用性的應用。
(2)新業務帶來巨大數據中心擴容壓力。
Netflix的傳統DVD寄送服務的服務模式下,客戶瀏覽Netflix網站選擇DVD,而後公司開始寄送。由於受到DVD來回寄送速度的限制,一般是以周爲週期給客戶寄送DVD。所以,這種傳統業務模式對IT系統的業務壓力較輕。
傳統DVD寄送業務模式
儘管DVD業務增加迅速,但2007年Netflix仍然決定推出第一款流媒體產品「Watch Now」來革新其業務。這種業務也是它後來蓬勃發展的關鍵因素之一。這種新服務模式下,用戶與Netflix網站之間的交互頻率是傳統DVD寄送業務下交互頻率的100倍甚至不止。
流媒體服務模式
新模式下,用戶每週看的視頻數量是以前的十倍,而每一個視頻對數據中心中的IT系統產生的流量則是百倍,所以每一個用戶對IT系統產生的流量是以前的千倍。也就是說,只要0.1%的用戶從傳統模式轉向新模式,那IT系統的容量就必須翻倍。其實這種規律也很常見。即便用戶並無顯著增加,只要由於業務模式的變化,對IT系統的壓力也可能成倍增長。
這就要求Netflix找到一種快速擴容數據中心的方法,由於根據當時的業務預測,其用戶很快就會轉向在線流媒體服務模式。時間來到2009年,隨着新業務的發展,Netflix面臨兩個選擇:自建數據中心,或利用其業務競爭對手亞馬遜於2006年才發佈的AWS雲。前者須要大量前期資金投入,而且將來的容量需求沒法預測且是變化不定的,然後者則是在視頻流領域的最大競爭對手Amazon的雲上開展業務。Netflix決定選擇後者。他們認爲,相比在不實際產生業務價值的數據中心上作前期巨大投入,將資金投入在視頻內容和開發人員身上會更有價值。
因而這一年(2009年),Netflix開始研究利用AWS雲來開展業務的各類風險,包括業務競爭風險、規模性風險、商業風險和公關風險等。就業務競爭風險,Netflix與AWS溝融了AWS是如何與Amazon Premier作業務分離的。而後開展實驗去驗證AWS上的資源快速擴容能力。Netflix還與AWS簽定了首批企業許可協議,這種協議下Netflix不須要經過受權信用卡方式來使用AWS資源,而信用卡受權是當時大多數人在AWS上消費時使用的主要方式。
隨着兩家合做消息的傳開,2010年4月,紐約時報還發表了一篇關於Netflix和AWS業務的文章,說二者將進行業務合做。請注意其中的「peculiar(特有)「一詞,表示那時候企業上雲是新聞,而上到競爭對手的雲上更是新聞。
當時Netflix還諮詢了一些業界專家,專家們認爲這種作法很是瘋狂,由於當時不多有企業這麼作,並且企業業務上雲在當時仍是一個很是不成熟的策略。但Netflix決定堅持下去,成爲首批上雲企業客戶之一。
接下來,Netflix實驗性地將一些沒有真正面向客戶的應用遷移到AWS上。首先從電影編碼開始,當時其只有數據中心沒有足夠的容量來容納編碼服務器。有一次Netflix申請3000臺服務器,結果AWS一個小時內就交付了,這就驗證AWS資源交付的彈性和及時性。並且隨着這項工做的完成,不用的機器即被釋放,這證實了雲計算的「按需使用和付費」特徵。
接下來驗證視頻服務QoS日誌上雲。隨着進入數據中心數據庫的流量愈來愈多,這些流量正在溢出,並且本身的機房缺少足夠的存儲空間來保存想要的信息。因而,Netflix利用S3來存儲數據,利用EMR來處理數據。Netflix是Hadoop早期用戶之一,曾與AWS合做將Hive做爲基於EMR的處理選項。
到2010年,可行性驗證基本完成,Netflix認爲上雲看起來是可行的。因而2011年,Netflix做出決定,再也不擴容自有IDC。
Netflix開始真正地要在AWS雲上起飛了。從最簡單的API服務開始,而後是最簡單的Web網頁,而後是更多的API和網頁。
到2010年末,Netflix成功地將網站前端都遷移到了AWS上,但後端依然在自有數據中心內。
用戶訪問流量仍是進入其自有數據中心,可是有選擇地將部分流量利用HTTP Redirect將請求轉向AWS Cloud。這其實也就是咱們如今經常提到的金絲雀模式,經過導入部分用戶到新環境上來驗證和逐步地完成系統遷移。
接下來是數據遷移。2010年的主要工做之一,是將主數據系統放在數據中心,將副本放在雲中,並將數據從本地持續地同步到雲中。
2011年,Netflix決定將全部數據放到雲上。其中一個問題是如何作數據備份。Netflix沒有采用當時常見的利用本地數據中心中的磁帶來備份雲中數據的作法,而是充分利用了S3的安全性和持久性,用不一樣的帳戶在不一樣的AWS區域中建立S3存儲桶,而後將生產數據導入生產區域S3存儲桶,再通過壓縮和加密並傳送到容災區域的桶中。利用不一樣的帳戶,主要是從安全角度考慮。後來,AWS發佈了Glacier後,Netflix利用它來作長期歸檔的數據存儲。
到2015年,除了計費和帳單系統外,其他全部系統都已經遷移到AWS上了。到2016年1月4日,Netflix完成了最後這兩個系統的遷移,詳細信息請參加其公司博客https://netflixtechblog.com/netflix-billing-migration-to-aws-451fba085a4。
2016年2月,Netflix宣佈其上雲遷移工做所有完成。這一年,Netflix的用戶數是2008年開始上雲遷移時候的8倍,而用戶的月度觀看視頻數則有幾千倍的增加,用戶遍及全球超過130個國家,Netflix也成爲了一家國際化視頻服務提供商。
到2017年,除了CDN由其自建外,Netflix使用AWS來知足其幾乎全部計算和存儲需求,包括數據庫、分析、建議引擎、視頻轉碼等數百種功能。並且,Netflix系統的可用性在持續增長,正在不斷接近99.99%的既定目標。
Netflix的視頻服務在高峯時段佔據了高達37%的Internet流量。相比之下,YouTube 僅佔到15.6%,網頁瀏覽約 6%, Facebook約2.7%, Amazon Instant Video 約2.0%。
在AWS上共利用超過10萬個 EC2 Instances 的80萬CPU Cores,且在此基礎上有約 20% 的波動。
在每一個服務區域上的 AWS Elastic Load Balancing 的流量超過 50Gbps
在 S3 上存儲和管理超過15億個對象的 60 PB 的數據。其中天天要丟棄超過 400TB 的過時數據以及新增 600TB 的數據。
2016年Netflix在AWS上的系統架構:
儘管下降成本支出並非Netflix上雲的主要出發點之一,可是實際上,如今每一個視頻的播放成本是當初利用自有數據中心的幾分之一,這是一種很是可觀的額外收益。這主要歸功於雲的彈性,使得Netflix能夠持續地優化實例類型,近乎實時地增長或減小所用的資源,而不須要維持大規模的備用容量,以及公有云的規模不斷擴大帶來的單位成本降低。
那爲何須要7年時間才能完成上雲遷移呢?這是由於全業務上雲是一項艱鉅的工做,須要作好多的艱難決策。能夠想到的是,最簡單的方式是將全部系統緣分不斷地搬到雲上,可是隨着系統一塊兒搬過去的還有你在傳統數據中心中遇到的全部問題和限制。所以,Netflix選擇了一條另外的道路,重構全部系統,完全改變公司IT運營方式,將單體應用改變爲微服務架構應用、重構數據模型、使用NoSQL數據庫。將過去那種預算嚴格受控制、版本發佈嚴格受管控、花幾周時間來作物理容量擴容的傳統方式,改變爲持續集成和發佈、技術團隊獨立作決策、基於鬆耦合DevOps環境的新方式。這種方式使得Netflix花了七年時間才完成上雲之旅,可是正是這種轉變,也使得它成爲了一家國際化的網絡視頻服務提供商。
大膽決策,開先河。不說10年前,就是在如今,要不要上(公有)雲、源代碼和核心數據能不能上雲、雲上安全怎麼搞、以什麼步驟上雲、應用要不要作架構升級等等這些問題,依然是評估上雲時會引起爭論的話題。而十年前的Netflix,從自身業務出發,作出了艱難決策,決定把資金用在覈心業務上,將數據中心外包給公有云,這前無來者,開了業界先河。要爲他們的眼光、勇氣和決心點贊!
先易後難,保安全。Netflix並不是倉促上陣,而是整體上執行先易後難、先驗證再推廣的策略。從最簡單的API、網頁前端、離線視頻編碼系統等開始,作技術可行性驗證。驗證成功後,再推廣至其它系統,最後作最核心的帳單和支付系統遷移,在保障業務穩定和用戶體驗的前提下,花了七年時間才完成所有遷移工做。要爲他們的務實精神點贊!
以終爲始,高標準。Netflix並無簡單地將其IT系統從其自有數據中心搬到AWS上,而是以終爲始,高標準完成遷移工做。「終」是系統的可用性要達到四個九,確保用戶體驗。要實現這個目標,須要在遷移上雲前對應用作分佈式改造。只有這樣,才能充分利用雲的彈性和分佈式能力。並且,Netflix主要利用的是AWS的IaaS,自研了全球分佈的PaaS平臺。一方面是由於當時AWS所提供的是以IaaS爲主,還考慮到了供應商綁定以及將來多雲等可能。這些作法都具備開創性和前瞻性,不只這種作法對後來更多用戶如何上雲極具參考價值,並且Netflix將其PaaS中不少組件都開源了,直接促進了行業發展。要爲他們對本身的嚴格要求和對業界的貢獻點贊!
參考資料:
覆盤Netflix發展史:如何用20年成爲一家千億美圓公司?,克魯斯2018年5月14日。https://www.gelonghui.com/p/179693
Completing the Netflix Cloud Migration,https://media.netflix.com/en/company-blog/completing-the-netflix-cloud-migration,2016.1
YouTube video,Globally Distributed Cloud Applications at Netflix,October 2012,Adrian Cockcro
Migrating to Cloud - Lessons from Netflix, Brought Up to Date,Adrian Cockcroft,https://media.netflix.com/en/company-blog/completing-the-netflix-cloud-migration
Companies Slowly Join Cloud-Computing,By Brad Stone and Ashlee Vance,https://www.nytimes.com/2010/04/19/technology/19cloud.html
感謝您的閱讀,歡迎關注個人微信公衆號: