當今年加州的夏天結束之時 ，云計算圈子里將有一起標志性剪彩：全球視頻流媒體頭牌Netflix將拉閘下線南硅谷自己最后一個數據中心，百分百擁抱公有云。
這是一場歷時7年的公有云馬拉松。Netflix從招聘網頁開始，螞蟻搬家，把自己數據中心的企業(yè)IT，從架構到職能，從片源搜索到大數據分析，一點一點 步步為營遷移到亞馬遜AWS。去年已完成包括賬單和支付在內大部分系統(tǒng)云遷移，現在只剩最后一個月，Netflix將從自己的數據中心凈身出戶。
2008年8月，正當北京奧運會酣暢淋漓的時候，Netflix主要數據中心數據庫重創(chuàng)，停擺整整三天三夜。Netflix抓狂無門，外加每天高達三百四十萬美元的慘重損失。多難興邦，Netflix痛下決心，從此走上AWS云遷移的不歸路。
2008年的那個時候，微軟正忙著買雅虎，Azure八字還沒有一撇。或者人們知道Sun已日薄西山，但誰是明日之星？然而，Netflix一幫名不經傳的攻城獅程序猿們開始了一場企業(yè)公有云造山運動，最后把當時甚至多數企業(yè)IT男都弄不明了的云計算弄得家喻戶曉。
塞翁失馬,焉知非福。7年后，Netflix已成為全球云先鋒，通過自身摸索與實踐，從當時的云計算處女地踏出一條大路，開創(chuàng)出卓越的企業(yè)公有云模式，昔日IT災區(qū)已是今天IT先驅，成為人人借鑒的楷模。最重要的是Netflix所執(zhí)著追求的業(yè)務目標全面開花結果。
云前云后的確令人贊嘆不已，Netflix以2倍增長的IT成本換取了巨大的業(yè)務成就：客戶增長10倍，訪問量攀升20倍，客戶互動參與增長爆棚100 倍，年銷售收入擴大3倍，達到55億美元，毛利增長21倍，達到17.5億美元。Netflix業(yè)務從美國延伸到60多個國家和市場，由DVD租賃轉型數 字流媒體交付。現在Netflix被分析家認為是下一個市值超1000億美元的公司。
Netflix是大型企業(yè)云遷移成功典范，它的公有云裸奔更讓人圍觀。Netflix為什么可以裸奔？有什么借鑒的價值？裸奔哪些地方是個坑？值得企業(yè)事 業(yè)用戶學習，并因人而異，因地制宜地應用到自己的業(yè)務實踐。此外，Netflix是家非常開放的公司，它把自己的實踐經驗開源成Netflix OSS與產業(yè)分享。重度的開源技術和工具深挖這里：netflix.github.io
為什么選擇AWS云遷移
數據庫掛掉只是當年Netflix轉向云的一個誘因，它促使Netflix深刻反思并認清自身業(yè)務一定需要一個優(yōu)勝的架構和應用。這類對云架構的需求，在企業(yè)用戶市場大同小異。
高可用性：宕機的人傷不起，宕機不僅不能再發(fā)生，而且Netflix決心把可用目標提高，從3個9追求4個9，全年服務率達到99.99%。并考慮不能把雞蛋放在一個籃子里，堆棧式IT架構對自身所需要的高可用有局限，探索包括分布式數據庫在內的橫向擴展架構。
規(guī)模化：Netflix業(yè)務面臨的一個重大挑戰(zhàn)是總需求急劇增長，同時由于收視終端設備類別多，把握不住細分需求趨勢。所以，不善預測的Netflix期望能夠在每一個軟件構件層面隨時隨需橫向擴展，要架構敏捷，沒有任何局限。
然而，擴大架構規(guī)模走什么路線？當時成本代價成為主要關注之一。比如按當時Oracle數據庫授權政策，架構規(guī)模擴大兩倍，授權成本遠遠不止?jié)q兩倍。（去IOE，也許最早從這里開始）
性能：超越現有系統(tǒng)性能，更好更快向客戶提供滿意的服務。這個保障有兩方面分工：AWS提供數據中心架構優(yōu)秀基礎性能保障，但難于針對具體的業(yè)務特別的Netflix業(yè)務改進性能。Netflix則專注在AWS基礎之上的業(yè)務創(chuàng)新和自身性能優(yōu)化。
遷移經驗
Netflix在實施云遷移時，選擇之一是像貨場用叉車一樣把當時數據中心的堆棧完整轉運到AWS，然后在此基礎上做微調。這種遷移方式最簡單，但弊端是 同時把原來不好的設計和行為方式一塊端了過去。最后Netflix決定完全從零開始，以云計算思路，基于AWS公有云創(chuàng)建全新的企業(yè)架構和應用。
螞蟻搬家： 一件事情持之以恒做了7年，從一個側面說明云遷移不是突擊戰(zhàn)，不是一揮而就的事。去年公司首席產品官Neil Hunt在AWS re:Invent大會上回憶說，選擇一張白紙畫新圖，Netflix冒有極大風險。當時完全沒有云環(huán)境經驗，也真不知道將遇到什么問題，甚至這條路是否 走的通都是個問題？基于這樣的考慮，Netflix謹慎選擇小規(guī)模搬遷，螞蟻搬家，一次一小塊。做不好，退回去重做。做好了，再搬下一塊。一次客戶遷移1 %，2%，5%，步步為營，逐步成長，直到最后完成全部遷移。
羅馬雙騎：由于 云遷移存在前景未卜的風險，Netflix采取了一個安全求穩(wěn)戰(zhàn)術：羅馬雙騎“Roman Riding”。這種騎術是一個人先騎一匹馬牽一匹馬，然后站在所騎馬背上。下一步慢慢把一條腿跨到并行奔跑的另一匹馬背上，形成羅馬雙騎奔跑。最后騎在 后一匹馬上，完成雙騎騎術。
羅馬雙騎騎術
羅馬雙騎是一次馬背上的遷移，驚險之處有兩個：站在馬背上跨越和橫跨兩匹馬背站立奔跑。如果跨越出錯，或并立奔跑不能完美協調一致，都可能葬身馬蹄。按照這個騎術，Netflix先在AWS創(chuàng)建原有服務功能，然后進行羅馬雙騎，而且每次只遷移一個特性或功能。
Netflix的云遷移雙騎有點像現在說的數據中心雙活。新開發(fā)的功能實例進行云部署運行，并導入正常流量，同時保留原有功能在老系統(tǒng)運行。云端功能被仔 細地監(jiān)控并保持運行一定時期。如果所有的事情都運行良好，則注銷老系統(tǒng)功能。如果有任何問題發(fā)生，那么馬上切換回老系統(tǒng)。多次確保云上功能完全正確無誤之 后，最后終止原有本地數據中心的該項功能，由云上功能取代原有服務。這個思路實際上已經貫穿在Netflix現在的DevOps一切流程中。
最逼格的是防御：NBA有句老話“防守奪魁”。Netflix的經典是“常作不死”（避免失敗的最好方法就是不斷地失敗）。Netflix這句話畫龍點睛，闡述出當今軟件定義數據中心，由硬件性能保障，轉型軟件性能和機制保障的架構迭代。
在Netflix看來架構事故不可避免，架構的可靠性和性能需經得起任何可能的意外、錯誤甚至宕機。軟件需要天生能夠處理硬件故障、網絡連接故障、軟件集 群故障以及其它類型的錯誤。軟件設計上需要通過在分布式架構中恰當處理獨立，分隔，冗余，延遲和備份，力圖架構永立不敗之地。
比如Netflix實施了微服務，讓服務碎片化，減少彼此關聯，以求事故波及最小鏈，最小化災難半徑。又如Netflix設計了多實例、多區(qū)域和多地域冗余，以確保業(yè)務連續(xù)可用。
不僅如此，Netflix特別“作”，而且非常自“作”。它創(chuàng)建一支“猴軍”（Simian Army）人為搗蛋，隨機地引入錯誤，甚至隨機地導致服務器崩潰終止服務，這種搗蛋每周演習一次。比如隨機關閉生產環(huán)境中的實例，人為進行延時使服務不可 用來模擬服務降級。通過這樣的不斷折騰，即使各種宕機，云服務依然銅墻鐵壁，固若金湯。
Netflix猴軍
現在Netflix猴軍已成為行業(yè)著名的開源工具，廣受攻城獅程序猿的歡迎和使用。
組織轉型DevOps：從本地專用數據中心轉向AWS公有云，Netflix最大的組織機構改革是DevOps。IT人員200擴大到1000+，原來做開發(fā)的程序猿已經同時身兼負責運維，轉型成為DevOps。
現在的Netflix組織結構正是云結構本身的寫照：去中心化和微服務。面向服務按最大可能最小化組建團隊。告訴團隊目標和責任，但不說干什么，不控制； 保持團隊間既定專注，但不綁定團隊，團隊要獨立擔當。總之，一個以微服務為單元組建的團隊獨立負責開發(fā)部署、功能和擴展、可用性設計和安全，凡重要事宜， 不要被代表。
中心團隊側重整體最佳操作案例分享和專家指導，提供公共開發(fā)工具和資源，保障整體戰(zhàn)略大方向一致，提供監(jiān)測和預警，進行評測和趨勢分析。
在此組織架構下，Netflix開發(fā)速度極大提高，原來2周一次發(fā)布，現在一天代碼部署上千次。
裸奔中的那些坑
歸納起來，Netflix云遷移經驗教訓包括這么幾點：
真是搬家，不是辦家家： 在云遷移之前，用戶肯定會進行云供應商選擇和平臺研究，甚至按實際的應用任務及負荷進行系統(tǒng)模擬測試。這些前期工作對云供應商選擇幫助，但決不可認為兩者 完全吻合，可以一帆風順實現遷移。云遷移過程挑戰(zhàn)在真槍實彈階段，只有當在選定云平臺進行落地搭建完成后，你放應用和流量時，用戶才知道云環(huán)境瓶頸在哪 兒？之前的一些聰明設計在實際的海量規(guī)模環(huán)境下很可能就是紙上談兵和辦家家。
上一個新選擇，盡可能在大規(guī)模全荷載下，以真實的數據存儲進行運行，從而逼近真實。記住，坐花轎的不是你的媳婦，接了面紗才是你媳婦。
這是云，不是咱機房：Netflix 自己的數據中心裝備高大上，服務器容量大，速度快，帶寬充足穩(wěn)定。因此允許程序猿玩得嗨，設計豪華應用，對遠程系統(tǒng)提供充足的API接口。然而AWS網絡 實際上存在各種延遲，所以必須在結構上接受各種網絡的交互環(huán)境，以及所帶來的延遲。這是哪怕是AWS這樣高分布式云架構也存在的狀況。
實際上在自己數據中心硬件比較可靠，任何單一硬件實例故障是少見的，因此基于時域的內存管理是不錯的辦法。同樣，管理不穩(wěn)定的內存狀態(tài)是可行的，因為我們 很少去進行從一個到另一個的實例遷移。事實上，云環(huán)境中你對實例的關注和內存管理，將有新的方向。由于可能的更復雜接口沖突或延遲等，實例遷移、丟失、故 障率更高，需要特別提防。
合租房的滋味： 如果你合租，你知道同享廚衛(wèi)，你知道一大早你想入廁，可能要等等因為別人已經占崗。上公有云就是這意思，你對客戶提供的服務都是要通過硬件、網絡、存儲等 共享模式去交付，請隨時準備接受延遲。合租模式既存在于云堆棧中任何一個層面，而且在任何層面它的表現又差異迥然，所以絕對講延遲無處不在。這里潛在許多 陷進，你在自己的專用數據中心難以發(fā)現。
各種延遲最后都可能是對你服務延遲甚至服務終止設下的坑。不要掉到坑里的辦法就是設定你已經掉進坑里的各種后路，隨時準備壯士斷腕，丟支線服務，保證主干服務，特別是確保主干服務的連續(xù)，起碼主干服務別掛掉。
或者，管理你在公有云上的資源，對你丟不起的業(yè)務避免合租。
微服務不是萬能的：這是一個微服務崛起的云世界。Netflix是微服務的模范踐行者，強調把服務切分到最小的粒度，對應獨立團隊去快速開發(fā)和迭代。微服務在反脆弱、容錯、獨立部署與擴展、架構抽象、技術隔離等方面具有諸多優(yōu)勢，保障了服務整體的可用和可擴展性。
微服務是相對于單體應用而言，它對復雜應用是當前極佳的開發(fā)和營運模式選擇。微服務在架構內省約了中間件，服務間直接通過API銜接，它對資源的開銷要求 分布式獨立配置。基于這些特性，在上具體應用之前用戶必須考慮自身基礎設施和組織結構的成熟度，包括服務的集成模式？有無自動化部署和配置能力？監(jiān)測能否 實現？是否采用DevOps的組織形式等？
Netflix微服務成功，但它的應用并不是天生就是微服務，而是后續(xù)采取微服務上新功能，最后反過來把老功能轉碼改造成微服務。是否采用微服務由用戶自身服務需求和復雜性決定，不能為微服務而微服務。
把一個管理和營運效率都很好的現有單體應用拆分成多個微服務可能并不是當務之急。更好的選擇是在新增功能時上手微服務，并以此練兵，在有了足夠的 DevOps經驗后，再看是否把原有應用切分成更細粒度的服務。如果應用不復雜，以優(yōu)秀的模塊化方式做單體應用仍然是好的選擇。
旅途與彼岸
Netflix已經義無反顧走上公有云之路，不再回頭。在云遷移的7年間，Netflix走過漫長的混合IT/混合云旅途。Netflix給企業(yè)用戶最大的啟示不在于公有云成為自己企業(yè)IT的終點，而在于提供前車之鑒，展示云遷移的歷程。
不是每一個企業(yè)都需要裸奔公有云，但混合IT/混合云是每個企業(yè)的必由之路。
AWS牛人Werner Vogels這樣描述云世界的未來：百花齊放的各種云服務構成了混合IT，但在我看來，你必須直面現實，混合IT不是終結。長遠看，許多企業(yè)仍然將有自己的數據中心，但隨時間的推移，企業(yè)數據中心將越來越少。
企業(yè)云計算是一個旅途，混合云/混合IT是常態(tài)。即便是公有云旗手亞馬遜，谷歌甚至Netflix迄今仍然保留有自己的專用IT操作。公有云存量將越來越大，而彼岸絕非一朝一夕。
京公網安備 11010502049343號