Monorepo架构: Nx Cloud 扩展能力与缓存加速

关注

原创最新推荐文章于 2026-11-13 19:31:25 发布 2k 阅读 AI 写同款· GEO 优化 ›

Monorepo架构: Lerna、NX、Turbo等对比与应用分析文章摘要在大型Monorepo项目中，Nx、Turbo、Lerna和Rush是主流工具。Nx下载量最高，生态成熟，支持构建优化、任务并行和分布式计算；Lerna专注于版本管理和发布，可与Nx互补。Turbo作为轻量构建工具，性能稍逊于Nx且缺少插件生态。Rush由微软维护，依赖隔离设计更贴近Node习惯，但扩展性较弱。Lerna提供缓存、版本控制和高效发包能力，适合CI场景；Turbo简化Monorepo初始化，但功能较基础。综合来看，Nx适合复杂构建需求，Lerna长于版本管理，Turbo适合轻量级场景阅读详情

借助 Nx Cloud 实现项目协同与加速构建

1 ）缓存工作原理分析

在了解了本地缓存和远程缓存之后，我们来探究缓存是如何工作的。
以计算文件的哈希串为例，若后续运行任务时文件哈希串未变，系统会直接使用对应的输出和制品文件。

2 ）远程缓存的机制与优势

参考 Nx 的官方文档，远程缓存与可遍历缓存类似。
当使用本地构建命令时，系统会检查远程是否存在对应文件，若有则利用该缓存下载到本地，辅助其他构建任务，省去部分包的构建成本，提升构建速度。

3 ）实现远程缓存的步骤

Lerna 与 Nx 的关系：Lerna 本身没有缓存能力，而是借助 Nx 内置命令实现了缓存和远程缓存功能
连接远程缓存：使用 nx connect 连接到指定端点，即可使用远程缓存。
登录 Nx Cloud：打开 Nx App 网站（即 Nx Cloud），点击右上角“Sign in”，可以使用 GitHub 账号登录。
默认情况下，新用户没有组织（Organization），免费用户可创建一个组织，一个组织下可创建一个免费的工作区（Workspace）。

4 ）远程缓存的实践操作

连接工作区：执行 npx nx connect 命令，按照提示操作，连接到 Nx App 创建工作区。若提示无 nx modules，安装 nx -d -w 。安装完成后再次执行NPX NX connect，根据提示操作，进度条走完后会自动跳转到workspace。完成连接后，系统会自动跳转到工作区页面。
构建项目测试：使用 package.json 中的 run build 命令构建项目，完成后可查看缓存文件。再次执行“npm lerna rebuild”（未删除缓存文件），会从本地读取缓存
重置缓存测试：执行 nx reset 命令重置远程工作区的缓存，再次执行构建命令，系统会重新生成缓存
模拟协作开发：在新目录下安装依赖，执行 npx nx build head 命令，系统会从远程缓存读取输出，实现缓存复用

5 ）用户权限与使用限制

访问权限
- 用户可通过创建访问令牌（Access Token）或添加成员（Members）的方式，让其他开发者访问工作区。
- 使用 token 方式：可通过点击“workspace”的“settings”，选择“manage tokens”，创建“access token”，复制给其他小伙伴使用。也可配置“members”，他们拥有访问“workspace”和创建“access token”的权限。
- 免费用户可拥有 30 个贡献者（Contributors），进阶版本每月可拥有 50 个。
使用限制
- 免费版 Nx App 用户数量不限，但每个用户只能创建一个组织
- 此外，Nx Runs（最大执行脚本数量）限制为 5 万个

6 ）其他缓存方案探索

若想使用自定义缓存，可在 NPM 上搜索相关包，有开发者创建了连接不同服务商（如 S3、谷歌等）的缓存方案。
相比之下，Nx 的开放性优于 Lerna。在使用 Nx 时，可通过 npx nx reset 重置工作区，执行 npx nx run-many --target=build 命令测试远程缓存效果，首次构建可能受网络影响耗时较长，后续构建则速度较快。

NX Cloud扩展能力解析：Agents等功能介绍与应用

一、NX与其他工具对比及NX Graph功能

经过前面的实践，大家可能会感觉NX和前面的Gradle区别不大
虽然有了某种支持后，NX对于版本管理表现不错，但它的优势究竟在哪里呢？
对于特别复杂的企业级应用，NX提供了Graph功能。大家可以选择NX，然后点击“Explore Graph”，直接使用NX Graph就能查看项目中的依赖关系。
通过这样的关系图表，能非常清晰地看到项目中各个模块对具体包的使用情况。
如果项目很复杂，使用这个可视化图表可以方便我们快速了解项目结构，这是NX第一个非常亮眼的功能。

二、Remote Caching及NX Agents功能

第二个功能是Remote Caching，之前已有提及。现在来说第三个很强大的功能。
目前，NX还未完全开放NX Agents功能，它属于NX Cloud的一部分。
NX Agents相当于我们在运行Jacons或者 GitHub Actions 时，可以创建多个并行任务。官方云服务提供了一些代理，可用于运行NX构建任务。
其代理功能或特性在于能够进行分布式任务（Distributed Task），这是整个CLI自带的功能，它将生态与云服务相结合，非常酷。
当与NX Cloud结合运行任务时，如果结合自己的CLI Provider，比如运行构建、测试等任务，整个流程可以交由自己的CI Provider，比如Jenkins或者Bitbucket Pipelines会有自己的Workers或Runners，运行特定脚本，再由NX Cloud进行分发。也可以全权交由 NX Cloud Workloads，它会创建这些Agents。
不过，使用这些资源需要付费。其好处是可以使用Agents产生的制品文件，加速整个构建过程。

三、与Git Actions结合的流程及加速效果

在官方文档的CI部分，选择“Recipes”，其中有一个“Setting up GitHub Actions”。
这里有几个菜单，先介绍第一个“Process only affected projects with one job on GitHub Actions”。
GitHub Actions会产生一些制品，我们可以在一个GitHub Action的任务中，运行那些已被修改的项目。
其Actions配置较为清爽，首先“Checkout”读取对应代码，然后配置Node环境，安装依赖，接着执行“NX Cloud Record”记录对应内容，之后“NX Affected”运行对应任务，最后并行执行任务。
这个Action会获取最后一次构建主分支上的内容，对比缓冲文件，加速后续构建过程。对于一些前端同学来说，面对众多工具包、环境和CICD流程，可能会对NX的出现感到困惑。
但实际上，NX的作用很明显，比如我们使用PNPM加速安装包过程，在国内还会使用淘宝源。而NX Cloud能加速构建过程，原本未使用缓存时构建花费11秒，配合NX Cloud缓存后降到2秒。
官方文档的配置存在一些问题，修改后放在课程资料文件夹里。对于Mitab项目，不能使用NPM CI，而要使用PNPM，配合GitHub Actions的PNPM缓存加速，可快速构建项目。除了GitHub Actions，还可与其他工具整合，原理类似，都是借助NX Cloud的构建缓存能力加速构建。

四、分布式任务菜单及NX Agents发布情况

第二个菜单是“Distribute tasks across agents on GitHub Actions”，需要设计分布式任务，执行特定命令会产生配置文件

NX 团队协同提效新方案

借助 Azure 存储构建缓存的申请、配置与权限管理

1 ) 背景与问题提出

前面我们介绍了 Nx 这类自动化构建工具，它能为我们带来本地化缓存或云端缓存。
虽然 Nx 比 Turborepo 要好，其自动化缓存，包括远端缓存的实现也较为流畅，但深入思考会发现存在一些问题。
一个项目可对应一个 workspace，项目中也能对应多个 Monorepo 项目，免费账户基本够用。然而，当公司有多个项目需要协同开发时，会发现 Turborepo 和 Nx 的远端缓存收费较贵。
以 Nx 为例，其 Pro 会员每月 75 美元，支持 Nx Agents 和 Nx Workflows，但目前 Nx Agents 仅处于 Review 版本，尚未全面铺开，Nx Workflows 也是如此。
对于绝大多数中小企业来说，Nx 的入门版本和进阶版本价格偏高。实际使用中，我们用到的功能可能与 GitHub Actions 类似，主要是 CI 和远端缓存，而远端缓存对构建有一定的提速效果。
若团队内部有多个前端项目需使用 Nx 工具实现构建缓存加速，该如何解决呢？
有同学提出使用 Turborepo 或注册多个 Nx 账号，但在开发不同项目时切换账号较为麻烦。还有同学想在团队内部使用共享存储或用 bat 文件上传.nx 文件实现共享，但这种方式存在问题，因为项目代码修改后，.nx 文件共享困难，且文件不是实时更新的，可能会导致项目出现 bug。

2 ) 解决方案探索

我们之前介绍 Nx 缓存时，提到过一个项目叫 @nx-tools/remote-cache-custom，它可自定义缓存，是核心包。其作者还开发了 @nx-tools/remote-cache-azure，这是基于微软云服务的项目。@nx-tools/remote-cache-custom 暴露了三个钩子方法：
- 1. findExisting：当文件存在时，后续的逻辑处理。
- 1. retrieveFile：发现文件后，下载对应的文件。
- 1. storeFile：与远端文件比对，若文件不存在，则存储文件。
若要自定义缓存，需读取对应的接口。在 Nx 生态中，已有相关工具，如 liveindexPS 直接从 @nx-tools/remote-cache-custom 中读取 createCustomRunner 并初始化环境变量。
createCustomRunner 会获取一个客户端，该客户端会拼接存储中的用户信息、workspace 容器信息以及上传或下载文件的信息，以此判断存储中是否有对应文件。
自定义存储后，团队可创建多个存储空间，不同的存储空间对应不同项目，使用相同的远端存储实现项目存储共享。

3 ) 实践操作步骤

云服务申请与存储账户创建
- 微软提供的云服务可免费试用，包含存储服务。点击免费试用后，在查看服务中选择查看所有免费服务，能找到存档存储。
- 注册账号需绑定国内信用卡，可选择中国地区。登录后，点击创建资源，搜索存储账户并选择创建。新注册用户有免费试用名额，需新建资源组，存储账户名称尽量简单，如 “toMC”。区域选择方面，若在公司内部使用，建议选择与国内较近的区域，如日本、韩国或亚洲东部；若对成本敏感，可选择美国的区域。性能选择标准即可，启用分层命名空间，网络选择所有网络的公共访问，数据保护部分保持默认。创建完成后，会得到一个存储账户。
创建容器
点击进入存储账户，创建对应的容器，如 “NXworkspace”，为方便测试，可将其名称改为 “demo”。
项目配置
- 选择一个空项目，初始化 repo、nx 和 lerna，安装项目依赖后，使用 pnpm install @nrwl/nx-cloud -d -w 安装，再用 npx nx init 初始化 Nx 配置文件，配置缓存任务为 build 和 test。
- 安装 @nx-tools/remote-cache-azure，将配置信息复制到项目的 nx.json 文件中。必填的四个选项为：
  - accountName：存储账户名称。
  - accountKey：在存储账户的左侧点击访问密钥，复制其中一个密钥。
  - container：容器名称，即 “NXworkspace-demo”。
验证与测试
- 使用 npx nx run-many -t build 执行构建任务，并将结果缓存到远端。执行前，容器内无内容，执行后，会推送压缩后的文件。
- 清除本地缓存后再次执行构建任务，会提示使用远端缓存。
权限配置
- 为控制权限，可针对容器设置权限。在容器左侧点击共享访问令牌，配置读取、写入等权限和所有权，设置有效期后生成 SAS URL。将不需要的 accountName 和 accountKey 删除，仅保留 container。调整权限后再次构建，可验证权限设置效果。
- 团队其他成员可将 Nx 的配置文件上传到服务器，使用 .nx 文件读取配置。在不同机器上测试，可验证构建效果。