蚂蚁构建服务演进史

简介： 自动化构建和CI/CD往往是相辅相成的，可以理解为，自动化构建是温饱问题，解决了温饱就会有更多的提高生产力的诉求，也就是对应的CI平台，CI/CD本篇文章不做扩展。

作者 | 琉克
来源 | 阿里技术公众号

一构建平台的由来

只要是软件开发就离不开构建，构建无处不在，构建是源代码和用户呈现之间的桥梁。

这里要澄清一点，构建 != 编译，构建的本质是把源代码翻译成运行环境能识别的产物（源代码可能是Java代码，也可能是配置文件、资源文件等，运行环境可能是物理机，也可能是虚拟机，也可能是mobile phone）。

所以工程师每天每时每刻都在构建，不构建就没法验证。随着规划的扩大，把构建自动化掉，提供一个“打包平台”也就是一个自然而然的事情，毕竟提高生产力是第一诉求吗，这也就是构建平台最开始的由来，把每天干的事情自动化掉，搬上平台。

自动化构建和CI/CD往往是相辅相成的，可以理解为，自动化构建是温饱问题，解决了温饱就会有更多的提高生产力的诉求，也就是对应的CI平台，CI/CD本篇文章不做扩展。

二理解构建

构建 != 编译，构建本身是一个很复杂的编排过程。举两个例子：

1 Android APK的构建过程

上图中绿色部分为工具，浅蓝色部门为源代码+中间产物。可以看到是一系列的工具+输入的编排，最终生成运行环境可识别的产物。上诉构建过程生成的产物(APK)可被Android手机识别并运行。

2 Java Jar包的构建过程

可以看到jar包的构建过程和上面APK的差异非常大，相对来说也是更简单。

3 构建工具

上面两个case可以看出来，构建本身很复杂，要最终构建出一个可以运行的产物需要做很多事情，我们完全可以手动javac copy jar等等一系列操作实现构建过程。但当工程越来越大，文件越来越多，这个事情就不是那么地令人开心了。这些命令往往都是很机械的操作。所以我们可以把这些机械的操作交给机器去做。对应的构建工具也应运而生，毕竟提高生产力是第一诉求。

拿Java举例：

Ant

上面的示例中，Ant定义了五个任务：init、compile、build、test和clean。

每个任务做什么都定义清楚了。在打包之前要先编译，所以通过depends来指定依赖的路径。

如果在命令行里执行ant build，那就会先执行compile，而compile又依赖于init，所以就会先执行init。

执行命令：

ant test

通过命令就可以执行编程，打包，测试。为开发者带来了很大的便利，提供了工作效率。

但是Ant有一个很致命的缺陷，那就是没办法管理依赖。

我们一个工程，要使用很多第三方工具，不同的工具，不同的版本。

每次打包都要自己手动去把正确的版本拷到lib下面去，不用说，这个工作既枯燥还特别容易出错。为了解决这个问题，Maven如约而至。

Maven

Ant仅是一个构建工具，它并未对项目的中的工程依赖以及项目本身进行管理，并且Ant作为构建工具未能消除软件构建的重复性，因为不同的项目需要编写对应的Ant任务。
Maven作为后来者，继承了Ant的项目构建功能，并且提供了依赖关系，插件机制，项目管理的功能，因此它是一个项目管理和综合工具，其核心的依赖管理，项目信息管理，中央仓库，Maven的核心理念是约定大于配置。每一种类型都有固定的构建生命周期。

和ant的build.xml相对的，maven项目的核心是pom.xml，java开发同学肯定都很熟。

Gradle

Gradle已经抛弃了Ant、Maven中Xml配置的形式，取而代之的是Gradle采用了领域特定语言Groovy的配置。Gradle继承了Maven中仓库，坐标，依赖这些核心概念。文件的布局也和Maven相同。但同时，又继承了Ant中target的概念，我们又可以重新定义自己的任务(在Gradle中叫做task)。

相比maven会更简洁，比如在maven中要引入依赖：

转换成gradle脚本：

dependencies {compile('org.springframework:spring-core:2.5.6')compile('org.springframework:spring-beans:2.5.6')compile('org.springframework:spring-context:2.5.6')compile('com.google.code.kaptcha:kaptcha:2.3:jdk15')testCompile('junit:junit:4.7')
}

配置从原来的28行缩减至7行！效果惊人。

同时gradle在构建性能上也碾压maven，gradle在maven的基础上额外增加了增量构建、build cache、daemon等特性，大大提升构建时间。

类似的构建工具其实还有很多，基本属于百花齐放，比如facebook的BUCK，Google的bazel等，国内也有一些厂商自己的构建工具，比如腾讯的blade。不同的工具都会有自己的优势和劣势。

三构建平台的演进

1 原始时代

其实最开始的诉求非常简单，构建工具基本都是现成的，人少，功能简单。所有构建基本都是手动。

移动端：支付宝一个应用，一个仓库，谁发版直接在个人电脑上拉取最新代码执行编译，发布app store。
服务端：一台物理机，一套构建脚本，谁要发布，直接登录，输入仓库/分支信息，执行构建，然后发版。

2 自动化

显然，随着人员的增长，规模的扩大，原始时代根本无法支撑进一步发展，主要的矛盾：

多人协作困难。
多人抢占。
个人机器构建的不稳定性，成功率极低。

这一阶段最大的诉求：项目管理/多人协作/自动化构建。应运而生两个平台：CP SCM。

CP主要负责项目管理，多人协作。
SCM主要负责代码管理，构建任务调度，构建机器管理运维（SCM慢慢演变成一个大杂烩，jar包上传管理，客户端签名，各种）。

大概长下面这个样子：

初级阶段

这里构建比较大的难点还是在机器的管理和调度，其实做了很多事情：

机器管理，增删机器。
机器保活，可用性监控。
机器环境一致性的保障。
机器构建负载均衡。
构建脚本的统一升级维护。

上面框架运行了一段时间后还是发生了很多问题，构建成功率越来越低，主要有几个问题：

ssh通道是有连接数限制的，抽风性的ssh连接异常。
负载均衡控制困难，机器之间负载经常不一致，构建时快时慢。
机器配置管理难度大。

进阶阶段

其实这一块，开源有非常成熟的方案 -- jenkins。我们干的很多的事情jenkins都已经帮我们干了。也能很好的解决我们遇到的痛点：

C/S架构，无ssh通道限制。
自动控制负载均衡，机器监控。
灵活的构建和任务配置。
强大的开放能力和丰富的API。

改造完大概长这样：

黑科技（填坑）

这里要抛出一个新的概念「制品库」。

Java开发中，大家对maven、gradle这些工具肯定不能再熟悉了。前面讲构建工具的时候讲过，Java构建工具有几代演进：Ant，Maven，Gradle。Maven之前的上古工具，用的人应该非常少了。

在Maven之前，是不存在版本管理，依赖管理这种概念的，所有的东西都在你的仓库。你的工程里面用到了gson，spring，log等开源框架和功能时，是需要去手动下载对应的jar包，然后放在代码库中。如果需要更新，需要不停去项目对应官网，下载最新发布的包。

Maven之后的工具，提供了强大的依赖管理功能，只要在pom.xml写上你要使用的依赖，maven会自动下载依赖，修改和升级只需要修改GAV坐标（groupid，artifactid，version），依赖的所有jar包都存储在「制品库」中。

此时的构建大概长这个样子：

物理机缓存使用overlay文件系统，每次构建缓存独立，防止公共缓存被刷入。
监控制品库的覆盖记录，生产delete task，快速通知物理机删除公共缓存。
记录overlay文件系统upper层的增加记录，记录add task，定时刷入物理机公共缓存。

存在的问题

环境一致性保证，环境升级。
复杂的脚本逻辑。

理解下这两个问题，随着业务的迅速发展，接入的系统越来越多，APP越来越多，构建的环境越来越“胖”。

比如：App除了支付宝，还有口碑，财富，香港钱包等，各个产品有自己的构建逻辑，也有自己的工具，比如支付宝用gradle4，口碑用gradle2。

其它的技术栈也越来越多，Java，GO，C++等，需要不同的JDK版本，GO环境等。

所有环境都塞进一台物理机，这里存在两个比较严重的问题：

频繁增加新的工具，如何确保不影响既有的环境和构建。
环境不可复制，新的构建机器，初始化困难，很难保证和旧有环境的一致性。

历史发生过的问题

新加的物理机编码异常，导致构建产物异常，运行时出现乱码。
升级IOT的AndroidSDK，影响支付宝，部分手机计步功能失效。
环境升级操作不当导致的各种构建失败。

3 容器化

构建是一件非常值得敬畏的事情，需要保证构建的绝对正确，一旦构建异常了，后果不堪设想。

最好的保证构建正确性的方式，就是什么都不要改，不要加机器，不要改环境，什么都不要动。

但是现实是总是有越来越多新的场景冒出了，今天要支持这个，明天要支持那个，这里是一个比较矛盾的点。

在容器技术出来之前，大家都是用的是虚拟机技术，我们可以模拟出来一台乃至多台电脑，但是太笨重了，也不好维护。2013年Docker开源，它轻量，高性能(秒级启动)，隔离性，让他迅速成为焦点。

构建也尝试探索，docker技术非常适合在构建时使用，可以很好的解决上面的问题。改造后长下面这样：

之后升级环境再也不是痛，各种场景容器隔离，升级互不影响，物理机秒级扩容。运维人员基本只要维护Dockerfile就行。

当然也会带来新的问题：

Mac构建没法虚拟化，仍然是传统物理机构建 + Ansible运维。
容器化之后缓存失效，构建时间暴增。
镜像本身的管理，物理机磁盘空间管理。

4 镜像化

前面讲的都是软件的构建过程和构建服务，这里其实还存在一个问题，除了构建的一致性，软件的运行环境一致性也至关重要。经常会发生，一个软件，在我的电脑可以，在别人的环境却跑不起来。

随着容器技术越来越火，serverless技术和应用微服务架构的演进。容器正迅速成为企业应用打包和部署的基本单位，可以真正的实现build once & run everywhere。
在蚂蚁的历史中也是如此，越来越多的场景开始镜像化部署，所以镜像构建本身也变得越来越重要，镜像构建的效率，稳定性，安全性等至关重要。

镜像构建也经过两次演进：

docker build

docker build是比较简单的，我们在之前的架构之上新增了一种镜像构建类型，主要存在下面几个弊端。

（1）对于multi-stage 的Dockerfile 构建无法实现并行编译

（2）docker build 缓存利用效率低，改变Dockerfile 前面的一层，后面所有的层都需
要重新构建而无法使用缓存，这要求用户不得不认真控制写好自己的Dockerfile以确保镜像缓存复用。

buildkit + K8S

buildkit是从docker build分离出来的单独项目，目前buildkit已经集成到Docker 18.06之后的版本之中，核心特性：

可扩展的前端格式：buildkit使用前后端分离的架构设计，除了Dockerfile也支持其他类型的前端格式。
并行构建执行：对于multistage类型Dockerfile， buildkit可以实现不同stage之间的并行执行。
支持构建缓存的多种处理方式：buildkit处理本地缓存snapshot，同时还提供了将构建缓存导入/导出到本地或者远程registry。
多种输出格式：buildkit支持导出成tar包或者oci格式的镜像格式。
引入Dockerfile新语法RUN --mount支持构建时挂载。

这里不进行扩展，有兴趣的同学可以查看buildkit的官方项目（蚂蚁目前每天运行着上万数量的高可用镜像构建服务）。

5 拥抱云原生

随着蚂蚁越来越多的业务serverless化，云原生慢慢成为了趋势。伴随着的是对K8s之上的构建和资源的使用诉求。

而K8s本身使用门槛又极高，同时也缺乏灵活的任务编排能力。相应的构建团队也开始调研和投入云原生的构建和调度解决方案。

背景

2019年3月份持续交付基金会（CDF）正式成立，它致力于使企业在多个 CI / CD 平台上更轻松地构建和复用 DevOps 管道。

第一批进入CDF项目的主要有四个：

Tekton 作为谷歌捐赠的 CDF 重要项目，是一组用于构建 CI/CD 系统的共享开源组件，与 Kubernetes 紧密相连，其重要性不言而喻。

并且jenkinsX底层也选择了tekton作为执行引擎。

Jenkins X is committing fully to Tekton as its pipeline execution engine. We are convinced that this is the right choice for Jenkins X, as a cloud-native CI/CD platform on Kubernetes, and for our users.

内部落地

综合权衡，采用tekton是一个比较合理的解决方案（站在巨人的肩膀，不重复造轮子）。

经过一段时间的探索和演进，逐步落地了云原生的资源调度和构建解决方案——ironman。服务内部每天几万的构建、代码扫描、CI任务等场景。

详细细节可以参考下面几篇文章：

tektoncd github
持续交付基金会

下一步计划

tekton相比K8s，复杂度大大降低，并且提供了足够灵活的编排和调度能力，但是仍然有缺陷：

概念复杂，偏厚重，整体调度相比直接使用POD会更慢
使用上仍然有一些成本，对一线用户的接入使用不友好

目前正在投入POD预热等极简模式，解决上诉痛点。当然还有很多未解的难题，就不一一赘述。

6 构建中台

经历了自动化，容器化，镜像化等场景，发现用户的需求实在是千奇百怪，越来越多（只能说蚂蚁的业务发展太快）。

我们有越来越多的业务场景（IOT，小程序，大数据，...），构建的需求差异性也非常大。有Mac构建，Linux构建，Windows构建。应付还是有点吃力。尤其是在Mac和Windows两种无法虚拟化的场景，大量的机器分组，有点维护不动。现状大概长这样：

由于构建逻辑基本都是在构建团队维护，SCM和构建脚本中的代码逻辑也处于一个非常混乱的状态，基本就是大量的if else，伪代码大概长这样：

if (framework == "sofa") {buildCmd = "mvn clean package"if (app == "special") {buildCmd = "mvn clean package -Ptest=true"}
} else if (framework == "android") {buildCmd = "gradle clean assembleRelease"
} else if (framework == "jar") {buildCmd = "mvn clean install && mvn deploy"
} else if (xxx) {buildCmd = "xxx"
}

这个阶段在面对一些个性化的构建需求其实有点力不从心，需求千奇百怪：“我要加个额外的参数”，“我要更多的CPU”，“我需要用Mac来跑构建”，“我需要用某某软件的某某版本”。

当前阶段是没法继续支撑蚂蚁未来的业务发展的，在加上当前底下已经有非常多的资源（linux，windows，Mac，K8S）管理困难。

所以未来的构建平台，至少是可以做到下面两点：

构建可描述，逻辑回归业务方。
构建资源(机器)动态插拔，任意切换。

构建可描述

所有的构建逻辑是透明的，可配置化，可代码化，可描述内容包括：

构建机器类型
构建所需资源大小
构建所需环境软件
构建执行逻辑
构建结果产物

构建资源动态插拔，任意切换

这里最关键的点是去掉大量分组维护带来的难点，让资源之间可以共用，互相流动。同时可以实现资源之间的任意切换，降级，保障构建服务的高可用（比如K8s资源降低到物理机构建）。

新的框架大概长下面这样：

业务使用方只要定义好buildspec.yaml文件，就可以实现任何个性化的构建需求。
底下执行构建的资源可以是K8S，可以是jenkins，可以是物理机，whatever，构建资源描述好自己支持的类型入场即可。

buildspec.yaml大概长下面这样：

name: android-aar-build
params:- name: productLinedefault: alipay- name: sprintIddefault: ${SPRINT_ID}
resources:- name: code-repotype: giturl: https://code.alipay.com/xxxxxref: master
environment:type: LINUX_CONTAINERimage: reg.docker.alibaba-inc.com/alipay/aarbuild:latest
buildTasks:- name: Download configimage: python:3commands:- python --version- name: Install Dependencyimage: ruby:2.6commands:- echo "-------2 in ruby:2.6"ruby -v
artifacts:- name: pod-for-alipaytype: iot-signpath: xxxx.zip