实战设计 WhatsApp 营销系统：Java 业务层 + Node Baileys 协议层的双层架构

背景我们在开发一款外贸行业的获客与 CRM 系统其中 WhatsApp 营销中心需要管理大量 WhatsApp 账号的长连接、收发消息并与业务系统联动。本文复盘这套系统的架构设计与踩坑记录。一、需求与约束营销中心的核心能力多账号接入、收件箱统一会话、批量群发任务、与 CRM 联动客户建档与跟进记录。工程上的硬约束有三条WhatsApp 没有官方开放的个人号 API。协议层主流方案是基于 BaileysWebSocket 长连接逆向协议实现它只能跑在 Node.js 环境业务系统是 JavaSpring Boot 3.5 / JPA / MySQL团队主体技术栈与既有 CRM、权限、审计体系都在 JVM 生态凭证是敏感资产。会话凭证落盘必须加密且密钥不能出现在代码仓库与日志里。二、为什么是双层架构而不是单进程第一直觉是把 Baileys 嵌进 Spring Boot 的 JVM 进程里比如走 GraalVM 或 sidecar但我们最终选择了独立 Node 协议层 Java 业务层的双层设计┌─────────────┐ HTTP 回调 ┌──────────────────┐ │ wa-worker │ ─────────────▶ │ viniray-server │ │ (Node 20) │ ◀───────────── │ (Spring Boot) │ │ Baileys │ REST 下发指令 │ CRM / 任务调度 │ │ 连接池 │ │ MySQL / 收件箱 │ └─────────────┘ └──────────────────┘ 每账号一个 socket 业务与数据单点收敛 凭证加密落盘 凭证密钥只在内存理由生命周期不同。WhatsApp 长连接需要 7×24 常驻、断线自动重连而 Java 侧需要频繁发版重启。把协议层拆出去业务发版不再踢掉所有会话故障域隔离。Baileys 协议层遇到协议变更、封号、风控异常的概率远高于业务层独立进程可以单独重启、单独扩容多 worker 实例分片账号技术栈各得其所。连接管理、消息序列化用 Node 天然顺手事务、报表、权限审计留在 Java。代价是多一跳 HTTP 和一套 worker 的运维对一个内部系统完全可接受。三、关键设计点1. 连接池与会话凭证加密每个 WhatsApp 账号对应 worker 内的一个 session 实例。凭证creds序列化后 AES-256-GCM 加密落盘加密密钥从环境变量注入SESSION_ENCRYPTION_KEY进程重启后解密恢复会话避免重新扫码。// worker 侧会话管理示意constsockmakeWASocket({auth:state,...options});sock.ev.on(creds.update,async(){awaitsaveEncryptedCreds(sessionId,state.creds);// AES-GCM 后写盘});sock.ev.on(connection.update,({connection,lastDisconnect}){if(connectionclose){constcodelastDisconnect?.error?.output?.statusCode;if(code!DisconnectReason.loggedOut)reconnect(sessionId);// 非登出均重连}});关键经验loggedOut 与其他 close 原因必须区分处理。前者凭证已失效重连无意义还会反复触发风控其余情况超时、restartRequired指数退避重连即可。2. 指令下发与回调上报的双通道Java → worker 用同步 REST发消息、查状态、踢会话worker → Java 用回调 URL 上报收到的消息与连接状态。两条通道都要带服务间鉴权 token并且回调要做幂等消息 ID 去重否则重连风暴时会产生重复工单。// Java 侧回调入口示意PostMapping(/internal/wa/callback)publicResponseEntityVoidonCallback(RequestBodyWorkerEventevent,RequestHeader(X-Worker-Token)Stringtoken){if(!workerTokenVerifier.verify(token)){returnResponseEntity.status(401).build();}eventDeduper.submit(event,this::handle);// 按消息 ID 幂等returnResponseEntity.accepted().build();}3. 限速营销系统最重要的参数是「每分钟发几条」群发不是越快越好。单账号高频发送是封号最强信号之一我们把它做成了核心配置SEND_RATE_PER_MIN由 worker 层令牌桶统一限速任务队列在 Java 侧排期。上线前踩过的坑限速做在 Java 侧并发调用上但 worker 重启后队列状态丢失导致瞬间并发——限流必须放在离 socket 最近的那一层。4. 与 CRM 的联动语义「已联系」的判定必须实时查业务库该号码是否已存在于 CRM 联系人且有跟进记录而不是在协议层冗余存储。协议层保持无状态语义只管连接与收发去重、状态、归属全部收敛到 Java 侧单点避免双写一致性问题。四、风控与合规最后强调两点比架构更重要不碰灰产。只服务企业自己的客户触达场景提供退出机制用户回复拒绝后停止发送参数保守。日发送量、账号预热期、内容变体这些运营参数比任何代码优化都更决定系统寿命。五、小结决策选择核心原因协议层Node Baileys 独立进程长连接生命周期与业务发版解耦业务层Spring Boot 3.5事务/权限/审计单点收敛凭证AES-GCM 加密落盘 环境变量密钥进程重启不丢会话密钥不进仓库限速worker 层令牌桶离 socket 最近重启不失效联动语义Java 侧实时判定协议层无状态避免双写一致性这套架构目前支撑着依零科技出品的外贸全链路系统 Viniray 的 WhatsApp 营销中心稳定运行。如果你也在做类似的即时通讯自动化系统欢迎评论区交流架构取舍。