兩岸微商網路創業平台

現今年加州的夏天收場之時 ，雲計算圈子裡將有一塊兒標誌性剪綵：全世界視訊流媒體頭牌Netflix將拉閘下線南矽谷自己最後一個資料中心，百分百擁抱公有雲。

這是一場歷時7年的公有雲馬拉松。Netflix從招聘網頁開始，螞蟻搬家，把自己資料中心的企業IT，從架構到職能，從片源搜尋到大資料分析，一點一點 步步為營遷移到亞馬遜AWS。去年已完成內含賬單以及支付在內大部份系統雲遷移，現在只剩最後一個月，Netflix將從自己的資料中心淨身出戶。

2008年8月，正當北京奧運會酣暢淋漓的時候，Netflix主要資料中心資料庫重創，停擺整整三天三夜。Netflix抓狂無門，外加天天高達三百四十萬美元￥的慘痛損失。多災興邦，Netflix痛下決心，從此走上AWS雲遷移的不歸路。

2008年的那個時候，微軟忙線中著買雅虎，Azure八字尚無一撇。或是人們曉得Sun已日薄西山，但誰是明日之星？然而，Netflix一幫名不經傳的攻城獅程式猿們開始了一場企業公有雲造山運動，最後把當時甚至多數企業IT男都搞不明瞭的雲計算搞得婦孺皆知。

塞翁失馬,焉知非福。7年後，Netflix已成為全世界雲先鋒，通過自身試探與實踐，從當時的雲計算處女地踏出一條大路，創始出卓著的企業公有雲模式，往日IT災區已是今天IT前驅，成為人人借鑒的楷模。最主要的是Netflix所執著追求的業務目的全面開花結果。

雲前雲後的確使人讚嘆不已，Netflix以2倍增長的IT成本換取了巨大的業務造詣：客戶增長10倍，走訪量攀升20倍，客戶互動參預增長爆棚100 倍，年銷售收入擴張3倍，達到55億美元￥，毛利增長21倍，達到17.5億美元￥。Netflix業務從美國延伸到60多個國家以及市場，由DVD租賃轉型數 字流媒體交付。現在Netflix被分析家認為是下一個市值超1000億美元￥的公司。

Netflix是大型企業雲遷移勝利典範，它的公有雲裸奔更讓人圍觀。Netflix為何可以裸奔？有什麼借鑒的價值？裸奔哪些處所是個坑？值得企業事 業使用者學習，並因人而異，因地制宜地運用到自己的業務實踐。此外，Netflix是家很開放的公司，它把自己的實踐經驗開源成Netflix OSS與產業分享。重度的開源技術以及工具深挖這裡：netflix.github.io

為何選取AWS雲遷移

資料庫掛掉只是當年Netflix轉向雲的一個誘因，它促使Netflix深刻反思並認清自身業務必定需要一個優勝的架構以及運用。這種對雲架構的需求，在企業使用者市場大同小異。

高可用性：宕機的人傷不起，宕機不僅不能再發生，而且Netflix決心把可用目的提高，從3個9追求4個9，全年服務率達到99.99%。並斟酌不能把雞蛋放在一個籃子裡，堆堆疊式IT架構對自身所需要的高可用有局限，探索內含擴散式資料庫在內的橫印延伸架構。

規模化：Netflix業務面臨的一個重大挑戰是總需求急劇增長，同時因為收視終端裝置類別多，把握不住細分需求趨勢。所以，不善預測的Netflix指望能夠在每個軟體構件層面隨時隨需橫印延伸，要架構麻利，沒有任何局限。

然而，擴張架構規模走什麼路線？當時成本代價成為主要關注之一。譬如按當時Oracle資料庫授權政策，架構規模擴張兩倍，授權成本遠遠不止漲兩倍。（去IOE，或許最先從這裡開始）

效能：超出現有系統效能，更好更快向客戶提供滿意的服務。這個保障有兩方面分工：AWS提供資料中心架構優良基礎效能保障，但難於針對具體的業務尤其的Netflix業務改良效能。Netflix則專註在AWS基礎之上的業務立異以及自身效能改善。

遷移經驗

Netflix在施行雲遷移時，選取之一是像貨場用叉車同樣把當時資料中心的堆堆疊完整轉運到AWS，然後在此基礎上做微調。這種遷移模式最簡單，但弊病是 同時把原來不好的設計以及行為模式一塊端了過去。最後Netflix抉擇徹底從零開始，以雲計算思路，基於AWS公有雲建立全新的企業架構以及運用。

螞蟻搬家： 一件事情持之以恆做了7年，從一個側面說明雲遷移不是突擊戰，不是一蹴而就的事。去年公司首席產品官Neil Hunt在AWS re:Invent大會上回憶說，選取一張白紙畫新圖，Netflix冒有極大風險。當時徹底沒有雲環境經驗，也真不曉得將遇到什麼問題，甚至這條路是否 走的通都是個問題？基於這樣的斟酌，Netflix小心選取小規模搬遷，螞蟻搬家，一次一小塊。做不好，退回去重做。做好了，再搬下一塊。一次客戶遷移1 %，2%，5%，步步為營，逐漸成長，直到最後完成全體遷移。

羅馬雙騎：因為 雲遷移存在前景未卜的風險，Netflix採用了一個安全求穩戰術：羅馬雙騎「Roman Riding」。這種騎術是一個人先騎一匹馬牽一匹馬，然後站在所騎馬背上。下一步慢慢把一條腿跨到並行奔跑的另一匹馬背上，形成羅馬雙騎奔跑。最後騎在 後一匹馬上，完成雙騎騎術。

羅馬雙騎騎術

羅馬雙騎是一次馬背上的遷移，驚險之處有兩個：站在馬背上跨越以及橫跨兩匹馬背站立奔跑。假設跨越犯錯，或者並立奔跑不能完美協調一致，均可能葬身馬蹄。按照這個騎術，Netflix先在AWS建立原有服務功能，然後進行羅馬雙騎，而且每一次只遷移一個特性或者功能。

Netflix的雲遷移雙騎有點像現在說的資料中心雙活。新開發的功能案例進行雲部署運行，並匯入標準流量，同時保留原有功能在老系統運行。雲端功能被仔 細地監控並維持運行必定時代。假設所有的事情都運行優良，則註銷老系統功能。假設有任何問題發生，那麼馬上切換回老系統。屢次確保雲上功能徹底正確無誤之 後，最後終止原有本地資料中心的該項功能，由雲上功能取代原有服務。這個思路實際上已經貫穿在Netflix現在的DevOps一切流程中。

最逼格的是防禦：NBA有句老話「防守奪魁」。Netflix的經典是「常作不死」（防止失敗的最佳方式就是不斷地失敗）。Netflix這句話畫龍點睛，闡述出現今軟體定義資料中心，由硬體效能保障，轉型軟體效能以及機制保障的架構迭代。

在Netflix看來架構事故不可防止，架構的可靠性以及效能需經得起任何可能的意外、過錯甚至宕機。軟體需要天生能夠處理硬體故障、網路連線故障、軟體集 群故障以及其它類型的過錯。軟體設計上需要通過在擴散式架構中恰當處理獨立，分隔，冗餘，延遲以及備份，力圖架構永立不敗之地。

譬如Netflix施行了微服務，讓服務碎片化，減少彼此關聯，以求事故波及最小鏈，最小化災難半徑。又如Netflix設計了多案例、多區功能變數以及多地功能變數冗餘，以確保業務連續可用。

不僅這樣，Netflix尤其「作」，而且很自「作」。它建立一支「猴軍」（Simian Army）人為搗蛋，隨機地引入過錯，甚至隨機地致使伺服器崩潰終止服務，這種搗蛋每週演習一次。譬如隨機關閉出產環境中的案例，人為進行延時使服務不可 用來摹擬服務降級。通過這樣的不斷折騰，即便各種宕機，雲服務仍然銅牆鐵壁，堅如磐石。

Netflix猴軍

現在Netflix猴軍已成為行業有名的開源工具，廣受攻城獅程式猿的歡迎以及使用。

群組織轉型DevOps：從本地私人資料中心轉向AWS公有雲，Netflix最大的群組織機構改革是DevOps。IT人員200擴張到1000+，原來做開發的程式猿已經同時身兼負責運維，轉型成為DevOps。

現在的Netflix群組織結構恰是雲結構本身的寫照：去中心化以及微服務。面向服務按最大可能最小化群組建團隊。奉告團隊目的以及責任，但不說幹什麼，不節制； 維持團隊間既定專註，但不綁定團隊，團隊要獨立擔負。總之，一個以微服務為單元￥群組建的團隊獨立負責開發部署、功能以及延伸、可用性設計以及安全，凡主要事宜， 不要被代表。

中心團隊著重總體最佳動作案例分享以及專家指示，提供公共開發工具以及資源，保障總體戰略大方向一致，提供監測以及預警，進行評測以及趨勢分析。

在此群組織架構下，Netflix開發速度極大提高，原來2週一次發佈，現在一天代碼部署上千次。

裸奔中的那些坑

歸納起來，Netflix雲遷移經驗教訓內含這麼幾點：

真是搬家，不是辦家家： 在雲遷移以前，使用者確定會進行雲提供者選取以及平台鑽研，甚至按實際的運用任務及負荷進行系統摹擬測試。這些前期工作對雲提供者選取說明，但決不可認為二者 徹底吻合，可以一路順風實現遷移。雲遷移過程挑戰在真槍實彈階段，只有當在選取雲平台進行落地搭建完成後，你放運用以及流量時，使用者才曉得雲環境瓶頸在哪 兒？以前的一些聰明設計在實際的海量規模環境下極可能就是空言無補以及辦家家。

上一個新選取，儘可能在大規模全荷載下，以真正的資料存儲進行運行，從而迫臨真實。記住，坐花轎的不是你的媳婦，接了面紗才是你媳婦。

這是雲，不是咱機房：Netflix 自己的資料中心設備高大上，伺服器容量大，速度快，頻寬足量安定。因而容許程式猿玩得嗨，設計奢華運用，對遠端系統提供足量的API介面。然而AWS網路 實際上存在各種延遲，所以必需在結構上接受各種網路的互動環境，以及所帶來的延遲。這是哪怕是AWS這樣高擴散式雲架構也存在的狀況。

實際上在自己資料中心硬體對比可靠，任何單一硬體案例故障是少見的，因而基於時功能變數的記憶體管理是不錯的辦法。同樣，管理不安定的記憶體狀況是可行的，因為咱們 很少去進行從一個到另一個的案例遷移。事實上，雲環境中你對案例的關注以及記憶體管理，將有新的方向。因為可能的更繁雜介面衝突或者延遲等，案例遷移、丟失、故 障率更高，需要尤其提防。

合租房的滋味： 假設你合租，你曉得共享廚衛，你曉得一大早你想入廁，可能要等等因為別人已經占崗。上公有雲就是這意思，你對客戶提供的服務都是要通過硬體、網路、存儲等 同享模式去交付，請隨時籌備接受延遲。合租模式既存在於雲堆堆疊中任何一個層面，而且在任何層面它的表現又懸殊迥然，所以絕對講延遲無處不在。這裡潛在許多 陷進，你在自己的私人資料中心難以發現。

各種延遲最後均可能是對你服務延遲甚至服務終止設下的坑。不要掉到坑裡的辦法就是設定你已經掉進坑裡的各種後路，隨時籌備壯士斷腕，丟支線服務，保證主幹服務，尤其是確保主幹服務的連續，起碼主幹服務別掛掉。

或是，管理你在公有雲上的資源，對你丟不起的業務防止合租。

微服務不是萬能的：這是一個微服務突起的雲世界。Netflix是微服務的模範踐行者，強調把服務切分到最小的粒度，對應獨立團隊去快速開發以及迭代。微服務在反懦弱、容錯、獨立部署與延伸、架構抽像、技術隔離等方面擁有諸多優勢，保障了服務總體的可用以及可延伸性。

微服務是相對於於單體運用而言，它對繁雜運用是現用的極佳的開發以及運營模式選取。微服務在架構內省約了中間件，服務間直接通過API銜接，它對資源的開消請求 擴散式獨立配置。基於這些特性，在上具體運用以前使用者必需斟酌自身基礎設施以及群組織結構的成熟度，內含服務的整合模式？有沒有自動化部署以及配置能力？監測能否 實現？是否採納DevOps的群組織形式等？

Netflix微服務勝利，但它的運用並非天生就是微服務，而是後續採用微服務上新功能，最後反過來把老功能轉碼改造成微服務。是否採納微服務由使用者自身服務需乞降繁雜性抉擇，不能為微服務而微服務。

把一個管理以及運營效力都很好的現有單體運用分割成多個微服務可能並非當務之急。更好的選取是在新增功能時上手微服務，並以此練兵，在有了足夠的 DevOps經驗後，再看是否把原有運用切分成更細粒度的服務。假設運用不繁雜，以優良的模組化模式做單體運用依然是好的選取。

旅途與彼岸

Netflix已經義無返顧走上公有雲之路，再也不回頭。在雲遷移的7年間，Netflix走過漫長的混合IT/混合雲旅途。Netflix給企業使用者最大的啟示不在於公有雲成為自己企業IT的終點，而在於提供前車之鑒，展示雲遷移的歷程。

不是每個企業都需要裸奔公有雲，但混合IT/混合雲是每一個企業的必由之路。

AWS牛人Werner Vogels這樣描寫雲世界的未來：百花齊放的各種雲服務形成了混合IT，但在我眼裡，你必需直面現實，混合IT不是終結。長遠看，許多企業依然將有自己的資料中心，但隨時間的推移，企業資料中心將愈來愈少。兩岸商貿,在家工作,網路創業,創業賺錢思維,微商平台,賺新台幣

企業雲計算是一個旅途，混合雲/混合IT是常態。即使是公有雲旗手亞馬遜，谷歌甚至Netflix迄今依然保留有自己的私人IT動作。公有雲存量將愈來愈大，而彼岸絕非一朝一夕。CBI