n8n 生产落地案例

生产落地案例

案例一：内容平台把「多系统发布」收敛成一条 workflow

业务背景：一个内容团队每天产出十几篇稿件，发布需要经过编辑审核、写入 CMS、转成结构化数据推给搜索、再把链接同步到社群。原来靠人工在四五个后台之间复制粘贴，一篇稿件平均要花十几分钟，且经常漏步骤。

怎么用：把 CMS 的审核通过事件作为入口。用一个 Webhook 触发流程接收 CMS 的回调，随后并行展开三条支线：一条调用 CMS 接口把状态置为已发布，一条调搜索服务的索引接口提交 URL，一条把标题和链接组装成消息推到社群机器人。三条支线用 Merge 节点汇合，最后写一条发布日志进内部数据库。

关键配置：入口 Webhook 走生产地址并在 CMS 侧配置了重试；HTTP Request 节点全部启用 Retry On Fail 并设置退避间隔，避免搜索服务偶发超时时直接失败；凭据统一放在 credential 里，流程 JSON 导出进 git 只留结构不含密钥；配置了一个错误工作流，任何一条支线失败都会往运维群发一条包含 $execution.id 的消息，点开就能定位。

效果：人工环节从五个后台操作压缩成「在 CMS 点发布」这一步，漏步骤的情况基本消失，出问题时也不需要翻日志，直接在错误通知里拿到执行链接。

踩过的坑与解决办法：第一，发布失败重跑时会出现重复提交，搜索服务收到两次相同 URL。解决办法是在流程开头按稿件 ID 做一次幂等检查，已处理过的直接跳过。第二，社群消息偶尔重复推送，原因是重试机制把整个 HTTP 节点重跑了一遍。解决办法是把发消息这一步的失败策略改成不重试，失败后交给错误工作流人工处理。第三，早期用单容器加 SQLite，执行记录越积越多，容器磁盘告警。解决办法是切到 PostgreSQL 并开启执行记录定期清理。

案例二：自托管 queue mode 支撑批量数据同步

业务背景：团队需要每天凌晨把 ERP 里变更过的客户数据同步到 CRM，同时把变更摘要邮件发给对应负责人。数据量在数万条量级，逐条处理耗时长，单进程模式下经常和白天的人工调试流程互相抢占资源。

怎么用：用 Schedule Trigger 在凌晨定时启动，先用 HTTP Request 拉取变更列表，再用 Split Out 把列表拆成逐条 item，接着用 Loop Over Items 分批（每批几十条）调用 CRM 接口，避免一次性打爆对端限流。同步完成后用 Aggregate 汇总结果，用 IF 节点分流：全部成功发一封汇总邮件，存在失败项则把失败明细一并发出。

关键配置：容器切到 queue mode，主进程只保留编辑器和调度，worker 用 worker --concurrency 控制并发，webhook 由独立角色进程处理，保证白天有人手工触发时不受凌晨批量任务影响；Redis 与 PostgreSQL 的数据卷单独挂载并做定时备份；N8N_ENCRYPTION_KEY 通过环境变量注入，三个角色的值完全一致；所有实例时区统一为 Asia/Shanghai，避免定时触发在错误的时刻启动。

效果：批量同步不再影响白天的人工调试，长任务的执行记录可以在编辑器里逐条回放，失败批次能单独重跑而不必整批重来。

踩过的坑与解决办法：第一，最初只加了 worker 容器但忘了给 webhook 单独进程，webhook 响应偶尔很慢，划分角色后恢复正常。第二，某个 worker 重启后再没接上任务，排查发现是 Redis 密码只写进了主进程的环境变量，补齐所有角色后解决。第三，循环节点里逐条调用造成请求量过大，被对端限流返回 429，改成小批量调用并加上失败重试后稳定下来。第四，早期备份只备了 PostgreSQL 没备工作流 JSON，做迁移演练时才发现流程定义不在数据库备份的预期范围内，随后把 CLI 导出加了进来。