工作流系统改造方案演讲稿

开场白

大家好！今天我要跟大家分享我们 项目中一个非常重要的技术改造方案。

作为我们从 xx 项目 fork 过来进行二次开发的核心系统，工作流引擎是整个平台的"心脏"。但是随着业务的快速发展，我们发现现有的工作流系统存在一些严重的性能瓶颈和用户体验问题。

今天我将从四个方面来详细介绍我们的改造方案：

1. 当前系统的痛点分析
2. 核心技术解决方案
3. 具体实施计划
4. 预期效果和价值

一、当前系统痛点分析

让我们先看看现在的工作流执行机制

从这张图可以看出，我们目前面临的核心问题：

1. 并发能力严重不足

现在的系统采用单进程递归执行模式。什么概念呢？

• 同一时间只能处理 1-5 个工作流
• 所有用户共享同一个 Node.js 进程
• 一个复杂工作流执行时，其他用户只能排队等待

举个例子：如果用户A启动了一个需要10分钟的复杂工作流，那么用户B、C、D都必须等待A执行完成才能开始。这在用户量大的时候是完全不可接受的。

2. 可靠性问题

• 进程重启 = 所有执行丢失：一旦服务器重启或崩溃，所有正在执行的工作流都会丢失
• 无状态恢复：没有持久化的执行状态，无法从故障中恢复
• 深度限制死板：硬编码20层限制，限制了复杂业务场景

3. 用户体验差

最让用户抓狂的是断线问题：

• 网络稍微不稳定，整个执行就中断了
• 用户不小心刷新页面，一切从头开始
• 长时间的工作流执行，用户不敢离开页面

我们经常收到用户反馈："我的工作流跑了半个小时，结果网络断了一下就全没了，又要重新开始..."

二、核心技术解决方案

针对这些痛点，我们设计了一套全新的架构方案。

方案一：工作流引擎独立化 + BullMQ 异步执行

让我们看看改造后的架构：

这个方案是如何解决并发问题的？

1. 任务队列解耦

// 原来：直接执行
function submitWorkflow(data) {
  return dispatchWorkFlow(data); // 阻塞式执行
}

// 改造后：异步任务
async function submitWorkflow(data) {
  const job = await workflowQueue.add('execute-workflow', {
    workflowId: data.id,
    sessionId: generateSessionId(),
    context: data
  });
  return { sessionId: job.data.sessionId };
}

用户提交后立即返回，不再等待执行完成。

2. 多Worker并行处理

我们可以启动多个Worker进程：

• 每个Worker可以同时处理多个任务
• 根据服务器配置，轻松支持几十到几百个并发
• Worker之间完全独立，一个崩溃不影响其他

3. 智能任务调度

方案二：断线重连机制

这是我们技术方案中最有挑战性的部分。

核心设计思路：事件序列号 + Redis缓存

具体如何实现？

1. 事件持久化存储

每个工作流执行过程中的所有事件都存储在Redis中：

interface SSEEvent {
  id: string;           // 递增序列号 "1", "2", "3"...
  event: string;        // 事件类型 "nodeComplete", "progress"
  data: any;           // 具体数据
  timestamp: number;    // 时间戳
  sessionId: string;    // 会话标识
}

// Redis存储结构
// Key: session:{sessionId}:events
// Type: Sorted Set (按序列号排序)
// 1 -> {"id":"1", "event":"start", "data":{...}}
// 2 -> {"id":"2", "event":"nodeComplete", "data":{...}}
// 3 -> {"id":"3", "event":"progress", "data":{...}}

2. 前端重连逻辑

class ReconnectableEventSource {
  connect() {
    this.eventSource = new EventSource(
      `/api/workflow/stream?sessionId=${this.sessionId}&lastEventId=${this.lastEventId}`
    );
    
    this.eventSource.onmessage = (event) => {
      this.lastEventId = event.lastEventId; // 更新最后接收的事件ID
      this.handleMessage(event);
    };
    
    this.eventSource.onerror = () => {
      // 指数退避重连：1秒、2秒、4秒、8秒...最多30秒
      const delay = Math.min(1000 * Math.pow(2, this.attempts), 30000);
      setTimeout(() => this.connect(), delay);
    };
  }
}

3. 支持的断线场景

我们的方案支持以下所有断线场景：

方案三：定时任务系统

这是业务团队强烈要求的功能。让我们看看整体架构：

数据库表设计

我们设计了两个核心表：

UserScheduledTask表 - 任务配置

• 支持Cron表达式（每周一到五上午9点执行）
• 支持间隔执行（每隔30分钟执行一次）
• 支持单次执行（指定时间执行一次）
• 完整的重试和超时配置

TaskExecutionHistory表 - 执行历史

• 每次执行都有详细记录
• 支持性能分析和问题排查
• 提供统计数据用于监控面板

三、实施计划

我们计划分四个阶段来实施这个改造：

为什么要分阶段？

1. 降低风险：每个阶段都有明确的可验证目标
2. 并行开发：前端和后端可以同时开工
3. 渐进切换：新旧系统可以平滑过渡

如何保证现有系统稳定？

我们采用双轨制方案：

通过配置开关，我们可以：

• 先让10%的流量走新系统测试
• 逐步提升到50%、80%、100%
• 发现问题可以立即回滚

四、预期效果和价值

性能指标对比

让我们看看改造前后的具体数据对比：

具体提升数据

用户体验提升

断线重连效果演示：

业务价值

1. 用户满意度大幅提升

• 不再担心执行中断
• 支持复杂长时间工作流
• 页面刷新不影响使用

2. 运营效率显著改善

• 支持定时自动执行
• 减少人工干预
• 提供详细的执行统计

3. 系统扩展能力增强

• 支持更大用户规模
• 横向扩展能力
• 为未来业务增长打下基础

4. 维护成本降低

• 完善的监控体系
• 自动故障恢复
• 详细的日志和追踪

结语

这次工作流系统改造是我们项目发展的一个重要里程碑。

我们要解决的不仅仅是技术问题，更重要的是：

• 让用户能够安心使用我们的产品
• 为业务的快速发展提供坚实的技术基础
• 建立可持续发展的技术架构

这个方案的特点：

• ✅ 技术成熟：BullMQ、Redis都是经过大规模验证的技术
• ✅ 风险可控：分阶段实施，支持随时回滚
• ✅ 效果显著：并发能力提升100倍，可用性接近99.9%
• ✅ 用户友好：零感知断线重连，完全改善用户体验

我相信通过这次改造，我们的xxx 将会成为一个真正企业级的、可靠的智能工作流平台。

谢谢大家！

Q&A环节

常见问题预案：

Q: 改造的技术风险如何控制？ A: 我们采用分阶段实施、双轨制部署的策略，每个阶段都有明确的回滚方案。

Q: Redis故障会导致整个系统不可用吗？
A: Redis配置了主从和哨兵模式保证高可用，同时有降级机制，最坏情况下可以回退到原有模式。

Q: 新系统的学习成本高吗？ A: 对用户来说完全透明，使用方式没有任何变化。对开发团队我们会提供完整的培训和文档。

Q: 什么时候可以看到效果？ A: 按照计划，7周后就可以完整上线。实际上第一阶段完成后就能看到明显的并发能力提升。