6 月 11 日，Netflix 出现了长达一个多小时的服务中断。当欧美观众结束了一天忙碌的工作回到家中想舒舒服服煲个剧，结果发现一个残酷的事实，在 App 和网站上只显示一条错误消息：Netflix error: this title is not available to watch instantly （Netflix 错误：此标题当前不可观看）。
作为美国流媒体巨头，世界上最大的收费视频网站，Netflix 出了不少高质量的影视剧，吸引的观众数量呈指数级增长。但迄今为止，Netflix 都能 hold 住场面，其服务器还没有遭受什么重大中断。也就是说，6 月 11 日的服务中断是 Netflix 首次遭受全球大规模宕机事故。
没有剧看的人生还有什么意义
Netflix 全球付费订阅用户过亿，这次大规模宕机也让网友们体内的段子手属性得以爆发。很多人发推文说自己“无所事事”，于是大家纷纷在推特上发起了表情包：
场景切换到 Netflix 总部：
chang
看不了 Netflix 的我：
Netflix: 我出了点问题。
我：怎么可能
Netflix: 上推特看看
推特上搜 #netflixdown 之后的我：
此时的我：
幸运的是，这次宕机持续的时间没有太长，也就是一小时零三分钟，或者大约三集神烦警探的时间，最后问题终于得以解决，Netflix 官方技术推特发布了推文：
“刚才报道的问题现在已经得到解决，感谢您的耐心，一如既往地祝您观剧愉快！”
至于服务中断的原因，目前还尚未得知。
Netflix：权利的游戏靠黑科技打赢
Netflix 能拥有如此庞大的用户群并保证用户在观看视频的过程中不卡顿，得益于背后很好的技术和文化支撑。他们信奉“自由与责任”的企业文化，鼓励工程师发挥自己的爱好与特长；特别开放，很多内部系统都开源了；所有业务都运行在云上，随之而来，有很多自己的工具，特色的运维文化。
从 2009 年开始，Netflix 便逐渐把 IT 系统迁移到 AWS 云平台，进行大规模生产级微服务架构实践，并开源了整个微服务技术栈。来看一看 Netflix 有哪些知名开源工具和技术：
Genie：专为 Hadoop 生态系统定制的一组 REST-ful 服务集合，用于管理作业和资源，它有两个关键的服务：ExecutionService 和 Configuration Serice。前者提供了 REST-fulAPI，用于提交和管理 Hadoop、Hive 以及 Pig 作业；后者是一个 Hadoop 资源的有效储存库，处理元数据的连接以及运行资源上的作业。
Inviso：对 Hadoop 作业和集群的性能进行详细而深入的剖析。
Lipstick：以一种清晰且可视化的方式展示 Pig 作业的工作流。
Eureka：Netflix 的云平台服务发现技术。
Zuul： Netflix 开源的网关组件，相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。Zuul 可以适当的对多个 Amazon Auto Scaling Groups 进行路由请求，提供云部署周边的动态路由、监控、安全和弹性扩展等服务。
Hystrix：针对分布式系统的延迟和容错库，提供单一服务调用所不具备的可靠性，提供运行时的延迟隔离和容错。
Chaos Monkey：用于将系统分组，并随机终止属于某个分组中的系统中的一部分，帮助工程师识别网络弱点。
Security Monkey：用于检测和保护大规模的 AWS 环境。
在不断的实践中，Netflix 已经成为硅谷和云计算生态系统中一家举足轻重的技术公司。
事故原因讨论
对于此次服务中断的原因还尚未得知，网友的猜测包括：是 AWS 的锅，是复杂微服务化的问题，是 Chaos Monkey 捣乱，也有人在等着看 case。
有人说 Netflix 自 2007 年推出服务到现在才首次出现这样全球大规模的服务中断已经很不错了。对此，有网友回复：
假设他们的内部项目与 OSS 类似，你可以自己尝试一下再看你是否还会得出同样的观点。评估一个架构的方法不仅仅只有通过服务中断的次数判断。Netflix 已经构建了一个很棒的系统，用于扰乱服务器来查找故障点。他们还有一堆清理工具可以解决一致性错误。过去我痴迷他们的架构，从中汲取了这些东西。
然后我开始尝试以这种方式构建一些项目，才意识到这是一个可怕的噩梦。通过一个全局立即一致的数据存储区，你可以将所有这些问题都推送回数据库，并且你的代码库会变得更小。
当你使用不同的数据存储区在服务间进行 RPC 时，在这种复杂度下故障就会爆发，因为你必须自己处理分布式事务。每一次调用都需要能够跨所有服务展开。
如果你有一个调用能拓展出 10 个其他的服务调用，你需要能够以任意顺序将其中任何一个调用展开。这种情况下很快就会有问题爆发。
