构建系统是研发效能工具链中的重要一环。在滴滴,开发同学们只需将构建脚本同源到代码库中,远在云端的构建系统就可以随时进行高效稳定的构建打包作业,同时完成多 OS 并行构建打包、服务注册与发现信息扫描、依赖关系收集分析、自动推送产出物管理中心等工作。当需要自定义构建环境时,只需提供一个容器镜像地址即可。如果是使用构建系统预置的数十套环境,更是简单到在构建环境配置文件中改动一行代码就能完成构建环境切换:
做到这一切的背后正是滴滴构建系统从开源方案走向自研系统的发展过程。滴滴初期通过 Jenkins 来帮助开发团队完成构建打包工作,使用规范的构建环境打包,保证产出包的环境和线上环境一致。
Jenkins 作为一款优秀的开源工具,具有如下优点:
简单易用:能够快速创建并运行自己的构建、测试等任务。
功能强大:目前已经存在众多插件,可以通过插件实现很多扩展功能。
社区活跃:版本更新很快,对容器等新技术的支持速度也很快。
然而仅就构建过程来说,我们在实际使用中也发现了以下问题:
稳定性问题: Jenkins 只有一个 Master,存在单点风险,会成为一个 SPOF。Master 一旦发生故障,将导致整个构建系统不可用。
性能问题:Jenkins 采用的轮询调度,没有对任务调度做任何的优化。这使得一些主机比较空闲,而其它主机过于忙碌,无法充分的利用运算资源。另外,当任务被分配到某个从未构建过该任务的主机时,需要重新搭建构建环境,导致构建性能曲线出现抖动。
安全性和便利性难以平衡: 构建失败时往往需要登录到构建机器上进行 Debug。这方面 Jenkins 没有做权限控制,构建主机完全暴露,安全风险较大。另外,每个 Jenkins 任务都可以对系统环境进行修改,导致系统环境经常发生变更,有导致构建环境不一致的风险。
以上问题,对于像滴滴这样量级的公司来说会更加凸显。因此,国内外一些规模较大的互联网公司也都会自研构建系统,以适应公司内部情况,并提升构建效率,比如 Google 的 Bazel、百度的 Build Cloud、腾讯的 Blade 等。
滴滴也有自己的构建系统——“建木”。建木是山海经中记载的一颗神树,传说是沟通天地人神的桥梁。伏羲、黄帝等神仙都是通过建木来往于天上和人间。在滴滴,建木构建系统是持续交付平台的重要组成部分,也是沟通代码系统和部署系统的重要桥梁,目前为滴滴每个月数万次的构建作业提供了稳定高效的服务。
滴滴“建木”的优势
1 稳定
采用主从机制,避免单点故障,能够提供持续稳定的服务。
支持构建主机的动态添加和删除,一键部署构建主机后可马上投入使用,故障主机动态摘除,无需备份构建任务配置。
每次任务构建完后,都会对系统环境做清理并恢复系统变量设置,保证系统环境的一致性。
建木拥有独立运行的监控模块,可有效的监控构建系统的运行健康状态,避免进程出现假死等状态(比如表面进程还运行着,实际已经无法提供服务能力)。
(“建木”系统架构图)
2 高效
调度器轻量的服务例程:将复杂的计算挪至构建主机,避免成为系统瓶颈。同时 Workspace 复用技术以及两级模块 Cache 机制能极大的加速构建环境的搭建。以下是对于不同大小的 Git 库的性能提升的测试数据:
智能调度:对于 Docker 化构建,系统可以智能的将构建任务尽可能分配到已经存在该 Docker 镜像的主机,节省了拉取 Docker 镜像的时间。同时任务结束后会清理 Docker 相关资源,保证系统资源不被不必要的进程消耗尽。而对于 Docker 构建任务,系统会综合考虑曾经构建的 Workspace、主机的 CPU、内存以及磁盘使用情况以及历史的构建成功系数来进行任务的调度。
建木对于 C/C++模块也具有分布式编译的能力:建木采用两套 Dmucs 来避免分布式构建系统的单点故障,同时还会复用原构建主机来提高资源利用率,保证强有力的分布式构建能力。
经过一年来的持续改进,利用以上各种优化手段,我们的建木将构建效率提升了一倍以上,平均构建时间小于一分钟。
3 安全便利
构建系统的客户端简单易用:只需提供 Git 模块地址以及特定的构建脚本即可发起构建任务。
Workspace 隔离机制:构建过程的任务不能访问或者破坏其他任务的 Workspace。并且,系统对 Debug 账号进行权限控制,用户登录后直接来到用户的 Workspace 根目录,无权对其他 Workspace 进行操作。
提供服务化定制:比如在构建过程中无缝透明的融入服务注册与发现扫描以及必要的安全扫描等功能。
开发和打包上线环境统一:建木提供了类似 Google 云构建系统,RD 本地可以发起构建请求到构建系统,以保证本地构建和上线打包环境的高度一致性,并且可受益构建系统的 Cache 机制,来有效的减少构建时间。
除了以上的特质,“建木”系统还有很多优秀功能,比如对容器化构建的支持,以及 Env As Code 机制。
容器化构建
容器化构建功能支持基于用户给定的自定义镜像,建立容器并执行构建任务。容器的创建、构建环境的准备和容器的销毁完全对用户透明,用户需要做的仅是指定构建需要使用的镜像。这种能力在应对一些对构建环境有特殊需求的场景时,能够为用户提供极大的便利性和完全的环境一致性。这对用户而言,真正做到了我的构建我做主。
ENV AS CODE 机制
BuildEnv As Code 功能是 Infrastructure As Code 理念在建木中的体现和实现方式。用户可以用完全代码化的方式编排构建环境。当需要切换构建环境时,唯一需要做的就是改动几行代码。这种方式下,构建环境和代码同源管理,有版本可追溯,在任何场景下都可以保证构建环境的一致性。这对用户而言,做到了构建环境全程可控。
但是,相对于滴滴飞速发展的业务来说,如今的“建木”构建系统还是不够,我们正计划对建木从以下三个方面进行更好的升级和优化。
1
系统自动无缝升级和构建能力弹性伸缩:当构建系统开发新功能或者升级时,系统可无缝升级实现服务不间断,用户对此完全无感知。同时,基于底层的容器平台和虚拟化平台,提供自动弹性伸缩的能力,用于应对各种突发的构建需求。
2
资源智能预分配:可针对频率较高和高并发的任务,做资源的智能预分配。比如一些任务需要使用 Docker 来运行任务,但是启用前提是拉取 Docker 镜像,而这需要较长的拉取时间。此时建木可以根据任务的频率和并发度等特征,进行数据分析和机器学习,事先将 Docker 镜像拉取到主机,并将任务主动调度到这些主机上。这样可以大幅缩短这类任务的运行时间,提高系统性能。
3
持续提升稳定性和构建性能:通过加强服务监控能力,优化系统调度,进一步优化服务降级等策略来保障核心功能,以此进一步提升稳定性。同时进一步排查构建过程中的性能短板,不断优化打磨构建系统,使构建效率再提升 30%以上。
建设一个稳定、高效、智能的构建平台殊为不易,我们还在探索前进并不断引入最新的技术,使得构建平台成为滴滴研发效能工具链中最坚实的环节。
本文转载自公众号滴滴技术(ID:didi_tech)。
原文链接:
https://mp.weixin.qq.com/s/8wk-t2UoQQPG-OA2C5I9XA
评论