之前提到Netflix，只知道紙牌屋。前一段在學DevOps Professional，才知道ChaosMonkey原來出自這家公司。稍微調查一下不打緊，原來Eureka，Hystrix都是出自Netflix。立馬路轉粉，加之近半年多來都對Amazon和AWS很感興趣，Netflix與AWS之間又是千絲萬縷的好基友。恰逢五一放假，抽空把近期有關Netflix的內容組織整理，便形成了本文。
大部分內容搬運自文後的參考資料，本人做了調整，同時加入自己的觀點。如有不妥，還望告知。
Netflix的故事
Netflix是什麼
Netflix是一家視頻公司，提供每月7.99到11.99美元不等的訂閱服務(subscription service)。他家採用"All-you-can-eat"的單一模式，在全球擁有8100萬subscribers，其中美國超過4600萬。
Netflix的起源
很久很久以前，有一家公司叫Blockbuster，稱霸租碟業許多年。某個叫Reed Hastings的哥們在那裡租了個碟，結果由於超期歸還被黑走“一大筆”逾期費（大概40美元），怒了。然後他忿忿地去健身，發覺健身房商業模式甚是美哉，不管你去得多還是少，會員費半毛錢也不能少交。很不巧，Hastings是一個動不動就要改變世界的軟件工程師，想法來了就要幹，更不巧的是他當時已經非常有錢。於是憤怒之餘他創辦了Netflix，也是做租碟生意，沒有逾期費並且搞會員制。十三年後Netflix把Blockbuster幹到了破產保護，大仇得報。這個故事告訴我們兩個道理：1.客戶服務一定要做好，不該薅的羊毛就別死命薅，不然你就是逼羊為虎。2. 工程師惹不起。
Blockbuster搞的是錄像帶和碟片租賃，和摩拜、ZipCar等一樣，都是自營商品的共享經濟，只是它沒有藉助互聯網。而Netflix從名字上就能感受到深深的互聯網基因。Netflix只對Blockbuster模式做了兩個改變 1. 輕資產化，無店面，網上運營。2. 郵碟到戶。輕資產電商+共享+O2O快遞模式。一幅圖能看出來Netflix逐年對Blockbuster的蠶食。
2006年是Netflix流媒體（streaming）的元年，隨著美國寬帶普及率逐年上升，2005年Youtube的出現，Netflix開始革自己的命。從實體租賃到內容在線提供，像極了傳統產品供應商向雲服務模式的轉型。2005年流媒體之前，Netflix訂閱人數為420萬；2016年流媒體十年之後，Netflix訂閱人數為8320萬。十年十倍增長，足以看出在線服務模式區別於實體產品提供模式的成本邊際遞減及規模效應。美國的有線電視價格高昂，一般的都要七十甚至一百五每月。而NETFLIX在十幾塊的價位上提供了幾乎是最大的內容庫，Netflix模式如此受歡迎閉著眼睛也能明白，美國人甚至造出一句俚語“Netflix and chill”（直接含義及引申含義自己Google）。
Netflix的成功，除了在模式和內容上的苦心經營，技術上的投入居功至偉。Netflix看起來在娛樂業，其實是個科技公司。從一開始單挑Blockbuster，Netflix骨子裡玩的就是一個O2O的概念，離不開信息技術的開路。時至如今更是如此，Netflix是出了名的開著業內頂薪打著燈籠挖IT工程師，公司官網專門開設Netflix Tech Blog討論各種尖端技術問題。
Netflix的混亂猴子軍團
鋪墊了那麼多，終於到了本文的重點，Netflix佔到北美網絡流量的1/3強，而背後則是AWS的支撐。無論是底層網絡、存儲與計算，還是大數據、人工智能應用，Netflix可是把AWS各項服務的能力用到了極致。
墨菲定律告訴我們，但凡一件事可能發生，它就必然發生。Netflix背後佔到北美1/3的網絡流量，用戶數量及併發訪問非一般技術公司能夠想象。一般的想法都是加強測試，儘可能模擬一切可能發生的事故，但現實是很多事故無法在實驗室模擬，比如大規模宕機，有些豬一樣的隊友無法預先想象，比如無處不在的rm -rf * 故事。
普通的公司會選擇迴避，當事件真正發生時再處理，畢竟在這類小概率事件上花費不成比例的精力，有些得不償失。而牛X公司如Netflix，追求的是極致的用戶體驗，以及對自身技術能力的無限追求，更重要的是不能被豬一樣的友商拖死。失效一定會發生，並且無法避免；如果你的應用無法容忍系統失效的情況，你是願意在凌晨 3 點被叫醒，還是希望在辦公室中用過 morning coffee 之後呢？
於是乎，Netflix在AWS上建立了一個叫做 Chaos Monkey的系統，這些猴子會在工作日期間隨機殺死一些服務，製造混亂，來測試production下的穩定性。Chaos Monkey是一種服務，用於將系統分組，並隨機終止屬於某個分組中的系統中的一部分；Chaos Monkey運行在一定的受控時間段和時間間隔內（不會無故運行在週末和假日中，並且僅在上班時間內運行）；在大多數情況下，我們的應用設計要保證當某個peer 下線時仍能繼續工作，但是在那些特殊的場景下，我們需要確保有人在值守，以便解決問題，並從問題中進行經驗學習；基於這個想法，Chaos Monkey 僅會在工作時間內被使用，以保證工程師能發現警告信息，並作出適當的回應；每當這些猴子開始騷擾，一開始，相關的工程師們不得不放下手頭的工作，手忙腳亂地尋求應對之策。隨著系統的不斷完善，猴子們的攻擊能力和攻擊範圍也在不斷提升，反而讓整個Netflix的服務穩定性、自愈能力以及抗擊打能力不斷上升。
Netflix整個的IT都架構於AWS之上，Chaos Monkey是用來測試 AWS 的彈性和恢復能力，Chaos Monkey 通過關停一個或多個虛擬機來模擬 service 實例的失效。
如今Chaos Monkey 已經升級為 Simian Army，從可用性、一致性、安全性、健康性等各方面對系統進行各種擾亂，想象一下，一群Monkey，小到蹦蹦跳跳的猴子，大到猩猩、金剛，在你的機房不知道會搞出什麼麻煩，而同時又要求你的系統防禦、自愈以及運維能力能夠抵禦這全方位的極限攻擊。長時間暴露在這樣高強度的壓力之下（普通的壓測在猴子軍團面前簡直弱爆了），系統和團隊的能力將得到怎樣的長足進步。
Simian Army中的各位成員：
-Chaos Monkey，可以隨機關閉生產環境中的實例，確保網站系統能夠經受故障的考驗，同時不會影響客戶的正常使用。
-Latency Monkey，在RESTful服務的調用中引入人為的延時來模擬服務降級，測量上游服務是否會做出恰當響應。通過引入長時間延時，還可以模擬節點甚至整個服務不可用。
-Conformity Monkey，查找不符合最佳實踐的實例，並將其關閉。例如，如果某個實例不在自動伸縮組裡，那麼就該將其關閉，讓服務所有者能重新讓其正常啟動。
-Doctor Monkey，查找不健康實例的工具，除了運行在每個實例上的健康檢查，還會監控外部健康信號，一旦發現不健康實例就會將其移出服務組。
-Janitor Monkey，查找不再需要的資源，將其回收，這能在一定程度上降低雲資源的浪費。
-Security Monkey，這是Conformity Monkey的一個擴展，檢查系統的安全漏洞，同時也會保證SSL和DRM證書仍然有效。
-10-18 Monkey，進行本地化及國際化的配置檢查，確保不同地區、使用不同語言和字符集的用戶能正常使用Netflix。
-Chaos Gorilla，Chaos Monkey的升級版，可以模擬整個Amazon Availability Zone故障，以此驗證在不影響用戶，且無需人工干預的情況下，能夠自動進行可用區的重新平衡。
除了Simian Army，Netflix同時也是分佈式領域開源共享無可辯駁的領先者。摘抄自Netflix的github主頁，開源項目涵蓋：
-Common Runtime Services & Libraries(e.g.Eureka,Ribbon,Hystrix)
-Big Data(e.g.Genie)
-Build and Delivery Tools(e.g.Asgard/Spinnaker)
-Data Persistence(e.g.EVCache)
-Insight, Reliability and Performance(e.g.Simian Army)
其中尤以Eureka,Hystrix以及Simian Army最為知名。
Netflix與AWS
Netflix並不是最早的AWS customer，但卻絕對是最重要的AWS customer之一。從商業層面，美國超過1/3的traffic經過Netflix，其中絕大部分還要經過AWS，這還僅僅是網絡，加上支撐所需的計算、存儲能力，以及之上的大數據和人工智能分析，說Netflix是AWS最重要的客戶之一絕不誇張。加之Netflix在開源社區的影響力，以及Netflix只使用AWS服務，每次AWS re:invent大會，Netflix都會成當之無愧的座上賓，基本每個大部門都會有人上臺演講。以最近的2015年AWS re:invent大會為例，Netflix有多達8位Presenter上臺演講。筆者今年參加過一次AWS re:invent，一次AWSome Day，但凡談到客戶，Netflix一定都是高亮的。
Netflix與AWS可謂是相互成就，可以說，沒有AWS就沒有今天的Netflix；而沒有Netflix，也就沒有AWS的今天。現在的Netflix和當年比已經成長了太多。從2007年12月到2015年12月，在這8年裡用戶時長指數級井噴，增長多達1000倍。這期間也恰好是AWS快速發展的8年。
說起Netflix migrate到AWS這件事還要追溯到2008年8月，發生了一件事情，Netflix的database被corrupted，導致長達三天的時間，沒有任何用戶可以接收到來自Netflix的租賃DVD。我們都知道，對於一個互聯網公司，時間就是金錢，即使是2008年主要還靠DVD為生的Netflix。Netflix的engineering team痛定思痛，在想：怎麼樣才能建立起完美可靠的架構？而防止此類事故不再發生？他們做了一個後來看起來無比正確的決定：架構外包。作為一個大公司，作為一個心高氣傲的Engineering團隊，在當時沒有繼續選擇搭建自主的infrastructure，而是退而選擇了AWS，這點不僅需要勇氣，也需要智慧。（這恐怕也會是未來趨勢，在主機時代已經有公司將IT服務外包，而當今的雲計算時代，彈性、按需、快速等都將使雲計算成為傳統IT的殺手）
2006年AWS才開放了第一個服務S3，2008年的AWS可以說是剛剛起步，在把Scalability的任務交給AWS的同時，Netflix需要很多tools去保證網站的availability，防止failover等等。以及專門為AWS service實現的優化和管理工具。正因為如此，很多Netflix OSS才應運而生。為了防止manual deployment 引起的human error，Netflix設計了這個AWS auto-deployment tool。現在該項目已經在github上擁有超過2100個stars。直到2014年，AWS才跟進推出了類似的tool：AWS CodeDeploy。
Netflix使用AWS總結的經驗：
-Dorothy, you’re not in Kansas anymore.
-Co-tenancy is hard.
-The best way to avoid failure is to fail constantly.
-Learn with real scale, not toy models.
-Commit yourself.
大意如下：
-在自己的數據中心好用的東西，到了雲上不一定好用（軟件設計/容量設計/網絡延遲等）；
-雲設計的基礎就是資源共享，面對的是多租戶；而這會導致各個層面上的吞吐量變化；
-我們常常將位於 AWS 上的 Netflix 軟件架構戲稱為“蘭博架構”；因為我們要求每一個系統都能做到，即使自身依賴的全部系統全軍覆沒，仍能提供服務；
-以真實的網絡環境數據進行實際測試；
結語：反脆弱
殺不死你的讓你更堅強，反脆弱理論告訴我們，擁抱混亂、波動及風險反而讓你從脆弱中收益，這比一開始就堅強更好，越穩定的越脆弱。反之，應當承認脆弱，不斷主動試錯，不斷的接觸小傷害，小傷害殺不死你的，而人體的自我補償機制會讓你抵抗力更強。Chaos Monkey 的原則：
避免大多數失效的主要方式就是經常失效。思考最頻繁發生的且痛苦的是什麼？堅持經常做，一步步自動化，減少人工重複勞動。骨折過的地方再長好，會比以前更結實。同樣的道理，從失敗中吸取教訓，從錯誤中學習，成長型思維。給我們帶來最大利益的，並不是那些試圖幫助我們的人，而是那些曾努力傷害我們，但最終未能如願的人。
同樣的，給我們的系統帶來最大收益的，恰好是這幫混亂、暴力、全心全意攻擊我們系統的，可愛的猴子軍團。
參考：
https://www.zhihu.com/question/19552101/answer/114867581 Netflix 是怎樣的一家公司？
https://zhuanlan.zhihu.com/p/19681894 Netflix和它的混世猴子
https://my.oschina.net/moooofly/blog/828545 Netflix 和 Chaos Monkey
閱讀更多 開發者公眾號大全 的文章
