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

借助 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：当文件存在时，后续的逻辑处理。
  • 2. retrieveFile：发现文件后，下载对应的文件。
  • 3. storeFile：与远端文件比对，若文件不存在，则存储文件。

• 若要自定义缓存，需读取对应的接口。在 Nx 生态中，已有相关工具，如 liveindexPS 直接从 @nx-tools/remote-cache-custom 中读取 createCustomRunner 并初始化环境变量。

• createCustomRunner 会获取一个客户端，该客户端会拼接存储中的用户信息、workspace 容器信息以及上传或下载文件的信息，以此判断存储中是否有对应文件。

• 自定义存储后，团队可创建多个存储空间，不同的存储空间对应不同项目，使用相同的远端存储实现项目存储共享。

3 ) 实践操作步骤

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

总结

• 本文介绍了使用 Nx 配合微软 Azure 云服务加速项目构建的过程，包括注册云服务、配置存储服务、创建容器、配置项目和设置权限等步骤
• 配置用户访问容器有两种方式
  • 一是提供密钥，用户可操作整个存储账户空间
  • 二是使用容器的共享令牌功能，可控性更好，可设置权限和有效期