標籤：

跟花和尚學系統設計：明星公司之Netflix(中篇)

02-04

誰是花和尚？

花和尚是一個定居西雅圖的程序員，擁有多年系統設計和開發經驗。喜歡研究和總結System Design, 並傳授給大家。花和尚在MITBBS一篇 "我的System Design總結" 文章獲得超過8萬訪問量，並被多家網站和博客轉載。

Netflix開源項目Deep Dive

上篇給了大家很多Netflix和Netflix OSS的context。本篇將直入主題，在這裡筆者選擇幾個有代表性且用戶數量多的明星項目跟大家一起分享。

Asgard/Spinnaker

我還記得new grad的時候進公司不久問了老闆一個問題："我們每次deploy時，service就down了，我們豈不是會丟掉很多requests?" 我當時的老闆一口茶差點沒噴出來。

後來我才知道原來changes可以分步deploy到hosts上。具體步驟分為3步：

  1. 在deployment前從VIP/Load balancer/DNS disable該host；
  2. Deployment。host運行app版本被更新為最新版；
  3. 在deployment完成後再把host加回VIP/Load balancer/DNS。

在Amazon這個deployment tool叫做Apollo，以後介紹Amazon的文章會專門講。

當然，說起來簡單，如何實現對ASG分批host的deployment？如何在alarm被trigger後rollback deployment？這些都不是一個trivial的問題。幸運的是，Asgard幫我們解決了這個問題。

Asgard界面

Asgard是一個deployment management tool。它與AWS tightly coupled together，提供了一個簡單的平台和UI幫助你實現deployment的管理。它管理了Elastic Load Balancers (ELBs), Auto Scaling Group (ASG), Amazon Machine Image(AMI)的更新和交互，以及deployment fast rollback和task automation。

ASG, AMI和ELB在deployment中的交互過程

Asgard解決了deployment的問題，但也帶來了新問題：

  • 隨著業界的發展 Continuous Delivery(a.k.a. CD)成了下一個the thing。SDE們希望隨時可以test並deploy 且擁有不同的deployment stage(e.g. alpha, beta, gamma, onebox and prod)
  • 如果我不想使用AWS怎麼辦？
  • 很多人fork了asgard的branch並沒有contribute back

為了解決這些問題，Netflix創建了Spinnaker。

Spinnaker

值得一提的是，Spinnaker的出現並不是說明Asgard是不重要的，而是在Asgard的原有functionality的基礎上又添加了更多功能來實現CD。它解決了筆者拋出的以上3個問題：

  • 提供了一個完整的Deployment Pipeline。包含了不同的stage和testing workflow。
  • 支持多個平台，包括AWS, Google Cloud Platform, Microsoft Azure, etc。
  • 更開放的開源平台，支持community support and contribution。

Link: techblog.netflix.com/20

Link: techblog.netflix.com/20

See also: Jenkins, Amazon Apollo/AWS CodeDeploy & CodePipeline

Eureka

Eureka是Netflix提供的mid-tier service registry service。它的主要作用是Service Discovery。筆者管它叫做"Service of Services"。

你可能會問：為什麼不能用普通的VIP？

原因是AWS的EC2 instances come and go，並不是static的hosts，所以也沒有static的IP和hostname。這就需要更複雜的load balancer來處理不停變化的cluster。

你可能又會問：那AWS自帶的ELB總可以handle EC2 instances的come and go的不確定性吧？為什麼不直接使用而要reinvent the wheel呢？

這是個好問題。要解釋清楚這個事情 還要牽扯到Microservices的概念。

Netflix microservices dependency graph

Microservices究竟是什麼意思呢？用筆者自己的話來解釋，其實就是一種觀點：這種觀點認為與其做一個超級無敵大的單個web application(a.k.a. Monolithic application)來handle所有business logic，不如做一批量的microservices，每一個microservice處理一塊相對獨立的business logic，然後把所有microservices以dependency graph的形式相互依存連接起來。

Monolithic application vs. Microservices

Microservices的優點有：

  • 每個component可以獨立選擇programming language，Framework。
  • 每個component可以獨立scale
  • 每個component可以有獨立的strategy實現failover或是degraded experience，而不需要一個大app倒下整個網站都不能用。

關於更深入的Microservices的知識我會單獨開一篇文章講述。

再回來講ELB，ELB的確可以擔負起load balancing這塊的責任。那麼這種情況下，每一個microservice的前面都需要加一個ELB來做load balancer。這樣做的缺點是：

  • ELB的主要用途是做edge service的load balancer。屬於heavy-lifting的load balancer，cost不小，也有點大材小用。
  • ELB使用的是外部IP，如果你的service並沒有準備handle external traffic，那麼too bad，全世界都知道你有這個service了。

Eureka解決的正是這個mid-tier AWS LB的缺失，有了它，你可以方便的知道所有的service並且輕易的integrate(當然authorization也是必須的)。Eureka和下面要提到的Ribbon一起負擔了mid-tier ELB的作用。 如下圖:

Ribbon

Ribbon是client-side的load balancing tool。它和Eureka一起實現了internal service ELB的功能。

舉一個例子，當一個request要從service A發送給service B(也就是Service A的dependency)的時候，service A會先make a request to Eureka，得到service B的metadata，包括hosts信息。然後Ribbon這個library會被調用讀取host信息，做出選擇來訪問其中的一個host然後得到response。

Ribbon有幾種選擇模式:

  • Simple Round Robin LB
  • Weighted Response Time LB
  • Zone Aware Round Robin LB
  • Random LB

著重講一下第三種Zone Aware Round Robin LB。這也是Netflix根據AWS的多ASG而量身定做的。在選取host的時候，Ribbon會根據Service A所在的ASG而優先訪問同樣ASG的service B的host(a.k.a. Zone Affinity)這樣減少了latency的同時還節約了cost。

同時，Ribbon還實時監控每個ASG的健康狀況。當一個ASG的request數量超過最大值或者當ASG down掉的時候，Ribbon會直接drop掉整個ASG。AWS雖然貴為最穩定的雲計算平台，但每隔一兩年搞掉一兩個ASG甚至一個region還是很正常的，而Netflix網站和traffic卻沒有因此受到絲毫影響，筆者猜測Ribbon應該是居功至偉。

Link: techblog.netflix.com/20

Hystrix

Hystrix的作用是client-side fail tolerance management。還用剛才的例子：假如Service B down掉了，Service A是否也不能運行？在Netflix的設定下，假如Service A是Netflix的主頁面，而Service B是Netflix的recommendation service，那麼我們完全可以認為即使Service B完全無法運轉，Service A也應該繼續運行，即使提供的是degraded experience。

比如在這種情況下，Service A應該得到的結果可以是一個pre-defined top picks list，這樣recommend給用戶的就是最popular的節目，在一定時間內也不會有任何問題(順帶吐槽一下，大多數recommendation system的performance其實比直接給最popular的shows也沒好到哪裡去。。。)。

Hystrix還提供了dashboard，供你實時觀測有多少request得到的response是fallback behavior，從而估測到每個dependency service的健康狀況。只能說非常貼心。

Link: techblog.netflix.com/20

Simian Army/Chaos Monkey

測試Microservices的穩定性一直是個世界級難題，Netflix擁有上百個services，無數種掛掉的combination，作為一個程序猿，我怎麼知道在每一種scenario下Netflix是否還能正常運行？你需要另一個猴子幫你：Introducing Simian Army and Chaos Monkey。

Simian Army直譯就是類人猿軍隊，是一個測試套裝。其中最有名的就是Chaos Monkey，直譯就是製造混亂的猴子。

這個猴子用來幹什麼呢？它在所有service的dependency graph里，每次隨機挑幾個service，把它們弄掛(當然testing是在test stage進行的，這時候spinnaker就派上用場了)，看看Netflix as a whole的輸出結果是否還是expected的(expected behavior嚴重依賴於Hystrix)。

筆者工作中也進行過很多次gameday，一起測試org下的幾十個services，但每一次都是固定的測試某些個系統掛掉的scenario。當筆者第一次看presentation聽到這個tool的時候可想而知是相當被震撼到的，也深深的成為了Netflix的腦殘粉。

Link: techblog.netflix.com/20

小結

甩了一堆純乾貨，想必大家都有點審美疲勞。我們歇一下，這篇就講到這裡。

如果你問本文涵蓋了所有Netflix OSS的精華么？答案是否定的。筆者所希望的是，以後當你考慮用一個架構，或者在實踐中發現了一個painpoint而且覺得是一個distributed system的通用問題的時候，不妨搜一搜Netflix OSS，說不定早就被Netflix的架構師解決了。

這就沒了？

中篇到此結束。別急，下篇我們侃一侃Netflix和AWS那點事兒，並聊一聊Netflix技術以外的八卦。

請勾搭包子君

微信：bao-zi-jun

推薦閱讀：

※什麼是 Design System
※統一業務後台架構如何設計？
※如何答好面試中的系統設計題？
※系統設計學期小結：nThink Not Like A Designer, But Like A Worm

TAG:分布式 | Netflix | 系统设计 |