仓库：TraceMachina/nativelink

背景

每个程序员，都或多或少地了解一些常见的编译/构建系统，如：CMake 、Gradle，甚至更老的Ant、Maven等；这类开源软件已经有不少了，但为啥还要推出这一款 NativeLink 呢？感到疑惑的同学，看完这篇文章，相信一定能豁然开朗。

简介

NativeLink是一个高效、高性能的构建缓存和远程执行系统，它能够加速软件，尤其是大型软件的编译和测试过程，同时降低基础设施成本（存储、算力、网络、不一致环境导致的扯皮等）。它通过智能缓存构建产物、在多台机器上分发任务，为各种规模的项目优化构建过程和成本。

NativeLink在生产环境中被信任，能够降低成本和开发者迭代周期——每月为包括 三星 等在内的大型企业处理超过 十亿次请求 。

许可证

友好的 Apache 2.0 许可

原理&功能特点

1. 原理：
   简单来说，NativeLink采用的原理，主要是以下两个：

• 分布式并行计算：把一个复杂的、大的构建（Build）任务，分布到多台计算机上并行执行以提高效率；
• 以空间换时间：存储并重用未更改组件在之前就已经构建好的结果；没改动的组件，没必要重新编译，可以把之前编译好的产物直接拿来使用。

记得之前做手机项目时，因为Android系统的庞大，一次本地完整编译，至少需要半个小时甚至几个小时，要不就得到编译服务器上用多个任务（job）的方式来并行编译，但也时常因服务器资源有限，不得不排队等，没法敞开用，极大地影响了工作效率，为了验证一些代码效果，很多时间花在等待构建上。

1. 高级构建缓存：

• 存储并重用未更改组件的先前构建步骤的结果。显著减少构建时间，特别是对于增量更改。
• 高效的远程执行：在一组机器的网络上分发构建和测试任务。并行化工作负载以更快完成。使用远程资源减轻本地机器的计算负担。确保与统一、受控的构建环境的一致性。

NativeLink 可以与使用远程执行协议的构建工具无缝集成，例如Bazel、Buck2、Goma和Reclient。它支持基于Unix的操作系统和Windows，确保在不同的开发环境中具有广泛的兼容性。

系统架构

1. Bazel、Buck2 或 Reclient 等创建一个 client 作业并将其发送到 scheduler 的作业队列。
2. 在 scheduler 工作线程池中查找合适的工作线程，并将作业路由到该工作线程池。
3. 运行 worker 作业，将输出工件发送到 cas .
4. 提供 worker 工件的下载说明 scheduler 。
5. 将 scheduler 下载指令转发给 client .

迁移到 NativeLink

常见的构建系统，例如 CMake 和 Gradle，是不支持远程执行的。而要使用 NativeLink，你需要先迁移到支持远程执行协议的构建系统。

不支持远程执行协议的构建系统的缺点：

1. 协作效率受限：
在团队协作开发的场景中，如果不支持远程执行协议，那么团队成员之间无法方便地在远程环境中协同执行构建任务。例如，不同地点的开发者无法直接远程触发构建，可能导致等待和沟通成本增加。

2. 资源利用不均衡：
无法远程执行意味着无法灵活调配远程服务器的计算资源。比如，本地机器性能不足时，不能利用远程强大的服务器来加速构建过程。

3. 环境一致性难以保证：
每个开发者都在本地执行构建，容易出现因为本地环境配置的差异而导致构建结果不一致的问题。例如，不同的操作系统版本、依赖库的版本等都可能影响到最终的构建产物。

4. 不利于持续集成和持续部署（CI/CD）：
现代软件开发流程中，CI/CD 非常重要。不支持远程执行协议会使将构建系统集成到 CI/CD 管道中变得困难，影响自动化部署的效率和可靠性。

5. 难以进行集中管理和监控：
无法远程执行就难以对构建过程进行集中的管理和监控。比如，无法及时获取构建的状态、错误信息等，不利于快速发现和解决问题。

以一个大型软件开发项目为例，如果使用不支持远程执行协议的构建系统，当多个团队分布在不同地区甚至时区时，很可能会因为无法远程统一构建和验证代码，导致版本合并时出现大量的冲突和错误，最终会严重影响项目的进度和质量。

迁移到支持远程执行协议的构建系统

这些支持远程执行协议（remote execution protocol）的系统有多种选择，包括：

• Bazel （最常见）
• Buck2
• Pants 裤子（比其他裤子不太常见，但经常用于 Python）

具体可以参阅每个构建系统的迁移指南。

剩下的步骤就是按照 NativeLink 的最新官方文档进行部署和配置了，最简单的是用云托管服务，它对个人、开源项目和云生产环境免费，并支持无限的团队成员；否则可以将 NativeLink 部署为自托管的 Docker 映像。

相关网址

• NativeLink官网
• NativeLink GitHub仓库

注意事项

• NativeLink可以通过Docker镜像部署，也可以使用云托管解决方案NativeLink Cloud。对于个人、开源项目和云生产环境，它是免费的，支持无限多的团队成员。
• 预构建镜像目前仅限于x86_64系统。可以在容器注册表中查看所有镜像标签，并在贡献文档中了解如何自己构建镜像。
• 使用Nix构建原生可执行文件虽然较慢，但更灵活，支持MacOS。不支持原生Windows，但在WSL2中工作。确保Nix版本是最新的，并支持flakes。例如，可以通过next-gen nix安装程序安装它。

快速开始

以下是部署NativeLink的步骤：

1. 使用Docker镜像部署：

• Linux x86_64：

curl -O \
https://raw.githubusercontent.com/TraceMachina/nativelink/main/nativelink-config/examples/basic_cas.json
# 查看 https://github.com/TraceMachina/nativelink/pkgs/container/nativelink
# 以找到最新标签
docker run \
-v $(pwd)/basic_cas.json:/config \
-p 50051 \
ghcr.io/tracemachina/nativelink:v0.4.0 \
config

• Windows x86_64：

# 下载配置文件
Invoke-WebRequest `
-Uri "https://raw.githubusercontent.com/TraceMachina/nativelink/main/nativelink-config/examples/basic_cas.json" `
-OutFile "basic_cas.json"
# 运行Docker容器
# 注意：如果脚本不在包含basic_cas.json的目录中运行，则需要调整路径
docker run `
-v ${PWD}/basic_cas.json:/config `
-p 50051 `
ghcr.io/tracemachina/nativelink:v0.4.0 `
config

• 使用Nix构建原生可执行文件：
• Linux, MacOS, WSL2：

curl -O \
https://raw.githubusercontent.com/TraceMachina/nativelink/main/nativelink-config/examples/basic_cas.json
nix run github:TraceMachina/nativelink ./basic_cas.json

有关更多信息，请参阅贡献文档。

贡献

访问他们的贡献指南了解如何为NativeLink做贡献。项目欢迎来自所有技能水平和背景的开发者的贡献！

项目统计

又是努力学习的一天，“朝闻道夕死可矣”

#头条创作挑战赛#

#妙笔生花创作挑战#