最近一个月我把手头负责的微前端跨仓构建链路整体重写了一遍核心是换上了一套叫 Peaks-Loop 的构建编排方案。重写之后全量构建从原来的 28 分钟降到了 15 分钟出头日常增量构建基本稳定在 6 到 8 分钟整体提速大约 45%。这篇文章我把接手时的痛点、方案选型、DSL 设计、迁移过程到踩坑记录完整过一遍给正在被多仓构建搞得焦头烂额的同行一点参考。先交代一下背景。我管理的这套微前端项目有几十个独立仓库包含登录态、用户中心、基础组件库、业务组件、灰度配置平台等。每个仓都有自己的 CI 流水线仓库之间存在真实的依赖关系业务仓依赖组件仓组件仓又依赖基础库。以前最痛苦的就是上游一个基础库发版下游所有业务仓都要重新构建验证而这个重新构建不是并行触发的而是靠人肉在群里喊话排着队等。我换掉的不只是某个打包器配置而是整套构建编排思路不再用一堆命令式脚本告诉你先执行 A再执行 B如果失败了执行 C而是用 Peaks-Loop 这套偏自然语言的声明式 DSL直接把构建意图说出来。剩下的依赖分析、任务调度、缓存复用、变更跳过全部交给引擎处理。这篇文章就是一次完整的实战拆解。1. 跨仓构建为什么这么慢先搞清楚卡在哪1.1 多仓微前端的典型痛感先别急着谈优化得先把痛点说透。多仓微前端和单仓最大的区别是代码不在一块但运行时却要合在一起。每个业务仓独立部署产出的却是同一个页面里不同区块的 JS 产物这就导致构建之间存在天然的时序依赖。我当时接手后的第一周大概摸清了几个核心场景基础库仓发版后下游十几个仓都需要重新构建但每个仓的 CI 是独立的没人能自动感知该你重建了。跨仓联调时需要先在本地把上游产物构建好再手动改下游仓的版本引用。如果上游依赖链比较深光本地构建可能就要二十分钟。CI 上每次全量验证都是从头跑一遍大量任务明明可以复用上一轮的构建产物却被白白重复执行。最典型的一次事故是基础库升级了一位小数版本结果下游某个业务仓构建出来的是旧版本产物原因就是它没有及时拉取最新依赖包。这类问题在跨仓场景下几乎每周出现一次。这些痛感汇总起来就是三个字没秩序。构建的前提是依赖就绪但没有任何机制去保证依赖就绪这件事。脚本和 CI 模板只是把人肉通知变成了脚本通知并没有从根上解决依赖编排问题。1.2 为什么传统工具解决不了有人可能会说用现成的 CI 编排工具不行吗可以写 pipeline也可以写 job 依赖为什么非要自己搞一套我的真实体验是传统 CI 编排工具擅长的是在一套流水线里安排步骤但它天然假设所有任务都在同一个 runner 上下文里。到了跨仓场景你要解决的是分布在多个仓库里的独立流水线如何按全局依赖关系协同执行。这时候如果硬要用 CI 模板去套写出来的东西会非常痛苦仓库之间没有全局的依赖图每个仓只知道自己的上游是谁不知道全局链路。构建产物之间的传递靠推到制品库再拉取但谁来触发上游构建、谁来等待产物就绪没有任何一致协议。缓存策略完全靠各仓自己维护有的仓做了缓存有的仓根本没做全量构建时水平参差不齐。更关键的是所有流水线都是命令式的你写死了先做什么、后做什么。一旦依赖关系变化脚本就要跟着改维护成本极高。所以我才转向 Peaks-Loop 这种思路与其去编排怎么做不如先描述要什么。比如构建用户中心它依赖统一认证平台的产物请先确保认证平台构建完成然后并行执行测试和打包。这种描述本身是接近自然语言的也是人可以理解的剩下的交给引擎去翻译成真正的执行计划。2. Peaks-Loop 的设计逻辑把构建意图说出来2.1 自然语言 DSL 长什么样Peaks-Loop 的核心是一套声明式 DSL用接近自然语言的字段去描述一个构建任务。我第一次看到它的时候觉得有点神奇因为写起来确实不像代码更像是在填一份需求单。看一个最简单的例子pipeline: - name: 构建认证平台 kind: build pkg: scope/auth-center trigger: event: push branch: [main, release/*] deps: - name: scope/base-utils version: latest source: registry steps: - run: pnpm install --frozen-lockfile - run: pnpm build - run: pnpm test -- --run cache: key: | {{ hashFiles(pnpm-lock.yaml) }}-{{ version }} artifacts: - dist/auth-center/*这段描述的意图很清晰构建一个叫认证平台的包它依赖基础工具库的最新版本构建步骤是先装依赖、再打包、再跑测试并且用 lockfile 的哈希加上版本号来区分缓存。你可能会觉得这就是个 YAML 配置文件没什么稀奇的。但 Peaks-Loop 和普通 CI 配置最大的区别在于它不会照着写死的顺序执行。deps 字段会被解析成真正的依赖关系trigger 字段会被解析成触发条件cache.key 会被计算成真正的缓存指纹。也就是说这份 DSL 最终会被编译成一张有向无环图DAG引擎根据这张图来调度任务。2.2 从描述到执行解析、DAG、调度Peaks-Loop 的执行过程大概分三段。我用自己的话翻译一下第一段是意图解析。它会把上面这种 YAML 文本解析成结构化对象提取出每个任务的名字、依赖、步骤、产物、缓存键等。这一步相当于读懂自然语言描述。第二段是依赖图构建。把所有任务当作节点把 deps 字段当作边生成一张全局 DAG。这一步最关键因为只有拿到全局图才能知道哪些任务可以并行、哪些任务必须等待上游完成。比如构建用户中心依赖构建认证平台那认证平台没跑完用户中心就只能排队。第三段是执行调度。引擎按 DAG 的拓扑顺序调度任务能并行的就丢给多个 worker 同时执行不能并行的就阻塞等待。每个任务执行前还会先查缓存如果缓存命中直接跳过执行步骤把产物从缓存里恢复出来。这三段式的好处是把描述和执行彻底解耦了。想调整并行策略不用改 DSL只改引擎的调度参数。想改变量检测规则也不用动每个仓的配置文件引擎层统一处理。这比每改一次构建逻辑就要动一堆仓的脚本要省太多事。2.3 为什么敢把关键逻辑交给声明式配置我刚开始也犹豫过把真正的执行顺序从命令式脚本改成声明式 DSL会不会失控后来对比了一下才觉得这一步是值得的。命令式脚本最大的问题不是不能跑而是只能按写的顺序跑。一旦依赖关系多了脚本里全是嵌套的 if 和 await根本看不出整体结构。而声明式配置把依赖什么和怎么执行分开反而更容易推理。我整理过一个对比表列在下面维度命令式脚本Peaks-Loop 声明式 DSL逻辑表达表达如何执行表达依赖什么、要什么结论依赖关系靠调用顺序隐含靠 deps 字段显式声明变更响应脚本要跟着改引擎重新解析依赖图即可缓存复用基本靠外部配置内置缓存键和产物指纹机制并行控制自己写逻辑引擎按 DAG 自动调度可审计性跑起来才知道顺序静态解析即可看到全貌当然声明式也不是银弹它要求你对依赖关系有足够清晰的认知。如果你的项目依赖是乱七八糟的网状结构声不声明式都是灾难。但只要你愿意花时间把依赖理清楚声明式的收益是实打实的。3. 实战迁移把旧构建链路重写成 Peaks-Loop3.1 迁移前准备与仓库摸底真正动手改之前我没有直接写 DSL而是先花了两天时间做仓库摸底。这个环节千万别省。很多迁移出问题就是因为还没搞清楚仓库之间的真实依赖就开始改配置结果解释出来的 DAG 全是错的。摸底我主要做了四件事拉出所有仓库清单记录每个仓的构建命令、产物目录、部署方式。遍历每个仓的 package.json 和 import 语句找出它实际依赖了哪些内部包。把所有依赖关系整理成一张表格按被依赖次数排序找到最底层的几个基础仓。手动跑了一次全量构建记录每个仓的真实构建耗时找出耗时最长的几个瓶颈。其中第 3 步特别关键。因为 Peaks-Loop 的 DAG 是以 deps 字段为依据的如果我在 DSL 里漏写了某个隐含依赖轻则顺序错误重则直接构建失败。我之前就碰到过运行时才报错的隐式依赖一个业务仓在代码里直接引用了另一个业务仓的源码路径但 package.json 里根本没有声明。这种情况靠人眼检查很难发现我是用脚本扫描 import 语句才揪出来的。摸底完之后我画了一张粗糙的依赖图就是纸上的箭头图确认每个仓的上游和下游。确认无误后才开始逐个仓写 DSL。3.2 改造后的 pipeline 配置示例以一个比较典型的业务仓为例我给出迁移后的完整配置pipeline: - name: 构建用户中心 kind: build pkg: scope/user-center trigger: event: push branch: [main, release/*] deps: - name: scope/auth-center version: latest source: artifact - name: scope/ui-components version: latest source: artifact steps: - run: pnpm install --frozen-lockfile - run: pnpm build:web - run: pnpm test -- --run cache: key: | {{ hashFiles(pnpm-lock.yaml) }}-{{ env.BUILD_ID }} restoreKeys: - {{ hashFiles(pnpm-lock.yaml) }}- artifacts: - dist/user-center/* notify: onSuccess: [slack, artifact-center] onFailure: [slack]这个配置里有几个细节值得解释第一个是 deps 里的 source 字段。我用的有 artifact 和 registry 两种来源。artifact 表示依赖的是上游构建产物会触发上游任务先执行registry 表示依赖的是制品库里已发布的版本不会触发上游构建。这两种来源的语义差别很大直接影响 DAG 的形状。第二个是 cache 的 restoreKeys。它表示如果精确缓存键没有命中尝试恢复相近的缓存。比如 lockfile 没变但 BUILD_ID 变了这时候精确键命中不了但通过 restoreKeys 可以恢复到之前任意一个版本减少很多重复安装。第三是 notify 字段。跨仓构建最怕上游失败了下游还在傻等。有了通知机制引擎会在任务状态变化时自动通知到制品中心和 IM 群不需要人肉盯着。实际迁移过程比想象中顺畅最耗时的反而是把仓库依赖关系摸清楚这个前置动作。一旦依赖图画对了写 DSL 本身非常快平均一个仓十分钟左右。3.3 关键参数与优化计算配置写完了还要调一堆运行参数。这里我把几个关键参数的计算过程记录下来方便你直接抄作业。先看并发 worker 数。我最初看到文档推荐的公式是max(4, CPU 核数 - 2)但实测发现不一定最优。我用的构建机是 16 核 64G如果设成 14 个 worker跑全量构建时 CPU 会瞬间打满部分任务反而因为等待资源而变慢。后来我压测了几组数据发现 8 到 10 个 worker 是比较稳的区间既能让 CPU 保持较高利用率又不会因为争抢资源导致单任务变慢。再看缓存键设计。这里有一个原则缓存键要能区分真正影响产物的输入。我最终采用的组合是lockfile 哈希 包版本号 平台标识。你可能会问为什么不用源码哈希因为源码哈希每次提交都会变用了它等于缓存永远不命中。反而是 lockfile 哈希控制依赖变化包版本号控制业务版本变化平台标识防止跨平台误用这三者组合起来在命中率和安全性之间比较平衡。最后是产物指纹。Peaks-Loop 会在每个任务完成后算出当前任务所有产物文件的哈希值作为该任务的最新指纹。下游任务判断自己是否需要重建时只需要比对上游指纹是否变化而不是傻乎乎地每次都全量构建。这个机制对只改了一个组件库但想跳过不受影响的仓非常有用。我在迁移时做过一个估算旧方案全量构建要执行大概 40 多个独立任务其中至少有 60% 的任务有缓存可以命中但因为旧方案没有统一缓存这些命中机会全部浪费了。换成 Peaks-Loop 后光是缓存命中这一项就省掉了全量构建中近半的耗时。4. 数据对比与 45% 提速拆解4.1 优化前后耗时对比迁移完成、压测稳定之后我整理了一组真实的耗时数据。下面的表是我记录的几组典型场景对比场景优化前耗时优化后耗时收益全量冷构建无缓存约 28 分钟约 15 分钟 40 秒约 44% 降幅基础库发版后的全量验证约 30 分钟约 16 分钟约 47% 降幅业务仓增量构建约 9 分钟约 5 分钟约 44% 降幅只改一个无关仓的构建约 9 分钟约 2 分钟约 78% 降幅多仓联合构建5 个仓约 24 分钟约 13 分钟约 46% 降幅标题里说的 45%其实是个综合口径主要参考的是第一、二、五这三条典型链路。单看某一场景收益可能更高或稍低但整体稳定在 45% 左右。需要诚实说明的是冷构建情况下 28 分钟降到 15 分钟 40 秒并不是因为每个任务都跑得更快了而是因为很多任务跑了五六个不同的构建环境里并行执行同时任务间不再有排队等待上游产物的浪费。4.2 提速从哪来我拆了一下45% 的提速主要由四块组成第一块是并行调度。旧方案里多个业务仓同时需要构建时CI 上是串行排队一个跑完另一个才开始。Peaks-Loop 解析出 DAG 后发现很多仓库之间其实是平级关系完全可以并行构建。这一块贡献大约占提速中的一成半。第二块是缓存命中。旧方案的缓存基本是摆设因为每个仓独立缓存缓存键还不统一。Peaks-Loop 把缓存键规范了lockfile 没变的仓直接命中缓存不重新执行安装和打包。这一块对基础库和公共组件仓特别明显贡献接近提速中的两成。第三块是跳过未变更仓。以前只要基础库发版下游所有仓都会触发全量重建。现在引擎会根据上游产物指纹判断——如果基础库的改动实际上没有影响某个业务仓那个仓就会被自动跳过或者只执行构建不执行测试。这个机制让无关仓的构建时间从 9 分钟降到了 2 分钟左右。第四块是依赖等待的消除。旧方案经常出现下游仓提前触发构建结果上游产物还没上传导致下游构建失败重跑的情况。Peaks-Loop 严格按 DAG 调度上游没完成就绝不启动下游任务。看着只是规避了失败重跑但实际上省掉了大量无效等待时间。4.3 调优中的取舍提速不是无脑调高并行度就行的我在调优过程中踩过几个坑简单说一下取舍逻辑。并行 worker 数不是越大越好。我之前为了追求极致速度把 worker 调到 14结果 16 核机器上任务互相争抢 CPU反而让每个任务变慢了 30%。最后压测发现 8 到 10 基本是甜点区。缓存策略也要分场景。全量冷构建时缓存命中率低这时最该做的是尽量并行增量构建时缓存命中率高最该做的是尽早跳过无关任务。这两者其实是两个优化方向Peaks-Loop 的好处是它们都通过配置表达不用改代码。还有一点关于跳过未变更仓的取舍跳过任务省了时间但也可能掩盖真实依赖关系。我刚开始太激进凡是上游指纹没变的仓都跳过结果有一次基础库改了一个全局样式变量但指纹计算没有感知到样式文件的变更导致下游仓拿到的是旧样式页面直接乱了。后来我把指纹计算范围扩大把样式文件、配置文件、环境变量模板都纳入进来这种情况再也没有出现。5. 常见问题与排查实录5.1 缓存不生效永远在冷构建迁移后我遇到过最气人的问题就是配置好了缓存但每次构建还是全量跑缓存形同虚设。排查过程让我学到不少东西。首先是缓存键设计得不稳定。我一开始用的是构建环境变量 BUILD_ID但每次构建 BUILD_ID 都会变导致精确缓存键永远匹配不上。虽然我配了 restoreKeys但 restoreKeys 只恢复依赖安装缓存不恢复构建产物。后来我改成只对真正影响产物的输入做哈希缓存才开始生效。其次是产物恢复失败。有时候缓存键匹配上了但产物解压过程失败或者产物目录权限不对Peaks-Loop 会默认当成缓存无效重新执行一遍。这个问题在 Windows runner 上特别明显后来统一换成容器执行器才稳定。排查缓存问题的一个小技巧在引擎日志里看每个任务的 cache 状态。如果看到 cache miss马上看它打印的完整缓存键和 restoreKeys对比一下就能知道是键不匹配还是恢复失败。这一招帮我省了不少时间。5.2 DAG 出现环依赖方向写反了还有一次是配置写完没问题一执行就报检测到循环依赖。我一开始以为是 Peaks-Loop 的 bug后来定位发现是自己在 deps 里写反了方向。我当时把构建用户中心误写成了依赖用户中心而用户中心又依赖认证平台认证平台实际上不依赖用户中心。看起来就是个粗心错误但问题在于两个仓互相引用了对方的包名脚本扫描时我以为是双向依赖直接把它写成了互相 deps。解决办法很粗暴手动把依赖方向理一遍再在 DSL 里把所有 deps 统一改成只依赖真正需要在构建时存在的上游产物不需要的引用坚决不写进 deps。DAG 有环的时候不要想着让引擎帮你处理因为编译器只会报错而不会帮你想清楚。5.3 并行构建抢占资源导致 OOM并行度调高之后随之而来的是 OOM 问题。我最初遇到的是两个大仓同时执行打包任务内存直接打满runner 被系统杀掉构建直接失败。排查时我看了执行日志发现是因为 Peaks-Loop 默认的 worker 内存上限是跟着 runner 走的但各个任务实际内存占用差异很大。有的打包任务一个就要吃 8G有的测试任务连 1G 都用不到。让所有任务都按统一内存上限去跑大任务必然崩。解决办法是给每个 pipeline 加了资源配额描述resources: cpu: 2 memory: 8Gi同时对两个特别耗内存的任务加了并发互斥配置保证它们不会在同一时间被调度到同一个 worker 上执行。从那之后OOM 问题基本没有再出现过。5.4 环境一致性本地产物能定位到代码版本还有一个容易被忽略的坑跨仓构建产物必须和环境变量模板、Node 版本保持强一致。有一次业务仓换了一个 Node 大版本导致基础库产物接口不兼容线上页面白屏。Peaks-Loop 好的一点是它允许你在 pipeline 里声明 runtime 环境并把 runtime 指纹也纳入缓存键和产物指纹计算。这样只要 Node 版本变了上游指纹就会跳变下游就会感知到产物变了需要重测。如果你不把这个纳入进来很容易出现构建明明成功了但运行时却是坏的这种诡异问题。我在每个 pipeline 顶部都加了runtime: image: node:20.11-bullseye-slim然后所有构建、缓存、指纹都基于这个 image 的版本计算。这条改动看似简单实际上救了后面好几次。5.5 小技巧把变更检测伪装成旁路任务最后分享一个我偷偷加的小技巧。Peaks-Loop 默认的变更检测是基于上游指纹是否变化但我还想知道某个仓的改动到底影响了哪些下游仓用来做通知和分析。我的做法是写了一个轻量的旁路任务它不负责构建只负责扫描本仓涉及的文件变更列表然后计算这些文件会影响到哪些下游仓最后把结果写到一个 JSON 文件里作为该任务的产物之一。- name: 输出影响分析 kind: analyze steps: - run: node scripts/impact.js impacts.json artifacts: - impacts.json这个产物本身不影响构建结果但下游的 notify 流程可以读取它在群里自动播报用户中心本期影响仓A、B、C请相关负责人关注。对一个跨仓协作的团队来说这个信息比单纯的构建成功有用得多。它不是什么高深技术纯属给现有方案加的一个辅助功能但对跨仓协同的效率提升非常明显。我个人在实际操作中的体会是Peaks-Loop 这套方案最大的价值不是省了那十几分钟构建时间而是让跨仓构建这件事第一次有了一个可依赖的全局秩序。以前大家靠吼、靠等、靠反复试错现在只要 DSL 写对了剩下的一切都有据可查。如果你也在被多仓微前端构建折磨建议先从仓库依赖摸底开始把依赖图画出来再考虑上声明式编排。不要一上来就追求把配置写得漂亮依赖关系理不清配置再好看也是空中楼阁。
