Netflix如何做构建和部署？

在代码部署到云端之前，Netflix 是如何做构建的？本篇文章将描述为 Netflix 服务8000万用户的微服务，是用什么工具和技术构建出来的。

上图描述了在 Netflix 的全球持续发布平台 Spinnaker 做发布之前，仍然有几个步骤需要执行，这些步骤就是将源码编译、构建、测试打包的过程，这些过程包括:

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

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

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

·   构建被 “baked” 到 Amazon Machine Images（AMI）。

·   Spinnaker pipelines 用来部署和升级代码变更。

文化，云计算，微服务

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

Netflix 的文化鼓励员工使用任何他们认为最好的工具去完成任务。在 Netflix 内部功能风靡的工具，一定是很核心的，非常具有价值，为大部分程序员大幅提升性能的工具。团队有选择技术方案的自由，同时也承担维护这些新方案的责任。

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

构建

Netflix 创建了 Nebula, 一个精选了多个插件的 Gradle 构建系统, 目的是为了全公司的 Java 服务提供统一的构建工具. Gradle 对应 Java 应用的构建，测试和打包支持的非常全面。为什么选择 Gradle？ 因为使用 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 的官网查看 the Nebula website。

集成

当代码被 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 从代码提交，到部署到跨区域的云服务器的时间只需要16分钟。

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

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

另外一个挑战，是 Bake 时间过长。在不久之前，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平台

公司成立于2008年，在美国、以色列、法国、西班牙，以及中国北京市拥有超过200名员工。JFrog 拥有4000多个付费客户，其中知名公司包括如腾讯、谷歌、思科、Netflix、亚马逊、苹果等。关注 JFrog，感受原汁原叶的硅谷技术！我们不仅仅提供最优秀的产品，也提供最优秀的持续交付平台的解决方案，详情请洽[email protected]