Netflix如何做构建和部署？

在代码部署到云端之前，Netflix 是如何做构建的？本篇文章将描述Netflix 使用哪些工具与技术构建出了为全球7500万用户提供的影片和电视节目的服务？

下图描述了Netflix基于 Spinnaker的的全球持续交付流水线。

在交给Spinnaker准备执行部署之前，有以下几个几个步骤，就是要将源码编译、构建和测试打包，即：

·   代码在本地用 Nebula 进行构建和测试。

·   代码都会被提交到统一的中央 Git 代码库。

·   使用 Jenkins 任务执行 Nebula 构建，测试并且执行打包应用。

·   将打出来的包烧制成AMI镜像（Amazon Machine Images）。

·   之后的工作，就交由Spinnaker来完成（对这些烧制好的AMI镜像进行分发、部署和发布）。

文化，云计算，微服务

在进入 Netflix 如果构建代码的细节之前, 先来看看 Netflix 最重要的关键元素：文化，云计算，微服务。

Netflix 的文化鼓励员工使用任何他们认为最好的工具去完成任务。根据Netflix的内部经验，那些非常受欢迎的工具，一定是提供竞争优势，大大增加价值，能为程序员提升生产效能的工具。Netflix各团队都有自由选择技术方案或工具，但也要承担这些新方案的维护责任。而Netflix专职团队开发的工具被认为是为提高工程效率铺平道路的。今天下面提到的一些工具就属于这类工具范畴。

另外，从2008年开始，Netflix 开始将流媒体业务迁移到 AWS，也开始将“巨石应用”迁移到基于 Java 的微服务。在微服务架构中，服务之间是松耦合关系，任何团队可以按需发布代码变更。

构建

Netflix 创建了 Nebula, 它是一个精选了多个插件的 Gradle 构建系统, 目的是为全公司的 Java 服务提供统一的构建工具。因为Gradle 对 Java 应用的构建，测试和打包等方而都有非常好的支持。同时，使用 Gradle编写插件非常容易，也大大减少每个项目的构建文件个数。Nebula 继承了 Gradle 健壮的自动化构建系统，并且继承了一系列开源工具，支持依赖管理，发布管理，打包等等。

一个简单的 Java 项目 build.gradle 文件：

上面的 ‘build.gradle’ Netflix 的一个典型的 Java 构建项目。这个构建文件声明了 Java 的依赖和4个应用的 Gradle 插件。 其中，‘nebula’ 插件是内部用于集成内部基础服务的Gradle 插件。‘Nebula.dependency-lock’ 插件能够为项目生成一个.lock 文件，记录所有依赖的图谱，用于版本的重建。 ‘Netflix.ospackage-tomcat’ 插件接下来会讲到。

通过 Nebula 能够实现可重用的构建能力，减少了项目框架构建文件的数量。 Nebula 已经在 Github 开源，详情可以去 Nebula 的官网查看Nebula网站。

集成

当代码被 Nebula 本地构建，测试完成后，可以将它做持续集成和部署。

第一步是将它提交到 Git 仓库。

一旦代码提交，一个 Jenkins 被触发。Netflix 使用一个巨大的Jenkins Master 调度 AWS 上的25个 Jenkins Master 节点。

一个 Jenkins 会配置 Neluba 的构建，测试和打包。如果目标包是一个库，Nebula 会打包成 .jar 到 Artifactory 仓库。如果目标包是一个应用， Nebula ospackage plugin 会被执行。使用 Nebula ospackage 插件，一个应用会被部署到一个 Debian 或者 RPM 包，这些包的内容会被 Gradle 的 DSL 定义。Nebula 会发布这些镜像文件到包仓库管理平台，准备下一个环节 “baking”。

Bake

Netflix 的部署策略是集中式，不可变基础设施为主导的模式。动态修改线上服务器的内容是严令禁止的，目的是为了每次发布是完成从代码提交开始。每次部署始于一个新的亚马逊机器镜像 Amazon Machine Image。从代码到生成 AMI就叫做 “the Bakery”.

Bakery 提供了全局的创建 AMIs 的接口。 Bakery API 服务定时的去执行创建镜像的任务，任务使用 Aminator 去创建镜像。用户只需要声明需要安装的依赖包，基础镜像，以及 Netflix 的上线基础服务即可。

当 Jenkins 任务成功了，它会触发一个 Spinnaker pipeline. Spinnaker 流水线可以被 Jenkins 任务触发，或者被一个 git commit 触发。Spinnaker 将会读取 Nebula 构建处理的系统包，并且调用 Bakery API 去发起一次 bake。

部署

一旦 bake 完成，Spinnaker 将烘焙好的 AMI 成百上千台服务器里。同样的  AMI 可以被不同环境重复使用，Spinnaker 暴露一个运行时的 context，能够进行运行时的环境变量注入。一个成功的 bake 会触发下一个阶段的 Spinnaker 流水线，一次部署到测试环境。从这里，团队会执行自动化的集成测试。在部署阶段，团队开始自定义自己的部署目标。可以使用 Spinnaker 管理多 Region 的部署，金丝雀发布，蓝绿部署等等。 Spinnaker pipelines 为团队提供了足够强大的能力去部署代码。

未来展望

总体来说，这些工具为Netflix带来了高效和自动化。例如，Netflix 从代码提交，到部署到跨区域的云服务器的时间只需要16分钟。

Netflix 一直在思考如何改进开发者的用户体验，如何做到更好，更快，更容易的交付软件。

Netflix 一直受到如何管理包依赖问题的困扰。Nebula 提供了更方便的解析 Java 依赖的能力。例如 Nebula dependency-lock plugin 能够为应用程序生成一个.lock 文件，将所有依赖的文件版本化起来。 Nebula resolution rules plugin 提供跨团队的依赖解析规则，在所有 Nebula 的构建中生效。这些插件让依赖管理变得更加容易。

另外一个挑战，是 烧制镜像时间过长。从前，在16分钟内从代码提交到部署还是一个梦想，但随着各个系统的时间都在缩短，这个时间变得越来越短。

随着Netflix 的发展，支持非 JVM 语言（例如 JavaScript/Node.js, Python, Ruby and Go）的构建，测试工具链的需求越来越强烈。目前推荐非 JVM 得语言使用 Nebula ospackage 插件生成 Debian 包去做 baking，将构建和测试的阶段的工作交给这些团队，他们使用自己熟悉的工具来做。

原文地址：https://medium.com/netflix-techblog/how-we-build-code-at-netflix-c5d9bd727f15

转载自公众号：“JFrog杰蛙DevOps”