[[206362]]

Netflix 是歐美地區最大的網絡視頻提供商，用戶超過了 Youtube。全球每天有超過 190 個國家，一億多會員在 Netflix 上觀看 1.2 億小時的電影、電視劇和紀錄片等等。同時，Netflix 也制作了像紙牌屋這樣的廣受歡迎的電視劇。

[[206363]]

為了支持大流量，高并發的訪問，Netflix 網站架構經過了一系列的重構。

上圖是 2008 年之前 Netflix 的網站架構，從圖中我們可以看到這是一個非常傳統的架構。

為什么要實現微服務的轉型?因為 Netflix 有足夠痛的經歷，Netflix 在 2008 年曾經遭遇過一次 4 天的服務宕機，原因是他們生產環境的數據庫掛掉了，并且經過 4 天才得以修復。

這是 2008 年 Netflix 給受影響用戶所發送的道歉郵件。當時所有的用戶都收不到他們自己訂購的 DVD。難以想象 4 天的宕機，業務停滯，為整個開發團隊帶來多大的壓力。

痛定思痛，Netflix 決定轉型微服務架構，來實現高可用，動態擴容，來應對越來越多的用戶訪問。

Netflix 用了 7 年時間完成了這個轉型，目前，Netflix 的云平臺上運行了 500 個微服務，每天會有 100-1000 的變更部署到線上環境。

線上環境部署在亞馬遜 3 個 Region，9 個可用區，為全球用戶提供穩定的網絡視頻服務。下面來看看 Netflix 實現微服務的原則和經驗總結。

Netflix 微服務開發原則

01購買 VS 自己開發

當 Netflix 需要一個功能時，如果有現有的方案可以購買(當然這里的“購買”不僅僅是購買第三方的服務，也包括開源軟件的使用和貢獻。)，他們會選擇不去開發這個功能。

只有在市面上或開源社區里沒有解決方案時，他們才會考慮自己開發這個功能。這樣做的目的，是快速的實現需求，提供服務，而不是將大把的研發資源投入在重復造車輪上。

02實現真正無狀態服務

不依賴 Sticky Session，你的服務是否是真正的無狀態?這可通過破壞性測試(Chaos Monkey)來驗證。

由于 Netflix 無法在測試環境完全模擬出真實的線上環境，導致很多微服務的可用性問題在測試環境測試時沒法發現，但是在線上環境卻頻繁發現微服務并不是完全高可用，于是 Netflix 決定在線上環境進行破壞性測試。

Chaos Monkey 的作用是識別云環境中的服務，然后隨機的對他們進行關閉，對系統實施破壞。

可采取的破壞性措施包括：關閉特定服務接口，關閉特定緩存服務，關閉特定 DB 服務，增加網絡丟包率，增大網絡延遲等。通過這樣的測試來確定自身的微服務是不是真正做到無狀態。

運行破壞性測試的時機一般是特定的時間點和特定的時間段。Netflix 每周一，五凌晨 3 點會在生產環境上進行自動化的破壞性測試，來確保他們的服務在生產環境上是真正無狀態的。

這里需要注意的是，他們是在生產環境上做破壞性測試，因為你永遠無法模擬和生產環境一模一樣的環境。這樣的測試場景能夠保證線上碰到問題，能夠從容應對。

03向上擴展 VS 水平擴展

如果一味的為去提高機器性能，增加 CPU、內存，終將有一天會遇到瓶頸。如果系統支持水平擴展，那么系統擴容的空間是很難達到瓶頸的，特別是在云環境，你可以更容易的獲得足夠的計算資源。

04彈性伸縮的冗余和隔離

任何節點都應該有超過一個的冗余備份，來避免單點失敗。在你的集群里，是否能夠支持關掉任何一個節點，且你的集群還能正常運行?

如果不能，就說明存在單點失敗。一旦發生服務異常，要將服務影響到的范圍做隔離。

Netflix 微服務開發實踐

01從關系數據庫遷移到 Cassandra

Netflix 的開發者為 Cassandra 數據庫貢獻了很多源代碼，其中一個功能就是做跨 Region 的異步數據一致性處理。

02Netflix 如何定義優先級

如何定義任務的優先級?對于這個問題，每個團隊都會有不同的的選擇。

在 Netflix，優先級最高的任務是創新，可靠性是排第二位的，這樣可以保證員工有足夠大的空間進行創新，讓產品能夠快速的迭代。

03端到端的負責

每個團隊自行負責產品的設計，架構，開發，構建，部署，運維，支持。團隊各自發布自己的模塊，團隊間模塊解耦，升級時向下版本兼容，互不影響。

當每個團隊都獨自管理自己的服務時，你會發現公司的組織結構變成上圖所示的樣子。每個團隊更加的靈活，發布的速度更快，嘗試新技術的意愿也更加強烈。

04區分關注焦點

為了讓所有業務團隊能夠獨立的交付他們的服務，Netflix 內部有 SRE 團隊，為所有業務開發團隊提供基礎工具鏈的支撐。

SRE 團隊關注的問題是基礎設施，中間件的提供和運維，包括性能，可靠性，擴展性，安全漏洞，監控等等;業務部門關注的是功能，頁面交互等等。

讓每個團隊關注不同的問題，這樣的好處是保證團隊不會重復去解決相同的問題。

Netflix 微服務經驗總結

01微服務是組織結構的變化

當你的組織決定接受全部的變化，那就意味著，你不再需要測試團隊，運維團隊。這很困難，大部分人不愿意接受變動，這是人員的問題，會被情緒干擾。

之前 Netflix 有測試、DBA、運維的團隊，現在每個團隊自己負責這些任務，SRE 團隊負責底層的基礎架構和中間件的支持。

02微服務的落地需要時間

進行微服務落地的這個階段，你會經歷：

維護兩套系統。

支持兩種技術棧。

多主節點數據同步。

03使用緩存保護數據庫

Netflix 基于 MemCache 開發了 EVCache。目的在于讓更多的緩存被命中。如果沒有命中，請求會訪問到數據庫，這時需要在緩存里補上這條記錄。

04重視運維可視化

在每個服務器上，管理員需要看多少監控報表?Netflix 每秒生成 2 千萬監控數據，這些是人工完全無法去觀察的，所以需要從這些數據里過濾出哪些是異常數據。

日志也有同樣的需求，需要具備從大量數據中消除噪音的能力，并且將這些數據可視化出來，有了可視化的數據，你才能夠對流程進行改進。

05服務故障處理

首先確認故障的級別是核心業務故障還是非核心業務故障。同時你需要讓服務以最快的速度回滾。

Netflix 孵化并開源了一個工具叫做 Hystrix。這個工具的作用是幫助分布式服務中增加延遲容錯和故障回滾的邏輯。在服務發生故障時，幫助你隔離故障服務的訪問接口，提供回滾機制，確保故障不會大面積擴散。

進行 Region 級別的破壞性測試，Netflix 舉行了一個"ChaosCon"的活動，活動測試目標是將美國西岸數據中心的所有線上服務器進行 Chaos Monkey 測試。有 40 個工程師參與了在線的搶修恢復，花了 4 個小時，全部修復了問題。

隨后 Netflix 又舉辦了第二次"ChaosCon"活動，這次只有 20 個工程師，花了 2 個小時解決了全部問題。到了今天，所有修復的方案都變成了腳本，自動化的修復線上的故障。

破壞性測試不僅僅能夠測出系統處理故障的能力，而且能夠度量團隊是否有足夠多的人了解整個系統，當問題發生了，是否能夠快速找到正確的人解決問題。

[[206367]]

從上圖可以看到"ChaosCon"測試的實時流量監控。左上角是美國西岸的數據中心，當該中心服務大面積停掉之后，Netflix 會監控到服務的故障區，開始隔離故障區域，通過 DNS 服務遷移用戶訪問流量到東岸數據中心，直到西岸的服務恢復。

"ChaosCon"測試會影響到用戶體驗，Netflix 每個月會做一次 Region 級別的測試。如果你的目標是真正的高可用，那么你也需要做類似的實踐，從這些事故中總結經驗教訓。

06容器化

容器化可以大大提高開發者的體驗，增加開發者的滿意度。在 Netflix 實現容器化的時候，社區還沒有成熟的容器管理的平臺，所以他們自己開發了一套容器管理平臺，在這個平臺的研發過程中，也孵化出了大量的開源項目。

幸運的是，目前容器化管理平臺已經有了很多的方案，例如谷歌的 Kubernetes，Apache 的 Mesos，Rancher，Docker 公司的 Swarm 等等，可以去評估，使用，不用去重復造輪子。

Netflix 通過深刻的轉型，從傳統架構的 Java 應用轉型成為最超前的微服務架構，并且通過破壞性測試驗證了微服務在線上環境的高可用性，為高并發請求提供了強大的支撐。

同時，內部團隊的開發模式也得到了改進，基礎工具鏈團隊提供工具支撐，解決所有開發團隊的通用問題;業務團隊只需關注業務功能的實現和創新，這樣做不僅提升了客戶滿意度，也大大提高了開發者的滿意度。