Node.js多进程与Worker线程部署小应用差异咨询

先明确对比的两个方案形态：

• 独立服务方案：每个小型应用对应一个独立Node.js进程，托管为systemd服务，可通过systemctl restart le-service-xxx单独管控
• Worker线程方案：单Node.js入口进程启动300+ Worker线程，每个Worker承载一个应用的业务逻辑

资源消耗对比 #

内存开销 #

独立服务方案的内存基线开销远高于Worker方案：

• 每个独立Node.js进程启动时，需要单独加载V8运行时、Node.js核心模块、初始化独立堆空间，单进程基线内存普遍在30MB_{50MB区间，300个进程仅基线内存就要占用9GB}15GB，还未计算业务逻辑本身的内存占用。
• Worker线程虽然持有独立V8 Isolate、独立事件循环，但同进程下的Worker会共享进程级的代码段、Node.js核心模块编译缓存、内置常量，单个Worker的基线内存仅为5MB_{10MB，300个Worker的基线总开销在1.5GB}3GB区间，相比独立进程方案可节省70%左右的基线内存。

CPU开销 #

业务逻辑本身的CPU消耗两种方案基本持平，但调度开销差异明显：

• 独立进程方案中，Linux调度进程时需要切换地址空间、页表，上下文切换成本比线程高30%左右，300个进程同时被唤醒执行任务时，这部分额外开销会更明显。
• Worker属于同进程下的线程，上下文切换仅需保存寄存器、栈信息，调度成本更低，在单轮任务IO占比超95%的轮询类场景下，整体CPU利用率会比独立进程方案高10%~20%。

注意：Worker方案的故障影响面远大于独立进程。如果某个Worker触发V8致命错误（比如原生模块bug、内存越界），整个Node.js进程会直接崩溃，所有300个业务都会同时中断；独立进程方案下仅故障服务本身退出，其余服务不受影响。

Worker线程的资源共享能力 #

很多人对Worker的资源隔离有误解：Worker的JS堆是完全隔离的，不能直接传递JS堆内的对象引用，但进程级的操作系统资源是完全可以共享的：

• 数据库连接：不能直接把主进程中创建的数据库连接JS对象传给Worker使用，但可以通过两种方式实现连接复用：
  1. 主进程维护统一数据库连接池，Worker通过进程间消息向主进程发起数据库操作请求，复用进程持有的TCP连接句柄（TCP连接由操作系统管理，同进程所有线程均可访问）
  2. 使用支持SharedArrayBuffer跨线程调度的数据库驱动连接池，直接在Worker侧从共享连接池拿连接使用
     按照给出的业务逻辑，每个应用单轮循环有20s左右在做数据库操作，如果用独立进程方案，每个进程至少维护1_{2个数据库连接，300个进程很容易打满数据库的最大连接数限制；而Worker方案下统一做连接池调度，仅需20}30个数据库连接即可承载所有业务流量，数据库侧压力会大幅降低。
• 其他资源：日志文件句柄、全局配置、公共缓存数据都可以在主进程加载后，通过共享内存或消息传递给所有Worker复用，不需要每个业务单元重复加载、重复占用资源。

对应业务场景的实际运行注意点 #

提到的业务逻辑是典型的IO密集型常驻轮询任务：

while(process.exitCode == null) {
    // query the db, avg: 15s
    // do some checking (most involve other queries): avg 5s
    // maybe do some inserts or updates: avg < 1s
    // sleep, avg 30s
}

针对这个场景有两个明确结论：

1. 不需要担心“频繁新建V8实例”的问题：不管是独立进程还是Worker方案，都是启动一次后长期常驻运行，V8实例仅在服务启动时创建一次，这部分一次性开销分摊到数月的运行周期里几乎可以忽略。
2. 不要忽略Worker方案的隐性运维成本：除了已知的单业务单元管控开发成本，实际运行中还要补全很多能力：比如Worker内存泄漏时的单独重启、故障Worker的自动拉起、业务日志的拆分隔离、单Worker的资源限流——这些能力在独立进程方案下是systemd、cgroup原生提供的，不需要额外写代码实现。比如独立进程方案下可以直接给每个服务配置MemoryLimit、CPUQuota，防止某个业务死循环占满整机资源；而Worker方案下所有线程共享进程的资源配额，单个Worker的异常很容易拖垮所有业务。

简单选型参考 #

• 如果300个应用优先级不高、允许批量重启、数据库连接数资源紧张，选Worker方案资源利用率更高，但需要自行开发完善Worker管控、异常隔离逻辑
• 如果业务稳定性要求高、不想投入额外开发做运维管控能力，选独立进程方案更稳妥，只需要提前预留足够内存，必要时增加数据库连接数上限或前置数据库代理即可

内容的提问来源于stack exchange，提问作者Lucas Steffen