科普 | 明星公司之Netflix

点击上方“朱小厮的博客”，选择“设为星标”

回复”1024“获取独家整理的学习资料

本文从一个全局上来介绍一下Netflix这家公司，是一篇科普文，可以在上班的路上或者睡前阅读一下，内容比较轻松，不需要烧脑。

引子

当你深入学习System Design一段时间以后，你会发现，不管是读科技文章还是看tech conference视频，一个公司的名字总是反复出现，避也避不开。

这是哪家公司呢? 刚开始接触System Design的同学可能脑子里会想:是Google还是Facebook? 答案可能会让你大跌眼镜，它是Netflix。

Netflix是什么公司?

Netflix是一家视频公司，提供每月7.99到11.99美元不等的订阅服务(subscription service)。他家采用'All-you-can-eat'的单一模式，在全球拥有8100万subscribers，其中美国超过4600万。2016年初，Netflix刚刚实现了全球布局(Globalization)，意味着在全球的任何一个角落(当然除了中国以及少数几个国家，你懂的)你都可以订阅Netflix服务，观看海量视频。

怎么可能是Netflix?

很多人可能一开始会不理解。别担心，你不是一个人。笔者在开始的时候也有类似的困惑。但仔细思考下来，却又发现Netflix这家公司在Distributed System领域贡献杰出却又在情理之中。为什么呢? 有以下三点原因：

Netflix占据了超过1/3的互联网下载的流量。
Netflix没有自己的hardware infrastructure(what?)，全部依赖AWS。
Netflix积极投入Open Source Community的大军中，这点接下来我会详细讲。

Netflix在Distributed System开源界到底有多火?

每个人心里都有杆秤，但在笔者看来，Netflix在DS开源的广度无人超其右。

Netflix OSS

Netflix的开源项目叫做Netflix OSS(a.k.a Open Source Software)。涵盖范围基本包括了业界绝大部分Distributed System的领域。

摘抄自Netflix自己的github主页他家的开源项目涵盖：

Common Runtime Services & Libraries(e.g. Eureka, Ribbon, Hystrix)
Big Data(e.g. Genie)
Build and Delivery Tools(e.g. Asgard/Spinnaker)
Data Persistence(e.g. EVCache)
Insight, Reliability and Performance(e.g. Simian Army)

因为Netflix在开源社区的影响力，加上Netflix只使用AWS服务，每次AWS re:invent大会，Netflix都会成当之无愧的座上宾，基本每个大部门都会有人上台演讲。以最近的2015年AWS re:invent大会为例，Netflix有多达8位Presenter上台演讲(http://techblog.netflix.com/2015/10/netflix-at-aws-reinvent-2015.html)

Netflix on Github

Netflix的所有开源项目都在github上有project并且可以fork，其中最多的Hystrix和falcor都有超过6000个stars。你可以通过这个link进行查看: https://github.com/Netflix

哪些公司在使用Netflix OSS的产品？

我们来看看Netflix已知的有哪些公司使用了Netflix OSS的产品：https://netflix.github.io/powered-by-netflix-oss.html

在这里面比较知名的有:

Yelp
Yahoo
IBM
Coursera
Yammer(owned by Microsoft)
Spring(没错就是你知道的那个做Spring Framework的公司)
Riot Games

而实际上使用的公司比这些更多，只是没有被统计进去而已。

Netflix开源项目Deep Dive

在这里笔者选择几个有代表性且用户数量多的明星项目跟大家一起分享。

Asgard/Spinnaker

我还记得new grad的时候进公司不久问了老板一个问题：'我们每次deploy时，service就down了，我们岂不是会丢掉很多requests?' 我当时的老板一口茶差点没喷出来。

后来我才知道原来changes可以分步deploy到hosts上。具体步骤分为3步：

在deployment前从VIP/Load balancer/DNS disable该host；
Deployment。host运行app版本被更新为最新版；
在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倒下整个网站都不能用。

再回来讲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和AWS的紧密关系以及Netflix的各种周边和八卦。

Netflix and AWS

Netflix并不是最早的AWS customer，但却是最重要的AWS customer之一。毕竟超过1/3的traffic经过netflix，其中绝大部分还要经过AWS。其流量之大超乎想象。

说起Netflix migrate到AWS这件事还要追溯到2008年8月，在一个夜黑风高的夜晚，Netflix创始人Reed Hastings走在Los Gatos Creek Trail上独自冥想，突然一道流星划过天际，Reed头上灯泡一亮...

画风不对。我们重新讲一遍。

2008年8月发生了一件事情，Netflix的database被corrupted，导致长达三天的时间，没有任何用户可以接收到来自Netflix的租赁DVD。我们都知道，对于一个互联网公司，时间就是金钱，即使是2008年主要还靠DVD为生的Netflix。

Netflix的engineering team痛定思痛，在想：怎么样才能建立起完美可靠的架构？而防止此类事故不再发生？

他们做了一个后来看起来无比正确的决定：架构外包。

作为一个大公司，作为一个心高气傲的Engineering团队，在当时没有继续选择搭建自主的infrastructure，而是退而选择了AWS，这点不仅需要勇气，也需要智慧。

回想当年，笔者2008年还在国内，还记得在那些年国内互联网业界对云计算的态度基本上是嗤之以鼻的，认为是绣花枕头，华而不实，系统还是要自己搭。这个观点对错现在看当然是错的，但当年的AWS稳定性而言跟现在必然是差着数量级的。

当年的AWS刚刚起步，拥有的产品远不如现在丰富，只有EC2，S3等旗舰产品。在把Scalability的任务交给AWS的同时，Netflix需要很多tools去保证网站的availability，防止failover等等。以及专门为AWS service实现的优化和管理工具。正因为如此，很多Netflix OSS才应运而生。

举个例子，比如上文讲解到的Asgard项目始于2010年，为了防止manual deployment 引起的human error，Netflix设计了这个AWS auto-deployment tool。现在该项目已经在github上拥有超过2100个stars。直到2014年，AWS才跟进推出了类似的tool：AWS CodeDeploy。

现在的Netflix和当年比已经成长了太多。举个例子，从2007年12月到2015年12月，在这8年里用户时长指数级井喷，增长多达1000倍。这期间也恰好是AWS快速发展的8年，现在的AWS稳居云计算老大，市场份额超过下6个竞争对手市场份额的总和。Netflix这个赌算是打对了。

现在的Netflix和AWS的关系就像两个好伙伴，每次AWS的re:invent大会，Netflix都不会缺席。Netflix还被当作case study挂在AWS官网上。作为回报，Netflix OSS绝大部分tools都是为AWS量身定做或是兼容的。当然也不是所有人都happy，AWS内部的oncall的朋友开玩笑说：Netflix当年选择AWS就是为了把他们变成Netflix的DevOps，自己就不用雇人了。玩笑归玩笑，但也从侧面反映AWS的oncall活不好干。不过总体来说，Netflix和AWS，谁短期也离不了谁。

Netflix战略

Netflix从1997年起步，到现在已经过去了19年，并成为了streaming领域的龙头。我们说成功永远是实力加运气。撇开运气不说，我们看一看Netflix做对了什么才走到了今天。在笔者看来，有几个关键点Netflix走对了:

1997年，创始人Reed Hastings和Marc Randolph测试了邮寄DVD的可行性，并创建了Netflix。这也是Netflix的第一项服务。到现在Netflix还保留着邮寄DVD这个subscription service。
2007年，Netflix开始了新的'All-You-Can-Eat' streaming subscription service。尽管早在2006年Amazon Video就创立了(那时还叫Amazon Unbox)，但提供的服务却是在网上购买电影电视剧的服务，直到2011年Amazon Video才推出了Amazon Prime Video提供类似Netflix的subscription，但Netflix已经优先抢占市场，稳固了行业老大的地位。
2013年，Netflix发布第一部原创电视剧House of Cards，受到了世界电视剧迷的好评。Netflix此举是非常重要的，光靠购买版权，Netflix永远受制于人，而自主原创剧才能够让Netflix成为市场独一份，就像HBO的Game of Thrones一样成为吸金利器。
2016年，Netflix宣布全球化，全世界200多个国家可以订阅Netflix观看电影电视剧。上篇提到过目前全球8100万用户有4600万在美国，这与美国占世界的人口比例严重不符。这也就意味着Netflix的下一个增长点应该是国际化。Netflix看到了这个机遇，领先于行业对手完成了全球化，为自己争夺了主动权和蛋糕。

Netflix原创剧推荐

笔者把自己看过并喜欢的Netflix原创剧推荐给大家，欢迎留言讨论补充：

House of Cards -- 应该不用怎么讲了，国内最火的Netflix原创剧，给你一个比现实精彩的美国白宫(不过现在被Trump碾压了)。

Making A Murderer -- 笔者最喜欢的Netflix剧！是一个纪录片从一个'杀人犯'视角讲述自己如何两次含冤入狱。温馨提醒：全程心情可能都非常压抑的片子，不建议郁闷的时候看。

Master of None -- 一部讲述二代美国移民的轻喜剧，讲述很多有意思的美国社会现象。比如其中有一集讲拍电视剧里面只能有一个印度裔美国人(主角是印度裔美国人)，于是主角和另一个印度裔抗争到最后，结果终于同意他们俩都出演这个电影，但是给的剧本却是一个印度口音的和一个美国口音的兄弟相聚的故事。这个电视剧每一集总是能让人思考一些影射的社会问题。

Narcos -- 一部类似于Breaking Bad的电视剧，剧的特点是大量的西班牙语，估计是为了讨好西语观众。

Netflix企业文化

作为一个技术宅程序员，看完中篇的技术干货，你可能有一种现在就投简历加入N家的冲动。不过技术是公司的一方面(当然是很重要的一方面)，但撇开技术，这个公司到底是什么样的？

Netflix和很多公司都不大一样。他家绝大多数engineer的title都是Senior Software Engineer Hierarchy及其扁平化。这意味着两件事：

Netflix不喜欢招new grad。毕竟一毕业就当senior是需要实力和勇气的。
同是Senior Software Engineer，你的工资和别人的工资可能有天壤之别。

Netflix给钱给的非常慷慨，慷慨到业界除了他家很少见到如此高的工资。他家动辄给200k到400k的年薪你可以去h1bdata.info这个网站自己查看(http://h1bdata.info/index.php?em=NETFLIX+INC&job=SENIOR+SOFTWARE+ENGINEER&city=&year=) 但缺点是几乎所有的perk都折成工资(不过最近好像有所改观开始给股票ESPP了)。

给的钱多不是让你歇着的：Netflix3个月一次review。对于review的underperformer，难逃进PIP卷铺盖走人的厄运。

当然他家对外宣传的福利还是不错的：unlimited pto and sick days，以及多达12个月maternity and paternity leave。

总结下来就是12个字：收入颇丰，涨知识快，钱不好赚。

Netflix and Chill

由于Netflix在美国的风靡，衍生出来了'Netflix and Chill'这个习语。在这里Netflix做动词就像'Google it yourself'里的'Google'一样表示'看Netflix'。所以字面意思就是'看Netflix并且放松'。

当真就这么单纯么？当然不是。

一开始的时候大家说'Netflix and Chill'真的是去看Netflix了。后来某些心怀不正的少年们就借着这个幌子求啪啪啪了。在越来越多的女性同胞痛斥这个幌子之后，慢慢这个习语就带有性暗示的意思了。所以女同学们如果有一个男同学说今晚上跟我一起去'Netflix and Chill'吧，你最好问清楚他家有几房几车。。。

还有一篇文章专门考证了'Netflix and Chill'的起源(http://fusion.net/story/190020/netflix-and-chill/)。我只能说美国记者要么是太无聊，要么是太敬业。。。

尾声

花了这么多篇幅，终于把我想讲的Netflix的方方面面都讲完了。其实一开始写Netflix的动机只是想写一篇关于Netflix OSS项目的文章科普一下，结果越写越觉得准备大家对Netflix这个公司知道的并不多，所以决定以上帝视角把这个公司的方方面面都尽量讲到。希望对大家了解Netflix这个公司有点帮助(Netflix真该给小编点稿费= =)。

本文是由公众号【包子铺里聊IT（baozitraining）】中的多篇内容整理而来。

想知道更多？扫描下面的二维码关注我

>>>Learn More<<

喜欢就点个"在看"呗^_^