跟花和尚学系统设计:明星公司之Netflix(中篇)

谁是花和尚?

花和尚是一个定居西雅图的程序员,拥有多年系统设计和开发经验。喜欢研究和总结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: http://techblog.netflix.com/2015/09/moving-from-asgard-to-spinnaker.html

Link: http://techblog.netflix.com/2015/11/global-continuous-delivery-with.html

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: http://techblog.netflix.com/2013/01/announcing-ribbon-tying-netflix-mid.html

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: http://techblog.netflix.com/2012/11/hystrix.html

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: http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html

小结

甩了一堆纯干货,想必大家都有点审美疲劳。我们歇一下,这篇就讲到这里。

如果你问本文涵盖了所有Netflix OSS的精华么?答案是否定的。笔者所希望的是,以后当你考虑用一个架构,或者在实践中发现了一个painpoint而且觉得是一个distributed system的通用问题的时候,不妨搜一搜Netflix OSS,说不定早就被Netflix的架构师解决了。

原文发布于微信公众号 - 包子铺里聊IT(baozitraining)

原文发表时间:2016-06-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Python小屋

Python统计多个Powerpoint文件中幻灯片总数量

晚上吃饭时突然想知道自己做了多少页《Python程序设计》系列教材的配套PPT,于是就有了下面的代码,这套PPT综合了《Python程序设计基础》(ISBN:9...

3845
来自专栏java一日一条

59条令人捧腹但真实的程序员编程语录

我收集了很多关于软件开发者的编程语录。这些语录和软件开发维护、调试、软件bug、软件设计和文档、代码质量、测试和管理等相关。下面这59条编程语录虽然令人捧腹但也...

1624
来自专栏cmazxiaoma的架构师之路

一场让我持续懵比的面试

2234
来自专栏Java编程

成为优秀Java程序员的10大技巧

Java程序员有许多应遵循的守则或最佳实践方式。本文概述了每个开发者最应该遵循的10条守则或戒律,如果不遵循它们,将会导致灾难性后果。

7861
来自专栏程序人生

走进 racket(lisp) 的世界

上周追着看了个大牛的好几篇文章,发现一个叫racket的语言出镜率颇高 —— 这已经是我十月来第三次从各种大牛的文章中接触这个词。就如「惊天魔盗团」里那个被催眠...

4473
来自专栏*坤的Blog

『电子书』分享一波码农必备编程开发类书籍[转]

3463
来自专栏微信公众号:Java团长

Java学习路线

学过一段时间的同学一定会觉得Java学习最头疼的不是语法结构的繁杂,而是Java本身体系结构的庞大。以至于自己不知道接下去该学什么,或者什么样的知识才会对后续的...

2955
来自专栏华章科技

程序猿必须知道的一些有用的(外国)网站

原文:https://github.com/sdmg15/Best-websites-a-programmer-should-visit

1.1K2
来自专栏Java架构

项目经验不丰富、技术不突出的程序员怎么打动面试官?前言 关于项目经验关于基本技术关于个人潜力结语

相信不少的程序员都有过类似的困惑:如果我没有大型的项目经历,也不能靠技术征服面试官,那我要怎么才能给面试官留下一个好印象呢?

791
来自专栏牛客网

三七互娱秋招提前批 java服务端

    我是在6月5号参加了三七互娱的秋招的web后端线上笔试,第二天又参加了java服务端的线上笔试,之后去三七大楼参加open day,然后面试时一面,二面...

1271

扫码关注云+社区

领取腾讯云代金券