80 lines
4.0 KiB
Markdown
80 lines
4.0 KiB
Markdown
# 分布式编译系统ShareBuild
|
||
|
||
## 为什么需要分布式编译？
|
||
- 大型项目过长的编译耗时将会给开发、测试和调试都带来延迟，所以缩短大型项目的编译时间的分布式编译系统有重要意义
|
||
- 使用分布式编译系统编译项目可以利用计算机集群提高编译效率，缩短项目编译时间
|
||
- 在实际开发时，同一个团队大量的编译任务时相同的。CloudBuild提供的编译缓存可以避免重复上传和重复编译，从而进一步加快编译效率
|
||
|
||
## 总体架构
|
||
### 系统总体架构
|
||
|
||
- Ninja：客户端，该机器上需要保存有完整的待编译项目源代码。
|
||
- Action Cache：服务端缓存，主要保存编译任务的执行结果。
|
||
- CAS Cache：服务端缓存，主要保存客户端上传的依赖文件，编译结果文件。
|
||
- Scheduler：任务调度器，将编译任务id分发到各个编译节点。
|
||
- Redis：主要存储具体的编译任务供编译节点领取执行，也可存储Action Cache和 CAS Cache中的内容加速编译。
|
||
- MySQL：主要存储编译过程中的任务统计信息。
|
||
- Executor：各个编译节点
|
||
|
||
### 部署示意图
|
||
|
||
CloudBuild主程序分为三个部分：Client、Server、Executor。
|
||
- Client：运行在客户端，和用户对接，用于生成待执行的远程编译任务， 同时也作为本地编译节点执行本地任务。
|
||
- Server：运行在主服务器，主要用于连接各个编译节点，以及 将客户端上传的编译任务调度到与其连接的各个编译节点上。
|
||
- Executor：运行在编译节点，负责接收并执行编译任务，是编译任务真正执行的地方。
|
||
|
||
### 系统分层结构
|
||
|
||
|
||
## 运行原理与流程
|
||
|
||
### 分布式编译原理
|
||
|
||
|
||
### CloudBuild客户端
|
||
CloudBuild客户端基于Ninja改造，有下面这些优势
|
||
- 兼容使用Ninja编译的项目
|
||
- 使用远程执行的方式提高编译时并发度
|
||
- 使用编译缓存减少需要编译的任务数量
|
||
|
||
### CloudBuild服务端
|
||
- 使用远程执行的方法提高编译时并发度，实现了任务分发至远程节点同步执行
|
||
- 使用分布式任务调度提高任务调度效率和计算节点资源利用率，避免集中式调度的任务阻塞问题
|
||
- 使用编译缓存结合内容寻址存储技术减少网络传输量、避免重复上传与重复编译
|
||
|
||
### CloudBuild优势
|
||
- 低成本：组成executor的机器不需要使用专门的高性能计算型机器，可使用多个平价的空闲机器
|
||
- 高效：CloudBuild实现分布式编译的功能，相比单机大大提升并发度
|
||
- 兼容Ninja：CloudBuild客户端基于Ninja改造，对于使用Ninja构建和可以转换为Ninja构建的项目不用额外修改构建清单
|
||
|
||
### CloudBuild执行流程
|
||
- 客户端: 生成远程任务->生成任务依赖->发送任务与依赖
|
||
- 服务端：检查任务缓存->检查依赖完整性->调度任务
|
||
- 编译结点：还原文件目录->还原文件目录->返回编译结果
|
||
|
||
## AOSP和LLVM上的应用
|
||
### LLVM上的应用效果
|
||
|
||
### AOSP上的应用效果
|
||
|
||
### CloudBuild硬件资源利用率
|
||
4核CPU利用率:
|
||
|
||
8核CPU利用率:
|
||
|
||
16核CPU利用率:
|
||
|
||
|
||
## CloudBuild使用方法
|
||
### CloudBuild安装
|
||
|
||
CloudBuild项目地址：https://gitee.com/cloudbuild888/cloudbuild.git
|
||
### CloudBuild分布式编译
|
||
|
||
LLVM项目地址：https://gitee.com/mirrors/LLVM.git
|
||
|
||
|
||
|
||
|
||
|