为什么我把核心服务从 Node 迁移到 Go：真实数据对比

背景：为什么要迁移

我们的投资平台核心 API 服务最初用 Node.js（Express）构建，在业务早期运行良好。但随着并发量上升和数据计算量增大，几个问题开始变得明显——

• CPU 密集型计算（投资组合估值）会阻塞事件循环
• 内存占用随请求数线性增长，GC Pause 周期性出现
• P99 延迟在高峰期飙升至 800ms+
• 多核利用率低，8 核服务器实际 CPU 使用率难超 40%

这并不是说 Node.js 不好。对于 I/O 密集型服务，Node 的事件循环模型非常高效。问题在于我们的场景是 CPU + I/O 混合型，而这恰好是 Node 的软肋。

技术选型：为什么是 Go

我们考虑过 Rust、Python（asyncio）和 Go。最终选择 Go 的原因很实际：

• 学习曲线相对平缓，团队一周内能写出生产级代码
• 标准库强大，不需要依赖大量第三方包
• goroutine 的并发模型非常适合我们的混合型场景
• 编译产物是单一二进制文件，部署极其简单

迁移策略：不停服渐进式切流

第一阶段：Strangler Fig 模式

我们在 Node 服务前加了一层 Nginx，按路由逐步将流量引导到 Go 服务。先从读多写少、逻辑相对简单的查询接口开始，稳定后再切换计算密集型接口。

# 按路由渐进切流配置
upstream node_backend {
    server 127.0.0.1:3000;
}

upstream go_backend {
    server 127.0.0.1:8080;
}

location /api/v2/portfolio {
    # 计算密集型接口 → Go 服务
    proxy_pass http://go_backend;
}

location /api/ {
    # 其余接口暂时保留 Node
    proxy_pass http://node_backend;
}

第二阶段：核心逻辑重写

投资组合估值是最核心也最复杂的计算逻辑，涉及大量并发数据库查询和数学运算。Go 的 goroutine + channel 让并发编排变得非常清晰：

func ValuatePortfolio(ctx context.Context, ids []string) ([]Result, error) {
    var wg sync.WaitGroup
    results := make(chan Result, len(ids))
    errs    := make(chan error, len(ids))

    for _, id := range ids {
        wg.Add(1)
        go func(assetID string) {
            defer wg.Done()
            r, err := calcSingleAsset(ctx, assetID)
            if err != nil {
                errs <- err
                return
            }
            results <- r
        }(id)
    }

    wg.Wait()
    close(results)
    // collect & return ...
}

结果：真实数据

完整切流并稳定运行 30 天后，我们对比了同等流量下的核心指标：

这些数字来自我们特定的业务场景，不代表所有场景。在 I/O 密集型、纯代理转发等场景下，Node.js 未必比 Go 差。

踩过的坑

• Go 的 database/sql 连接池默认 MaxOpenConns 是无限制的，上线后差点打爆数据库
• 错误处理从 try/catch 转变为显式 if err != nil 需要强制适应，但长期来看更清晰
• 日志和链路追踪需要重新集成，原本 Node 的中间件生态不能直接复用
• 时区处理：time.Time 默认不携带时区信息，需要显式指定 time.UTC

结论

迁移值得吗？对我们来说，是的。但前提是你清楚自己的瓶颈在哪里。如果你的服务主要是 I/O 等待（数据库、外部 API），Node.js 的事件循环完全够用，切 Go 的收益会非常有限。

如果你和我们一样，计算逻辑越来越重、并发度要求越来越高，Go 的确是一个值得认真考虑的选项。学习成本比想象中低，而带来的性能空间非常可观。