# 从 Node.js 迁移到 Bun 实现 5 倍吞吐量：Firestarter 服务的完整迁移路径 > Trigger.dev 将关键服务从 Node.js 迁移到 Bun，经历四轮优化实现 5 倍吞吐量提升，详细解析迁移路径、性能基准与隐藏的内存泄漏问题。 ## 元数据 - 路径: /posts/2026/04/06/why-we-replaced-nodejs-with-bun-for-5x-throughput/ - 发布时间: 2026-04-06T13:01:26+08:00 - 分类: [systems](/categories/systems/) - 站点: https://blog.hotdry.top ## 正文 在 Node.js 生态中，迁移到新运行时从来不是一件小事。当 Trigger.dev 决定将他们的 Firestarter 服务从 Node.js 切换到 Bun 时，他们的目标很明确：在不影响稳定性的前提下，获得显著的性能提升。最终结果令人印象深刻——5 倍吞吐量、28 倍更低的尾延迟、容器镜像体积缩减 62%。但过程远比预期曲折，Bun 的 HTTP 模型与 Node.js 存在根本性差异，如果不加注意，一个隐藏的内存泄漏足以吃掉所有性能收益。 ## 背景：Firestarter 服务的性能瓶颈 Firestarter 是 Trigger.dev 平台中的关键组件，它扮演着「预热启动连接经纪人」的角色。这个服务维护着数千个来自空闲运行控制器的长轮询 HTTP 连接，每个连接都在等待任务分发。当任务到达时，Firestarter 将其与等待中的控制器匹配，通过已建立的连接发送 payload，从而避免冷启动和容器拉起。这个服务位于_trigger.dev 每次任务执行的关键路径上。 原始实现基于 Node.js 运行，存在三个明显的性能热点：31% 的 CPU 时间消耗在 SQLite 查询上、每次请求都用 Zod 进行完整模式验证、每次 GET 请求都使用 `Object.fromEntries()` 转换请求头。这种架构能够工作，但在高并发场景下表现得不尽如人意。 ## 第一阶段：用内存 Map 替换 SQLite 团队首先识别到的问题是一个被过度设计的 SQLite 查询引擎。原始设计将连接元数据展平为键值对并存储在内存 SQLite 数据库中，意图提供灵活的查询能力。然而实际访问模式始终只涉及 4 个字段：deployment ID、version、CPU 和 memory。每次匹配请求都会执行一个包含 JOIN、GROUP BY 和 HAVING COUNT(DISTINCT) 的相关子查询，而本质上这只是一次哈希表查找。 使用 `node --prof` 进行性能分析后确认，`getConnection` 方法占据了 31% 的总 CPU 时间。团队将其替换为复合键的 `Map>` 数据结构，键由 `deployment + version + cpu + memory` 组成，中间用空字符分隔。匹配操作从 SQL 查询的 O(n) 复杂度降级为 Map 查找的 O(1)。 这一轮优化的基准测试结果如下：吞吐量从 2,099 req/s 提升至 4,534 req/s，p50 延迟从 22.5ms 降至 10.1ms，p95 延迟从 29.1ms 降至 14.9ms，最大延迟从 619ms 降至 403ms。吞吐量提升了 2.2 倍，同时可以移除 Node.js 的 `--experimental-sqlite` 标志。 ## 第二阶段：迁移到 Bun.serve() 移除 SQLite 后，下一个性能瓶颈暴露出来：50% 以上的 CPU 时间消耗在 `node:http` 内部实现上，包括 writev、socket 管理和流处理。当服务需要维护数千个并发长轮询连接时，Node.js 的 HTTP 栈开销变得显著。 团队添加了 Bun 入口点，使用 `Bun.serve()` 及其原生路由 API。由于在 SQLite 移除阶段已经将连接管理器设计为传输无关，这一迁移主要是接线工作。基准测试在 500 个控制器和 50 个并发 supervisor 请求的条件下进行，结果显示吞吐量从 4,434 req/s 提升至 9,434 req/s，p50 延迟从 10.1ms 降至 4.5ms，p95 延迟从 14.9ms 降至 7.4ms，最大延迟从 403ms 大幅降至 22ms。再次实现了翻倍的性能提升。 ## 第三阶段：分析并优化热路径 Bun 开箱即用就比 Node.js 快，但团队并未停止优化。利用 Bun 的 `--cpu-prof-md` 标志输出 Markdown 格式的 CPU 分析报告，可以直接用文本编辑器查看而无需额外工具。分析结果揭示了三个明确的热点。 第一个热点是 Zod 验证，每次 POST 请求都执行完整的 `DequeuedMessage.safeParse()`，占总 CPU 的 22%。由于这是内部服务间流量，控制器已经验证过完整模式，团队将其替换为最小化的字段存在性检查。第二个热点是请求头转换，每次 GET 请求都调用 `Object.fromEntries(req.headers.entries())` 然后读取单个字段，占 10.5% 的 CPU，替换为直接的 `req.headers.get()` 调用。第三个热点是调试日志，即使在过滤级别下也在序列化日志参数之前进行检查，占 8.6% 的 CPU。这三项修复在相同负载下将 CPU 使用量降低了约 40%。 ## 第四阶段：编译为独立二进制 最后一步是利用 Bun 的 `bun build --compile` 功能生成单个自包含可执行文件。编译后的二进制文件无需运行时环境，无需 `node_modules`，容器镜像中只需包含二进制文件和一个 CA 证书包。 编译后的性能对比显示：吞吐量相比解释执行提升 14%，p95 延迟降低 24%，镜像大小从约 120MB（bun + node_modules）缩减至约 68MB。团队还测试了 `--bytecode` 选项（JSC 字节码预编译），发现它实际上损害了稳态性能。字节码有助于冷启动场景（CLI 工具、无服务器函数），但对于 JSC JIT 已经预热的长运行服务器，更大的二进制文件和额外的内存映射开销反而导致性能下降。 ## 隐藏的陷阱：Bun 内存泄漏 部署到生产环境后，CPU 确实下降了，但 RSS（常驻内存）却快速攀升。监控图表显示 Node.js 稳定在 192 MiB，而 Bun 攀升至 250 MiB。团队发现了一个在 Bun HTTP 模型中特有的内存泄漏。 每个 GET `/warm-start` 请求都返回一个 Bun 持有的 `Promise`，有三条解决路径：被匹配（发送 payload 后解决）、超时（65 秒后发送 408）、客户端断开（pod 死亡或网络抖动触发 abort 事件）。前两条路径正常，但第三条导致了泄漏。 当客户端断开时，团队的 abort 处理器调用 `removeConnection()` 清理连接管理器，但从未解决挂起的 `Promise`。在 Node.js 的 Fastify 或 Express 中这不是问题——服务器将响应状态绑定到 socket，当 socket 死亡时无论是否调用 `res.end()` 都会被清理。但在 Bun 中，`fetch` 处理器的契约不同，每个 `Promise` 必须被 settled，Bun 会保留内部请求状态直到 promise 被解决或拒绝。如果永不解决，状态永远留在内存中。每个泄漏的连接约 500-2000 字节，每小时数百次断开累积下来相当可观。 修复方法是一行代码：在 abort 事件中向已断开的客户端发送 499 状态码。499 是 Nginx 的「客户端关闭请求」状态码，客户端永远不会看到它（他们已经断开），但这允许 Bun 释放请求上下文。修复后 RSS 从 250 MiB 降至 85 MiB 并保持稳定。 值得注意的是，团队此前已经将 `idleTimeout` 从 Bun 默认的 10 秒调整为 120 秒，因为 10 秒的默认值会过早终止长轮询连接。这减少了连接抖动，从而减缓了泄漏速度，但并未根除问题。修复泄漏后，CPU 上升了约 5%——这是正确清理连接的代价，此前这些连接在后台泄漏。 ## 完整性能对比 | 指标 | Node.js + SQLite | Node.js + Map | Bun（解释执行） | Bun（编译） | |------|------------------|---------------|-----------------|-------------| | 吞吐量 | 2,099 req/s | 4,534 req/s | 9,434 req/s | ~10,700 req/s | | p50 延迟 | 22.5ms | 10.1ms | 4.5ms | ~3.9ms | | p95 延迟 | 29.1ms | 14.9ms | 7.4ms | ~5.6ms | | 最大延迟 | 619ms | 403ms | 22ms | ~17ms | | 镜像大小 | ~180MB | ~180MB | ~120MB | ~68MB | 最终实现了 5 倍吞吐量提升、28 倍更好的最大延迟、容器镜像从 180MB 缩减至 68MB。生产环境的实际表现甚至优于本地基准测试——Node.js 下的 CPU 波动剧烈，在负载下几乎翻倍，而 Bun 保持稳定；Node.js 的事件循环延迟飙升至 40-80ms，而 Bun 几乎为零。 ## 迁移要点总结 对于考虑从 Node.js 迁移到 Bun 的团队，Trigger.dev 的经验提供了几个关键教训。首先，始终在优化前进行性能分析，SQLite 替换在事后看来一目了然，但只有通过性能分析才能发现它。其次，Bun 的 HTTP 模型与 Node.js 存在根本差异——响应生命周期绑定到 promise 而非 socket，如果要迁移长轮询或流式端点，必须考虑每条代码路径是否正确解决了 `Promise`。第三，`bun build --compile` 可以在零代码改动的情况下带来 14% 的吞吐量和 24% 的 p95 延迟改善。第四，修复内存泄漏后 CPU 上升约 5%，这是正确清理连接的必要代价。最后，每个阶段都要进行基准测试，使用相同的负载测试配置，否则无法判断哪些改动真正有效。 Trigger.dev 将完整的调试经验封装为一个可复用的 Agent Skill，涵盖 Bun 内存泄漏排查、堆分析、JSC 指标、AbortSignal 生命周期和 prom-client 兼容性等问题。对于在生产环境中使用 Bun 的开发者，这些细节往往比基准数字更有价值。 --- **资料来源**：本文核心数据与案例来自 Trigger.dev 官方博客《Why we replaced Node.js with Bun for 5x throughput》（2026年3月27日）。 ## 同分类近期文章 ### [好奇号火星车遍历可视化引擎：Web 端地形渲染与坐标映射实战](/posts/2026/04/09/curiosity-rover-traverse-visualization/) - 日期: 2026-04-09T02:50:12+08:00 - 分类: [systems](/categories/systems/) - 摘要: 基于好奇号2012年至今的原始Telemetry数据，解析交互式火星地形遍历可视化引擎的坐标转换、地形加载与交互控制技术实现。 ### [卡尔曼滤波器雷达状态估计：预测与更新的数学详解](/posts/2026/04/09/kalman-filter-radar-state-estimation/) - 日期: 2026-04-09T02:25:29+08:00 - 分类: [systems](/categories/systems/) - 摘要: 通过一维雷达跟踪飞机的实例，详细剖析卡尔曼滤波器的状态预测与测量更新数学过程，掌握传感器融合中的最优估计方法。 ### [数字存算一体架构加速NFA评估：1.27 fJ_B_transition 的硬件设计解析](/posts/2026/04/09/digital-cim-architecture-nfa-evaluation/) - 日期: 2026-04-09T02:02:48+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析GLVLSI 2025论文中的数字存算一体架构如何以1.27 fJ/B/transition的超低能耗加速非确定有限状态机评估，并给出工程落地的关键参数与监控要点。 ### [Darwin内核移植Wii硬件：PowerPC架构适配与驱动开发实战](/posts/2026/04/09/darwin-wii-kernel-porting/) - 日期: 2026-04-09T00:50:44+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析将macOS Darwin内核移植到Nintendo Wii的技术挑战，涵盖PowerPC 750CL适配、自定义引导加载器编写及IOKit驱动兼容性实现。 ### [Go-Bt 极简行为树库设计解析：节点组合、状态机与游戏 AI 工程实践](/posts/2026/04/09/go-bt-behavior-trees-minimalist-design/) - 日期: 2026-04-09T00:03:02+08:00 - 分类: [systems](/categories/systems/) - 摘要: 深入解析 go-bt 库的四大核心设计原则，探讨行为树与状态机在游戏 AI 中的工程化选择。