遭遇難以想象4天的宕機後，Netflix用7年時間轉型為最超前的微服務架構
Netflix 是歐美地區最大的網路視訊提供商，使用者超過了 Youtube。全球每天有超過 190 個國家，一億多會員在 Netflix 上觀看 1.2 億小時的電影、電視劇和紀錄片等等。同時，Netflix 也製作了像紙牌屋這樣的廣受歡迎的電視劇。
為了支援大流量，高併發的訪問，Netflix 網站架構經過了一系列的重構。
上圖是 2008 年之前 Netflix 的網站架構，從圖中我們可以看到這是一個非常傳統的架構。
為什麼要實現微服務的轉型？因為 Netflix 有足夠痛的經歷，Netflix 在 2008 年曾經遭遇過一次 4 天的服務宕機，原因是他們生產環境的資料庫掛掉了，並且經過 4 天才得以修復。
這是 2008 年 Netflix 給受影響使用者所傳送的道歉郵件。當時所有的使用者都收不到他們自己訂購的 DVD。難以想象 4 天的宕機，業務停滯，為整個開發團隊帶來多大的壓力。
痛定思痛，Netflix 決定轉型微服務架構，來實現高可用，動態擴容，來應對越來越多的使用者訪問。
Netflix 用了 7 年時間完成了這個轉型，目前，Netflix 的雲平臺上運行了 500 個微服務，每天會有 100-1000 的變更部署到線上環境。
線上環境部署在亞馬遜 3 個 Region，9 個可用區，為全球使用者提供穩定的網路視訊服務。下面來看看 Netflix 實現微服務的原則和經驗總結。
Netflix 微服務開發原則
1.購買 VS 自己開發
2.實現真正無狀態服務
可採取的破壞性措施包括：關閉特定服務介面，關閉特定快取服務，關閉特定 DB 服務，增加網路丟包率，增大網路延遲等。通過這樣的測試來確定自身的微服務是不是真正做到無狀態。
執行破壞性測試的時機一般是特定的時間點和特定的時間段。Netflix 每週一，五凌晨 3 點會在生產環境上進行自動化的破壞性測試，來確保他們的服務在生產環境上是真正無狀態的。
這裡需要注意的是，他們是在生產環境上做破壞性測試，因為你永遠無法模擬和生產環境一模一樣的環境。這樣的測試場景能夠保證線上碰到問題，能夠從容應對。
3.向上擴充套件 VS 水平擴充套件
如果一味的為去提高機器效能，增加 CPU、記憶體，終將有一天會遇到瓶頸。如果系統支援水平擴充套件，那麼系統擴容的空間是很難達到瓶頸的，特別是在雲環境，你可以更容易的獲得足夠的計算資源。
4.彈性伸縮的冗餘和隔離
任何節點都應該有超過一個的冗餘備份，來避免單點失敗。在你的叢集裡，是否能夠支援關掉任何一個節點，且你的叢集還能正常執行？
如果不能，就說明存在單點失敗。一旦發生服務異常，要將服務影響到的範圍做隔離。
Netflix 微服務開發實踐
1.從關係資料庫遷移到 Cassandra
Netflix 的開發者為 Cassandra 資料庫貢獻了很多原始碼，其中一個功能就是做跨 Region 的非同步資料一致性處理。
2.Netflix 如何定義優先順序
如何定義任務的優先順序？對於這個問題，每個團隊都會有不同的的選擇。
在 Netflix，優先順序最高的任務是創新，可靠性是排第二位的，這樣可以保證員工有足夠大的空間進行創新，讓產品能夠快速的迭代。
3.端到端的負責
每個團隊自行負責產品的設計，架構，開發，構建，部署，運維，支援。團隊各自發布自己的模組，團隊間模組解耦，升級時向下版本相容，互不影響。
當每個團隊都獨自管理自己的服務時，你會發現公司的組織結構變成上圖所示的樣子。每個團隊更加的靈活，釋出的速度更快，嘗試新技術的意願也更加強烈。
4.區分關注焦點
為了讓所有業務團隊能夠獨立的交付他們的服務，Netflix 內部有 SRE 團隊，為所有業務開發團隊提供基礎工具鏈的支撐。
SRE 團隊關注的問題是基礎設施，中介軟體的提供和運維，包括效能，可靠性，擴充套件性，安全漏洞，監控等等；業務部門關注的是功能，頁面互動等等。
讓每個團隊關注不同的問題，這樣的好處是保證團隊不會重複去解決相同的問題。
Netflix 微服務經驗總結
1.微服務是組織結構的變化
當你的組織決定接受全部的變化，那就意味著，你不再需要測試團隊，運維團隊。這很困難，大部分人不願意接受變動，這是人員的問題，會被情緒干擾。
之前 Netflix 有測試、DBA、運維的團隊，現在每個團隊自己負責這些任務，SRE 團隊負責底層的基礎架構和中介軟體的支援。
2.微服務的落地需要時間
- 維護兩套系統。
- 支援兩種技術棧。
- 多主節點資料同步。
3.使用快取保護資料庫
Netflix 基於 MemCache 開發了 EVCache。目的在於讓更多的快取被命中。如果沒有命中，請求會訪問到資料庫，這時需要在快取裡補上這條記錄。
4.重視運維視覺化
在每個伺服器上，管理員需要看多少監控報表？Netflix 每秒生成 2 千萬監控資料，這些是人工完全無法去觀察的，所以需要從這些資料裡過濾出哪些是異常資料。
日誌也有同樣的需求，需要具備從大量資料中消除噪音的能力，並且將這些資料可視化出來，有了視覺化的資料，你才能夠對流程進行改進。
5.服務故障處理
破壞性測試不僅僅能夠測出系統處理故障的能力，而且能夠度量團隊是否有足夠多的人瞭解整個系統，當問題發生了，是否能夠快速找到正確的人解決問題。
從上圖可以看到”ChaosCon”測試的實時流量監控。左上角是美國西岸的資料中心，當該中心服務大面積停掉之後，Netflix 會監控到服務的故障區，開始隔離故障區域，通過 DNS 服務遷移使用者訪問流量到東岸資料中心，直到西岸的服務恢復。
“ChaosCon”測試會影響到使用者體驗，Netflix 每個月會做一次 Region 級別的測試。如果你的目標是真正的高可用，那麼你也需要做類似的實踐，從這些事故中總結經驗教訓。
6.容器化
容器化可以大大提高開發者的體驗，增加開發者的滿意度。在 Netflix 實現容器化的時候，社群還沒有成熟的容器管理的平臺，所以他們自己開發了一套容器管理平臺，在這個平臺的研發過程中，也孵化出了大量的開源專案。
幸運的是，目前容器化管理平臺已經有了很多的方案，例如谷歌的 Kubernetes，Apache 的 Mesos，Rancher，Docker 公司的 Swarm 等等，可以去評估，使用，不用去重複造輪子。
Netflix 通過深刻的轉型，從傳統架構的 Java 應用轉型成為最超前的微服務架構，並且通過破壞性測試驗證了微服務在線上環境的高可用性，為高併發請求提供了強大的支撐。
同時，內部團隊的開發模式也得到了改進，基礎工具鏈團隊提供工具支撐，解決所有開發團隊的通用問題；業務團隊只需關注業務功能的實現和創新，這樣做不僅提升了客戶滿意度，也大大提高了開發者的滿意度。
參考資料：
Chaos Monkey 理論：http://principlesofchaos.org/
Chaos Monkey 原始碼：https://netflix.github.io/chaosmonkey/
Hystrix 原始碼：https://github.com/Netflix/Hystrix
作者：王青
來源：JFrog傑蛙DevOps微信公眾號（jfrogchina）