Netflix 的微服務演進之路

背景

Netflix 是全球領先的視頻網站，影片類型包括好萊塢製作，獨立製作電影，本地電影等等，自主研發了「紙牌屋」等知名的電視劇。全球有8千多萬的訂閱會員，覆蓋190個國家（暫未覆蓋中國…），支持一千多種設備類型。

Netflix 是 AWS 服務的重度用戶，在 AWS 上有數萬台虛機。在 DevOps 領域，Netflix 是業界的先驅，他們為 Spring Cloud Netflix 社區貢獻了大量優秀的開源軟體，例如 Eureka，Zuul，Turbine，Hystrix 等等。

遇到的挑戰

Netflix 認為，他們之前的應用架構是典型的巨石應用。雖然實現了應用層面的多活，但是仍然使用單一巨大的代碼庫，單一巨大的資料庫，如果資料庫掛了，整個系統都將癱瘓。

微服務架構是什麼？來複習下 Martin Fowler 的定義：

裡面提到幾個重要的關鍵字：多個微服務，獨立進程，輕量的通訊機制(通常是 HTTP)。

Netflix 任務微服務必須具備以下能力：

服務的關注點分離：

一個服務不能即處理用戶信息，又處理訂單的信息，服務要實現模塊化，並且需要封裝內部的介面，對外提供服務。

服務的水平擴展性：

服務能否順利的水平擴展？擴展一個服務需要多少時間？在服務水平擴展之後，如何將流量分流到新的節點？

虛擬化和彈性計算的能力：

需要能夠實現自動化運維，按需的創建計算環境。

1.Netflix 微服務架構

上圖是整個 Netflix 的服務調用關係圖譜。

左側是 Edge 服務，包含：

ELB （Elastic Load Balance）- 用於做客戶端的請求負載分發。

Zuul – Netflix 的開源網關組件，用於提供動態路由，監控，故障自愈，安全等服務。

API– Netflix 統一調用後端服務的介面層。

右側是中間件服務層：

提供的服務包括：

產品

產品的 A/B 測試

訂閱服務

推薦服務

平台

路由

服務配置

加密

一個典型的微服務，應該具備緩存層，服務層，數據層。

2.Netflix 的痛點

服務間調用失敗

服務之間的調用會出現網路延遲，服務失效，調用邏輯錯誤，以及擴容失敗等問題。

服務故障引發雪崩

當核心服務發生故障，會影響到整體系統的可用性。失效的服務會讓用戶的請求一直等待返回，且一直得不到釋放，伺服器資源被撐爆。

解決方案

優化方案：熔斷器和 FIT

Hystrix（熔斷器）是 Netflix 貢獻的開源組件，Netflix 認為，一個服務掛了，應當被立刻發現，系統不再持續調用該不可用的服務而出現超時返回，而是應當立刻調用一個 FallBack 方法進行錯誤處理。

Netflix 網站的特點是高峰期並發流量非常高，平時流量低，很多應用上線之後，並沒有一個能夠完全模擬線上環境流量的測試環境去驗證應用的高可用性。為了解決這些問題，Netflix 搭建了 Fault Injection Testing(FIT) 框架做容錯性測試。它主要提供3種能力：

模擬線上流量

將真實的線上環境流量推到100%進行壓測，看高並髮狀態下的真實反應。

Netflix 的微服務分為2種，一是核心服務，即用戶載入應用，觀看視頻等，另一種是非核心服務。FIT 能夠創建一個場景，將所有非核心服務停掉，看用戶是否還能享受 Netflix 的核心服務。

優化方案: 分散式數據一致性

Netflix 的數據需要存儲在 AWS 不同的可用區，而一條數據寫入多個可用區的資料庫存儲延遲，那麼就有可能部分寫失敗，Netflix 在 CAP 理論中，選擇了最終一致性來解決這個問題。Netflix 使用 Cassandra 作為分散式資料庫，當你寫入可用區 B 的數據時，Cassandra 會自動複製到其他可用區。你可以使用 Quorum 進行靈活的寫策略，比如寫入一個節點成功，你就認為整個集群的寫入成功，讓 Cassandra 幫你做剩下的同步，你也可以設置讓整個集群的寫入成功，才認為該條數據寫成功。

優化方案: 無狀態的緩存服務

傳統的緩存服務例如 Squid，即使你可以做到 Squid 基於用戶 ID 做 Sharding 來分擔高並發的請求，這樣每個用戶能夠訪問到自己的緩存，但每個 Sharding 仍然存在單點故障，某一個 Squid 服務掛了，仍然會帶來雪崩。Netflix 最初就是使用 Squid 做分片緩存，但當一個分片掛掉是，Netflix 發生了3個小時的宕機。

所以 Netflix 採用了多寫的分散式緩存 EVCache，EVCache 封裝了 MemcacheD 實現分散式緩存。每個 EVCache 客戶端會將緩存數據寫入多個可用區的緩存伺服器，避免緩存伺服器的單點故障。而客戶端讀緩存時，只需從本地可用區進行讀取。

通過 EVCache 集群的搭建，Netflix 支持了3千萬次/秒的請求。可是問題又來了，當每個應用都來請求線上的 EVCahce 之後，該服務本身會遇到瓶頸。很多後台任務(Batch)，例如推薦服務會頻繁訪問線上的緩存，於是 Netflix 將線上和線下的緩存分離，這樣的優勢在於後台任務不會影響到線上的緩存服務。

優化方案: 上線檢查的 Checklist

Netflix 在持續的運維工作中，總結出來很多最佳實踐，他們在上線之前都有一個檢查清單，會覆蓋告警，自動化金絲雀發布的分析，自動擴容，ELB 配置，壓力測試，藍綠部署，失敗回滾等。

Netflix 使用 Nebula 構建，Jenkins 做 CI，JFrog Artifactory做製品庫的管理（.jar, .deb, Docker 鏡像），並且開源了他們的持續部署平台Spinnaker。Spinnaker 能夠實現自動化的金絲雀發布，往前能夠對接 Jenkins，往後能夠對接 AWS，Kubernetes 集群的部署。它能夠為金絲雀發布的每個階段進行自動化評分，評分會包含服務狀態，用戶反饋，系統異常等信息進行評估，從而用機器決策是否進入到下一個金絲雀發布的階段。

Netflix 公司能夠實現快速的發布服務，一個很重要的地方是在於線上服務的容錯性做得非常成熟，他們的程序員提交代碼也會讓線上服務失敗。

從上圖可見，在工作日 Netflix 的服務失敗時間很高，但由於服務的降級，隔離處理都是自動化完成，所以程序員有充分的自信去提交代碼，修復問題。

總結

Netflix 的運維團隊為公司提供了強大的基礎設施，這為業務開發團隊帶來了極大的快速發布的能力，實現將 Idea 變成線上服務的時間大大縮短，運維團隊在公司的價值大大提升！

參考資料：

https://www.youtube.com/watch?v=CZ3wIuvmHeM

https://github.com/Netflix/zuul

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！