Netflix与AWS之间不得不说的混乱猴子军团
之前提到Netflix，只知道纸牌屋。前一段在学DevOps Professional，才知道ChaosMonkey原来出自这家公司。稍微调查一下不打紧，原来Eureka，Hystrix都是出自Netflix。立马路转粉，加之近半年多来都对Amazon和AWS很感兴趣，Netflix与AWS之间又是千丝万缕的好基友。恰逢五一放假，抽空把近期有关Netflix的内容组织整理，便形成了本文。
大部分内容搬运自文后的参考资料，本人做了调整，同时加入自己的观点。如有不妥，还望告知。
Netflix的故事
Netflix是什么
Netflix是一家视频公司，提供每月7.99到11.99美元不等的订阅服务(subscription service)。他家采用"All-you-can-eat"的单一模式，在全球拥有8100万subscribers，其中美国超过4600万。
Netflix的起源
很久很久以前，有一家公司叫Blockbuster，称霸租碟业许多年。某个叫Reed Hastings的哥们在那里租了个碟，结果由于超期归还被黑走“一大笔”逾期费（大概40美元），怒了。然后他忿忿地去健身，发觉健身房商业模式甚是美哉，不管你去得多还是少，会员费半毛钱也不能少交。很不巧，Hastings是一个动不动就要改变世界的软件工程师，想法来了就要干，更不巧的是他当时已经非常有钱。于是愤怒之余他创办了Netflix，也是做租碟生意，没有逾期费并且搞会员制。十三年后Netflix把Blockbuster干到了破产保护，大仇得报。这个故事告诉我们两个道理：1.客户服务一定要做好，不该薅的羊毛就别死命薅，不然你就是逼羊为虎。2. 工程师惹不起。
Blockbuster搞的是录像带和碟片租赁，和摩拜、ZipCar等一样，都是自营商品的共享经济，只是它没有借助互联网。而Netflix从名字上就能感受到深深的互联网基因。Netflix只对Blockbuster模式做了两个改变 1. 轻资产化，无店面，网上运营。2. 邮碟到户。轻资产电商+共享+O2O快递模式。一幅图能看出来Netflix逐年对Blockbuster的蚕食。
2006年是Netflix流媒体（streaming）的元年，随着美国宽带普及率逐年上升，2005年Youtube的出现，Netflix开始革自己的命。从实体租赁到内容在线提供，像极了传统产品供应商向云服务模式的转型。2005年流媒体之前，Netflix订阅人数为420万；2016年流媒体十年之后，Netflix订阅人数为8320万。十年十倍增长，足以看出在线服务模式区别于实体产品提供模式的成本边际递减及规模效应。美国的有线电视价格高昂，一般的都要七十甚至一百五每月。而NETFLIX在十几块的价位上提供了几乎是最大的内容库，Netflix模式如此受欢迎闭着眼睛也能明白，美国人甚至造出一句俚语“Netflix and chill”（直接含义及引申含义自己Google）。
Netflix的成功，除了在模式和内容上的苦心经营，技术上的投入居功至伟。Netflix看起来在娱乐业，其实是个科技公司。从一开始单挑Blockbuster，Netflix骨子里玩的就是一个O2O的概念，离不开信息技术的开路。时至如今更是如此，Netflix是出了名的开着业内顶薪打着灯笼挖IT工程师，公司官网专门开设Netflix Tech Blog讨论各种尖端技术问题。
Netflix的混乱猴子军团
铺垫了那么多，终于到了本文的重点，Netflix占到北美网络流量的1/3强，而背后则是AWS的支撑。无论是底层网络、存储与计算，还是大数据、人工智能应用，Netflix可是把AWS各项服务的能力用到了极致。
墨菲定律告诉我们，但凡一件事可能发生，它就必然发生。Netflix背后占到北美1/3的网络流量，用户数量及并发访问非一般技术公司能够想象。一般的想法都是加强测试，尽可能模拟一切可能发生的事故，但现实是很多事故无法在实验室模拟，比如大规模宕机，有些猪一样的队友无法预先想象，比如无处不在的rm -rf * 故事。
普通的公司会选择回避，当事件真正发生时再处理，毕竟在这类小概率事件上花费不成比例的精力，有些得不偿失。而牛X公司如Netflix，追求的是极致的用户体验，以及对自身技术能力的无限追求，更重要的是不能被猪一样的友商拖死。失效一定会发生，并且无法避免；如果你的应用无法容忍系统失效的情况，你是愿意在凌晨 3 点被叫醒，还是希望在办公室中用过 morning coffee 之后呢？
于是乎，Netflix在AWS上建立了一个叫做 Chaos Monkey的系统，这些猴子会在工作日期间随机杀死一些服务，制造混乱，来测试production下的稳定性。Chaos Monkey是一种服务，用于将系统分组，并随机终止属于某个分组中的系统中的一部分；Chaos Monkey运行在一定的受控时间段和时间间隔内（不会无故运行在周末和假日中，并且仅在上班时间内运行）；在大多数情况下，我们的应用设计要保证当某个peer 下线时仍能继续工作，但是在那些特殊的场景下，我们需要确保有人在值守，以便解决问题，并从问题中进行经验学习；基于这个想法，Chaos Monkey 仅会在工作时间内被使用，以保证工程师能发现警告信息，并作出适当的回应；每当这些猴子开始骚扰，一开始，相关的工程师们不得不放下手头的工作，手忙脚乱地寻求应对之策。随着系统的不断完善，猴子们的攻击能力和攻击范围也在不断提升，反而让整个Netflix的服务稳定性、自愈能力以及抗击打能力不断上升。
Netflix整个的IT都架构于AWS之上，Chaos Monkey是用来测试 AWS 的弹性和恢复能力，Chaos Monkey 通过关停一个或多个虚拟机来模拟 service 实例的失效。
如今Chaos Monkey 已经升级为 Simian Army，从可用性、一致性、安全性、健康性等各方面对系统进行各种扰乱，想象一下，一群Monkey，小到蹦蹦跳跳的猴子，大到猩猩、金刚，在你的机房不知道会搞出什么麻烦，而同时又要求你的系统防御、自愈以及运维能力能够抵御这全方位的极限攻击。长时间暴露在这样高强度的压力之下（普通的压测在猴子军团面前简直弱爆了），系统和团队的能力将得到怎样的长足进步。
Simian Army中的各位成员：
-Chaos Monkey，可以随机关闭生产环境中的实例，确保网站系统能够经受故障的考验，同时不会影响客户的正常使用。
-Latency Monkey，在RESTful服务的调用中引入人为的延时来模拟服务降级，测量上游服务是否会做出恰当响应。通过引入长时间延时，还可以模拟节点甚至整个服务不可用。
-Conformity Monkey，查找不符合最佳实践的实例，并将其关闭。例如，如果某个实例不在自动伸缩组里，那么就该将其关闭，让服务所有者能重新让其正常启动。
-Doctor Monkey，查找不健康实例的工具，除了运行在每个实例上的健康检查，还会监控外部健康信号，一旦发现不健康实例就会将其移出服务组。
-Janitor Monkey，查找不再需要的资源，将其回收，这能在一定程度上降低云资源的浪费。
-Security Monkey，这是Conformity Monkey的一个扩展，检查系统的安全漏洞，同时也会保证SSL和DRM证书仍然有效。
-10-18 Monkey，进行本地化及国际化的配置检查，确保不同地区、使用不同语言和字符集的用户能正常使用Netflix。
-Chaos Gorilla，Chaos Monkey的升级版，可以模拟整个Amazon Availability Zone故障，以此验证在不影响用户，且无需人工干预的情况下，能够自动进行可用区的重新平衡。
除了Simian Army，Netflix同时也是分布式领域开源共享无可辩驳的领先者。摘抄自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)
其中尤以Eureka,Hystrix以及Simian Army最为知名。
Netflix与AWS
Netflix并不是最早的AWS customer，但却绝对是最重要的AWS customer之一。从商业层面，美国超过1/3的traffic经过Netflix，其中绝大部分还要经过AWS，这还仅仅是网络，加上支撑所需的计算、存储能力，以及之上的大数据和人工智能分析，说Netflix是AWS最重要的客户之一绝不夸张。加之Netflix在开源社区的影响力，以及Netflix只使用AWS服务，每次AWS re:invent大会，Netflix都会成当之无愧的座上宾，基本每个大部门都会有人上台演讲。以最近的2015年AWS re:invent大会为例，Netflix有多达8位Presenter上台演讲。笔者今年参加过一次AWS re:invent，一次AWSome Day，但凡谈到客户，Netflix一定都是高亮的。
Netflix与AWS可谓是相互成就，可以说，没有AWS就没有今天的Netflix；而没有Netflix，也就没有AWS的今天。现在的Netflix和当年比已经成长了太多。从2007年12月到2015年12月，在这8年里用户时长指数级井喷，增长多达1000倍。这期间也恰好是AWS快速发展的8年。
说起Netflix migrate到AWS这件事还要追溯到2008年8月，发生了一件事情，Netflix的database被corrupted，导致长达三天的时间，没有任何用户可以接收到来自Netflix的租赁DVD。我们都知道，对于一个互联网公司，时间就是金钱，即使是2008年主要还靠DVD为生的Netflix。Netflix的engineering team痛定思痛，在想：怎么样才能建立起完美可靠的架构？而防止此类事故不再发生？他们做了一个后来看起来无比正确的决定：架构外包。作为一个大公司，作为一个心高气傲的Engineering团队，在当时没有继续选择搭建自主的infrastructure，而是退而选择了AWS，这点不仅需要勇气，也需要智慧。（这恐怕也会是未来趋势，在主机时代已经有公司将IT服务外包，而当今的云计算时代，弹性、按需、快速等都将使云计算成为传统IT的杀手）
2006年AWS才开放了第一个服务S3，2008年的AWS可以说是刚刚起步，在把Scalability的任务交给AWS的同时，Netflix需要很多tools去保证网站的availability，防止failover等等。以及专门为AWS service实现的优化和管理工具。正因为如此，很多Netflix OSS才应运而生。为了防止manual deployment 引起的human error，Netflix设计了这个AWS auto-deployment tool。现在该项目已经在github上拥有超过2100个stars。直到2014年，AWS才跟进推出了类似的tool：AWS CodeDeploy。
Netflix使用AWS总结的经验：
-Dorothy, you’re not in Kansas anymore.
-Co-tenancy is hard.
-The best way to avoid failure is to fail constantly.
-Learn with real scale, not toy models.
-Commit yourself.
大意如下：
-在自己的数据中心好用的东西，到了云上不一定好用（软件设计/容量设计/网络延迟等）；
-云设计的基础就是资源共享，面对的是多租户；而这会导致各个层面上的吞吐量变化；
-我们常常将位于 AWS 上的 Netflix 软件架构戏称为“兰博架构”；因为我们要求每一个系统都能做到，即使自身依赖的全部系统全军覆没，仍能提供服务；
-以真实的网络环境数据进行实际测试；
结语：反脆弱
杀不死你的让你更坚强，反脆弱理论告诉我们，拥抱混乱、波动及风险反而让你从脆弱中收益，这比一开始就坚强更好，越稳定的越脆弱。反之，应当承认脆弱，不断主动试错，不断的接触小伤害，小伤害杀不死你的，而人体的自我补偿机制会让你抵抗力更强。Chaos Monkey 的原则：避免大多数失效的主要方式就是经常失效。思考最频繁发生的且痛苦的是什么？坚持经常做，一步步自动化，减少人工重复劳动。骨折过的地方再长好，会比以前更结实。同样的道理，从失败中吸取教训，从错误中学习，成长型思维。
给我们带来最大利益的，并不是那些试图帮助我们的人，而是那些曾努力伤害我们，但最终未能如愿的人。
同样的，给我们的系统带来最大收益的，恰好是这帮混乱、暴力、全心全意攻击我们系统的，可爱的猴子军团。
参考：
https://www.zhihu.com/question/19552101/answer/114867581 Netflix 是怎样的一家公司？
https://zhuanlan.zhihu.com/p/19681894 Netflix和它的混世猴子
https://my.oschina.net/moooofly/blog/828545 Netflix 和 Chaos Monkey