Netflix 背景
Netflix 是歐美地區最大的網絡視頻提供商，超過了 Youtube。全球每天有超過190個國家，一億多會員在 Netflix 上觀看1.2億小時的電影，電視劇和紀錄片等等。Netflix 也製作了像紙牌屋這樣的廣受歡迎的電視劇。
爲了支持大流量，高併發的訪問，Netflix 網站架構經過了一些列的重構。上圖是08年之前 Netflix 的網站架構，可以看到這是一個非常傳統的架構。爲什麼要實現微服務的轉型？因爲 Netflix 有足夠痛的經歷，Netflix 在2008年曾經遭遇過一次4天的服務宕機，原因是他們生產環境的數據庫掛掉了，並且經過4天才得以修復。
這是2008年 Netflix 給受影響用戶所發送的道歉郵件。所有的用戶都收不到他們訂購的 DVD。難以想象4天的宕機，業務停滯，爲整個開發團隊帶來多大的壓力。
痛定思痛，Netflix 決定轉型微服務架構，來實現高可用，動態擴容，來應該越來越多的用戶訪問。Netflix 用了7年時間完成了這個轉型，目前，Netflix 的雲平臺上運行了500個微服務，每天會有100-1000的變更部署到線上環境。線上環境部署在亞馬遜3個 Region，9個可用區，爲全球用戶提供穩定的網絡視頻服務。來看看 Netflix 實現微服務的原則和經驗總結。
Netflix 微服務開發原則
原則1：購買 VS 自己開發
當 Netflix 需要一個功能時，如果有現有的方案可以購買，（當然這裏的'購買'不僅僅是購買第三方的服務，也包括開源軟件的使用，和貢獻。）他們會選擇不去開發這個功能。
只有在市面或開源社區裏沒有解決方案時，他們纔會考慮自己開發這個功能。這樣做的目的，是快速的實現需求，提供服務，而不是將大把的研發資源投入在重複造車輪上。
原則2：實現真正無狀態服務
不依賴 Sticky Session，你的服務是否是真正的無狀態？通過破壞性測試（Chaos Monkey）來驗證。
由於 Netflix 無法在測試環境完全模擬出真實的線上環境，導致很多微服務的可用性問題在測試環境測試沒法發現，但是在線上環境缺頻繁發現微服務並不是完全高可用，於是 Netflix 決定在線上環境進行破壞性測試。
Chaos Monkey 的作用是識別雲環境中的服務，然後隨機的對他們進行關閉，對系統實施破壞。可採取的破壞性措施包括：關閉特定服務接口，關閉特定緩存服務，關閉特定DB服務，增加網絡丟包率，增大網絡延遲等。通過這樣的測試來確定自身的微服務是不是真正做到無狀態。
運行破壞性測試的時機一般是特定的時間點和特定的時間段。Netflix 每週一，五凌晨3點會在生產環境上進行自動化的破壞性測試，來確保他們的服務在生產環境上是真正無狀態的。注意，他們是在生產環境上做破壞性測試，因爲你永遠無法模擬和生產環境一模一樣的環境。這樣的測試場景能夠保證線上碰到問題，能夠從容應對。
原則3：向上擴展 VS 水平擴展
如果一味的去爲機器提高性能，增加 CPU，內存，終將會有一天會遇到瓶頸。如果系統支持水平擴展，那麼你擴容的空間是很難達到瓶頸的，特別是在雲環境，你可以更容易的獲得足夠的計算資源。
原則4：彈性伸縮的冗餘和隔離
任何東西都應該有超過一個的冗餘備份，來避免單點失敗。在你的集羣裏，是否能夠支持關掉任何一個節點，且你的集羣還能正常運行？如果不能，就說明存在單點失敗。一旦發生服務異常，要將服務影響到的範圍做隔離。
實踐：數據 - 從關係數據庫遷移到 Cassandra
Netflix 的開發者爲 Cassandra 數據庫貢獻了很多源代碼，其中一個功能就是做跨 Region 的異步數據一致性處理。
實踐：Netflix 如何定義優先級
如何定義任務的優先級？對於這個問題每個團隊都會有不同的的選擇。在 Netflix，優先級最高的任務，是創新，可靠性是排第二位的，這樣保證員工有足夠大的空間進行創新，讓產品能夠快速的迭代。
實踐：端到端的負責
每個團隊自行負責產品的設計，架構，開發，構建，部署，運維，支持。團隊各自發布自己的模塊，團隊間模塊解耦，升級時向下版本兼容，互不影響。
當每個團隊都獨自管理自己的服務時，你會發現公司的組織結構變成的上圖所示的樣子。每個團隊更加的靈活，發佈的速度更快，嘗試新技術的意願也更加強烈。
實踐：區分關注焦點
爲了讓所有業務團隊能夠獨立的交付他們的服務，Netflix 內部有 SRE 團隊，爲所有業務開發團隊提供基礎工具鏈的支撐。SRE 團隊關注的問題是基礎設施，中間件的提供和運維，包括性能，可靠性，擴展性，安全漏洞，監控等等；業務部門關注的是功能，頁面交行等等。讓每個團隊關注不同的問題，這樣的好處是保證團隊不會重複去解決相同的問題。
經驗總結
微服務是組織結構的變化
當你的組織決定接受全部的變化，那就意味着，你不再需要測試團隊，運維團隊。這很困難，大部分人不願意接受變動，這是人員的問題，會被情緒干擾。之前 Netflix 有測試，DBA，運維的團隊，現在每個團隊自己負責這些任務，SRE 團隊負責底層的基礎架構和中間件的支持。
微服務的落地需要時間
進行微服務落地的這個階段你會經歷：
維護兩套系統。
支持兩種技術棧。
多主節點數據同步。
使用緩存保護數據庫
Netflix 基於 MemCache 開發了 EVCache。目的在於讓更多的緩存被命中。如果沒有命中，請求會訪問到數據庫，這時需要將緩存裏補上這條記錄。
重視運維可視化
在每個服務器上需要看多少監控報表？Netflix 每秒生成2千萬監控數據，這些是人工完全無法去觀察的，所以需要從這些數據裏過濾哪些是異常數據。日誌也有同樣的需求，需要具備從大量數據中消除噪音的能力，並且將這些數據可視化出來，有了可視化的數據，你才能夠對流程進行改進。
服務故障處理
首先確認故障的級別是核心業務故障還是非核心業務故障。同時你需要讓服務以最快的速度回滾。Netflix 孵化並開源了一個工具叫做 Hystrix。這個工具的作用是幫助分佈式服務中增加延遲容錯和故障回滾的邏輯。在服務發生故障時，幫助你隔離故障服務的訪問接口，提供回滾機制，確保故障不會大面積擴散。
進行 Region 級別的破壞性測試。Netflix 舉行了一個"ChaosCon"的活動，活動測試目標是將美國西岸數據中心的所有線上服務器進行 Chaos Monkey 測試。有40個工程師參與了在線的搶修恢復，花了4個小時，全部修復了問題。隨後又舉辦了第二次"ChaosCon"活動，這次只有20個工程師，花了兩個小時解決了全部問題。到了今天，所有修復的方案都變成了腳本，自動化的修復線上的故障。
破壞性測試不僅僅能夠測出系統處理故障的能力，而且能夠度量團隊是否有足夠多的人瞭解整個系統，當問題發生了，是否能夠快速找到正確的人解決問題。
從上圖可以看到這是"ChaosCon"測試的實時流量監控。左上角是美國西岸的數據中心，將該中心服務大面積停掉之後，Netflix 會監控到服務的故障區，開始隔離故障區域，通過 DNS 服務遷移用戶訪問流量到東岸數據中心，直到西岸的服務恢復。
"ChaosCon"測試會影響到用戶體驗，Netflix 每個月會做一次 Region 級別的測試。如果你的目標是真正的高可用，那麼你也需要做類似的實踐，從這些事故中總結經驗教訓。
容器化
容器化可以大大提高開發者的體驗，增加開發者的滿意度。在 Netflix 實現容器化的時候，社區還沒有成熟的容器管理的平臺，所以他們自己開發的一套容器管理平臺，在這個平臺的研發過程中，也孵化出了大量的開源項目。幸運的是，目前容器化管理平臺已經有了很多的方案，例如谷歌的 Kubernetes，Apache 的 Mesos，Rancher，Docker 公司的 Swarm 等等，可以去評估，使用，不要去重複造輪子。
Netflix 通過深刻的轉型，從傳統架構的 Java 應用轉型成爲最超前的微服務架構，並且通過破壞性測試驗證了微服務在線上環境的高可用性，爲高併發請求提供了強大的支撐。同時，內部團隊也開發模式也得到了改進，基礎工具鏈團隊提供工具支撐，解決所有開發團隊的通用問題，業務團隊只需關注業務功能的實現和創新，這樣做不僅提升了客戶滿意度，也大大提高的開發者的滿意度。
下載JFrog Artifactory 開源版（代替 Nexus）：
http://www.jfrogchina.com/open-source/
下載JFrog Artifactory 企業版(免費試用)：
https://www.jfrog.com/artifactory/free-trial/?lang=zh-hans#High-Availability
參考資料：
Chaos Monkey 理論：http://principlesofchaos.org/
Chaos Monkey 源碼：https://netflix.github.io/chaosmonkey/
Hystrix 源碼：
https://github.com/Netflix/Hystrix
關於JFrog
世界領先DevOps平臺
公司成立於2008年，在美國、以色列、法國、西班牙，以及中國北京市擁有超過200名員工。JFrog 擁有3000多個付費客戶，其中知名公司包括如騰訊、谷歌、思科、Netflix、亞馬遜、蘋果等。連續兩年，JFrog 被德勤評選爲50家發展最快的技術公司之一，並被評爲硅谷增長最快的私營企業之一。