著名的电影流媒体网站 Netflix 每天都会进行上百遍部署，它们没有使用 Chef 或 Puppet ，没有一个质量保证部门，也没有发布工程师。为了实现自己的目标，Netflix 构建了一个先进的内部 PaaS（平台即服务）平台，所有的团队都能够通过这个平台部署自己的基础设施部分，同时部署也没有时间和次数上的限制。在 QCon New York 2013 期间， Jeremy Edberg 介绍了这个 Netflix 为了满足快速迭代的需要而基于 Amazon AWS 构建的基础设施。
Netflix 在实现 API 的时候使用了面向服务的架构，该架构会处理网站的大部分请求（每天有 20 亿次请求）。在幕后，API 被分离成了很多服务，每一个服务都由一个团队进行管理，这使得团队能够相对独立地进行工作，也能够独立决定何时以何种频率部署新软件。
Netflix 在 DevOps 方面的投入很大。开发者构建、部署并维护他们自己的服务器集群，同时还需要对错误负责。如果发生了错误，便需要组织一个会议调查问题出现的根本原因，讨论防止此类问题将来继续发生的方案——类似于 5 个为什么。
Netflix 中的部署完全是自动化的。如果一个服务需要部署，那么开发者首先会将代码推到一个源代码仓库。之后 Jenkins 会捕获到这个代码推动事件并执行构建生成一个应用程序包。再往后便会基于基础镜像（包含一个 Linux 发布版本）和所有 Netflix 服务器上运行的软件（包括 JVM 和 Tomcat，将来可能会允许团队做进一步的自定义）产生一个新的 VM 镜像（AMI）。在上面这些基础内容安装完成之后会安装应用程序包。由此，一个 AMI 便产生并注册到系统中了。
为了将 VM 镜像部署到它的基础设施中， Netflix 构建了 Asgard 。VM 镜像能够通过 Asgard Web 接口实例化并创建新的 EC2 集群。每一个集群都会包含至少 3 个 EC2 实例用于冗余，这些实例会散步到多个可用区域中。部署新版本的时候，在新版本被实例化运行的同时，运行之前版本的集群仍将继续运行。在新版本启动并将自己注册到称为 Eureka 的 Netflix 服务注册表之后，负载均衡器便会进行切换将所有的流量导向到新集群。新集群会被仔细地监控并保持运行一整夜。如果所有的事情都运行良好，旧集群便会被销毁。如果有任何问题发生，那么负载均衡器便会切换回旧集群。
在 Netflix 基础设施中会不断地产生错误。软件需要能够处理硬件故障、网络连接故障以及其他类型的错误。虽然错误并不会自然而然地产生，但是使用 Simian Army 还是极有可能诱发错误。Simian Army 中包含了很多（软件）“猴子”能够随机地引入错误。例如，Chaos 猴子会随机地导致服务器崩溃，而 Latency 猴子会随机地引发网络延迟。如果团队认清了错误会时常发生的事实，那么他们就有可能忽略错误并创建一种错误弹性至上的文化。
Netflix 基础设施中的很多部分现在都已经开源了，你可以通过 GitHub 获取。Netflix 的最终目标便是完全发布它的基础设施，让其他的公司能够从中受益。
查看英文原文： How Netflix Deploys Code
暂无签名
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
评论