在之前的Github榜单中出现了今天要介绍的项目，搜了下，自媒体平台上没啥介绍；本着做自己没做过的才有挑战，做别人没做过的就更有挑战的精神，简单介绍下😄。
仓库：TraceMachina/nativelink
背景
每个程序员，都或多或少地了解一些常见的编译/构建系统，如：CMake 、Gradle，甚至更老的Ant、Maven等；这类开源软件已经有不少了，但为啥还要推出这一款 NativeLink 呢？感到疑惑的同学，看完这篇文章，相信一定能豁然开朗。
简介
NativeLink是一个高效、高性能的构建缓存和远程执行系统，它能够加速软件，尤其是大型软件的编译和测试过程，同时降低基础设施成本（存储、算力、网络、不一致环境导致的扯皮等）。它通过智能缓存构建产物、在多台机器上分发任务，为各种规模的项目优化构建过程和成本。
NativeLink在生产环境中被信任，能够降低成本和开发者迭代周期——每月为包括 三星 等在内的大型企业处理超过 十亿次请求 。
许可证
友好的 Apache 2.0 许可
原理&功能特点
原理：简单来说，NativeLink采用的原理，主要是以下两个：
分布式并行计算：把一个复杂的、大的构建（Build）任务，分布到多台计算机上并行执行以提高效率； 以空间换时间：存储并重用未更改组件在之前就已经构建好的结果；没改动的组件，没必要重新编译，可以把之前编译好的产物直接拿来使用。
记得之前做手机项目时，因为Android系统的庞大，一次本地完整编译，至少需要半个小时甚至几个小时，要不就得到编译服务器上用多个任务（job）的方式来并行编译，但也时常因服务器资源有限，不得不排队等，没法敞开用，极大地影响了工作效率，为了验证一些代码效果，很多时间花在等待构建上。
高级构建缓存：
存储并重用未更改组件的先前构建步骤的结果。 显著减少构建时间，特别是对于增量更改。
高效的远程执行：
在一组机器的网络上分发构建和测试任务。 并行化工作负载以更快完成。 使用远程资源减轻本地机器的计算负担。 确保与统一、受控的构建环境的一致性。
NativeLink 可以与使用远程执行协议的构建工具无缝集成，例如Bazel、Buck2、Goma和Reclient。它支持基于Unix的操作系统和Windows，确保在不同的开发环境中具有广泛的兼容性。
系统架构
Bazel、Buck2 或 Reclient 等创建一个 client 作业并将其发送到 scheduler 的作业队列。
在 scheduler 工作线程池中查找合适的工作线程，并将作业路由到该工作线程池。
运行 worker 作业，将输出工件发送到 cas .
提供 worker 工件的下载说明 scheduler 。
将 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的步骤：
使用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 \
configWindows 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做贡献。项目欢迎来自所有技能水平和背景的开发者的贡献！
项目统计
又是努力学习的一天，“朝闻道夕死可矣”😄
