从状态机到流程编排引擎：质检系统演进之路

• 1 引言：流程编排的现实需求
• 1.1 什么是质检系统？
• 1.2 质检流程日益复杂的挑战
• 2 第一阶段：基于状态机的流程控制实践
• 2.1 选用状态机的背景
• 2.2 状态机模型设计
• 2.3 示例状态流转（简化）
• 2.4 实现方式
• 2.5 状态机的优点
• 2.6 面临的挑战
• 2.7 小结
• 3 第二阶段：工作流引擎的探索与评估
• 3.1 主流引擎能力对比
• 3.2 引擎能力基本满足，但迁移与性能问题突出
• 3.3 最终选择：基于工作流思想，自研流程编排引擎
• 4 第三阶段：结合工作流思想的自研流程编排引擎
• 4.1 自研流程编排引擎的核心设计目标
• 4.2 引擎核心模块设计
• 5 演进效果与落地实践
• 5.1 节点配置
• 5.2 线体配置（简化）
• 6 未来展望

1 引言：流程编排的现实需求

1.1 什么是质检系统？

质检系统是针对用户和平台交易的手机、3C 数码等物品，通过专业流程进行全面检测并输出质检报告的系统。它是履约体系中的关键一环，核心目标是解决用户在买卖过程中的信任问题，同时为平台的质保、售后处理等提供客观、可依赖的判责依据。

1.2 质检流程日益复杂的挑战

质检流程不是一成不变的，它受到以下因素影响：

• 商品品类不同，要执行不同的质检节点
• 站点不同，流程分支不一致
• 新业务模式上线，质检链路频繁调整

比如：一个“C2B”的质检流程可能是“收货 →  质检  → 上架审核”，而一个“B2C”流程则是“录入 → 质检 →   拍照 →  上架审核”。

原有的流程控制方式难以支撑复杂且频繁变更的业务场景。“配置驱动、可视化流程、快速响应变更”成为我们架构演进的核心诉求，也推动我们从状态机迈向流程编排。

2 第一阶段：基于状态机的流程控制实践

在质检系统早期，我们选择使用状态机（FSM, Finite State Machine）模型来驱动整个流程的控制。这是当时非常自然的架构选择，既满足了流程的基本控制逻辑，也能较好地与业务事件做绑定，且实现成本可控。

2.1 选用状态机的背景

初期的质检业务流程相对简单：

录入 → 质检 →   抽检 →  上架审核

每一步都有明确的起止条件与状态变化，非常适合用状态机建模。每个任务都可抽象成一个“流程实例”，而流程实例的每个阶段则用“状态”表示。

2.2 状态机模型设计

我们的状态机核心逻辑包括：

• 状态（State）：表示流程当前所处阶段，例如 已录入、已质检、已抽检、已上架审核 等；
• 事件（Event）：外部触发行为，例如 录入完成、质检完成、上架审核完成；
• 转移（Transition）：由状态 + 事件决定的流转逻辑；
• 动作（Action）：状态切换时需要执行的具体业务逻辑，如更新数据库、推送消息等。

2.3 示例状态流转（简化）

我们为每种质检任务维护一套状态定义，通过状态图驱动业务流程。

2.4 实现方式

系统内部基于cola-component-statemachine封装了一套轻量状态机框架，开发只需：

• 配置状态枚举 + 转移规则；
• 注册状态流转监听器，绑定处理逻辑；
• 通过 fireEvent 触发流转；
• 状态流转统一落库，支持流程跟踪。

例如：

stateMachine.fireEvent(context.getProcessState(), context.getEvent(), context);

2.5 状态机的优点

状态机模型在早期阶段给我们带来了不少收益：

✅ 流程清晰：状态之间转换规则明确，易于开发理解和维护；✅ 执行稳定：逻辑基于事件驱动，天然适合异步处理和失败重试；✅ 开发效率高：只需要配置状态与事件即可快速上线新流程；✅ 状态管理方便：支持追踪流程执行轨迹，方便排查问题。

2.6 面临的挑战

但随着业务复杂度的提升，状态机模型逐渐暴露出以下问题：

1）流程分支能力弱，流程控制混乱

• 某些流程节点根据不同条件需要进入不同分支（如：是否抽检），但状态机天生不擅长处理条件流；
• 为实现分支流转，我们建立了流转单概念，执行完成节点后，调用单独的功能去计算下一个要执行节点，建立对应的流转单；

• 由于流转单和状态机同时存在导致后续维护人员不清楚使用什么控制对应的功能，导致流程控制混乱

2）并行流程支持能力差

• 质检业务中存在多个任务并行处理的场景；
• 状态机模型天然是线性流转模型，缺乏原生的并发节点、同步等待、汇聚等能力；
• 要实现并发处理，需要额外引入中间状态和异步控制逻辑，极易导致代码复杂化、状态混乱。

3）产品运营无法自主控制流程

• 所有流程变更都需要开发参与；
• 产品无法“可视化配置流程”，流程灵活性严重受限。

2.7 小结

状态机作为质检流程的第一个技术实现形态，帮助我们度过了流程初期“可控但固定”的阶段，为质检系统的稳定运行打下了良好基础。但在面对 复杂性提升、业务高频调整 的现实挑战时，它逐渐难以胜任。

这一阶段的经验与教训，推动我们开始思考：

有没有一种更灵活、可配置、对业务友好的流程控制方式？

这也引出了我们探索工作流引擎的下一阶段。

3 第二阶段：工作流引擎的探索与评估

随着质检业务复杂度不断提升，原本基于状态机的流程控制架构逐渐难以满足需求，暴露出流程分支弱、并行处理能力差、流程配置依赖开发等问题。在这种背景下，我们开始考虑是否引入成熟的工作流引擎来承接未来的流程管理能力。

工作流引擎相比状态机具有更强的流程建模能力，天生支持条件判断、并发处理、任务分派、流程追踪等能力。为了选出最适合我们业务场景的引擎，我们调研并评估了以下几款主流工作流引擎，包括 Flowable、Camunda、Activiti、Zeebe、Netflix Conductor 等。

3.1 主流引擎能力对比

3.2 引擎能力基本满足，但迁移与性能问题突出

经过深入业务流程建模验证后，我们发现这些引擎的建模能力、并行支持、条件流转处理等都能较好满足当前质检流程的核心诉求，在功能层面具有较高的可用性。

但是在设计过程中，我们也遇到了一些关键挑战：

• 迁移成本高：将现有流程与质检系统完全迁移至工作流引擎意味着流程表达需要重新建模、任务系统需要全面适配，风险与人力成本高；
• 性能表现不佳：引擎对高并发下的任务执行、事件响应等性能瓶颈难以规避；
• 黑盒感强：调试和排查难度大，且不易扩展复杂的业务规则。

3.3 最终选择：基于工作流思想，自研流程编排引擎

在充分评估上述优劣后，我们意识到：虽然现有开源工作流引擎“功能够用”，但并不适合我们。

因此，团队最终决定：借鉴成熟工作流引擎的核心思想（BPMN建模、执行流控制），结合我们质检业务对流程颗粒度控制、节点灵活配置、自定义扩展能力的诉求，自研一套轻量级流程编排引擎，更好地支撑复杂质检流程的灵活演进与运营驱动。

4 第三阶段：结合工作流思想的自研流程编排引擎

4.1 自研流程编排引擎的核心设计目标

我们自研流程编排引擎的目标不是重造一个 BPMN 引擎，而是结合自身业务需求，设计一套“既能建模流程逻辑，又能快速适配现有系统，简单易用”的引擎：

4.2 引擎核心模块设计

我们将整个流程编排引擎拆分为以下核心模块

4.2.1 流程建模模块

核心概念

• 节点模板流程中一个具体的作业环节原型，例如“质检”“抽检”“拍照”等。模板描述的是环节的业务语义和通用执行逻辑，可被不同流程复用。
• 节点基于节点模板实例化的流程环节。虽然同为“质检”节点，不同业务线可有差异化的配置，例如执行规则、质检标准、图片要求等。
• 节点配置绑定在节点上的具体规则，包括执行条件、输入输出参数、校验规则等。在节点执行时，这些配置会直接影响任务的处理方式。
• 连接线描述节点间可达的流转关系及条件。例如，从“质检”节点到“抽检”节点的路径可能要求质检结果为“待复检”。
• 流出规则决定流程是否进入下一个节点的条件判断，类似 BPMN 中的Sequence Flow 条件表达式。
• 网关用于处理流程中的分支、汇聚、并行等复杂逻辑。为降低配置复杂度，我们将网关能力直接集成到节点配置中，由节点自身决定流转策略。
• 线体流程的完整载体，由多个节点与连接线构成。一个线体即代表一个完整的质检作业流程模型。
• 作业单用于记录质检相关的基础信息（设备信息、检测类型、进度等），并标识该作业在流程线体中的当前位置。同时为质检人员提供可查询、可追溯的运营能力。
• 作业任务单节点执行的核心控制单元。当流程进入某节点时，会生成对应的作业任务单，用于驱动节点执行、记录执行结果、触发后续流转。

概念关系图

在流程模型设计完成后，我们进入了落地实现阶段。前端采用 AntV X6 框架，实现可视化流程编排与节点配置能力；所有配置数据均以 JSON 格式进行结构化存储，既方便前端渲染和交互，又便于后端解析与版本管理，为流程的灵活调整和快速迭代提供了坚实基础。

4.2.2 流程引擎调度器

在完成流程建模之后，进入流程调度阶段。流程调度是流程编排引擎的核心执行环节，我们将其拆分为四个步骤：

1. 查询作业单从存储中获取当前作业单，包含质检对象的基础信息与当前流程执行位置。
2. 加载流程节点与连接信息根据作业单关联的线体，获取当前节点及其相关的连接线定义。
3. 规则计算下一执行节点调用规则引擎，结合节点配置与业务上下文，计算流程的下一步目标节点（支持分支、并行等逻辑）。
4. 创建作业任务单为目标节点生成对应的作业任务单，作为后续执行调度与状态追踪的核心控制单元。

4.2.3 节点执行器机制

在生成具体的作业任务单后，系统即可进入节点执行阶段。节点执行过程可拆分为以下五个步骤：

1. 进入节点执行启动当前作业任务单对应的节点作业流程。
2. 加载节点配置根据作业任务单关联的节点 ID，获取该节点的详细配置与执行规则。
3. 规则驱动节点作业按照节点配置的规则与业务逻辑，执行质检、拍照、判责等具体作业操作。
4. 标记任务完成作业完成后，将对应的作业任务单状态更新为“已完成”，并记录执行结果。
5. 异步触发流程调度通过事件驱动或消息队列，异步通知流程引擎调度器，计算并执行下一步流程节点。

5 演进效果与落地实践

5.1 节点配置

这张图展示了单个流程节点的可视化配置界面，是运营和产品调整流程的核心入口。

• 作用：定义节点的执行逻辑、质检规则等。
• 意义：
• 过去这些规则需要开发写死在代码中，现在只需在页面上修改参数即可生效。
• 支持业务线差异化，比如不同站点的“质检”节点可以配置不同的质检标准或图片要求。
• 让流程细节可视化，运营可直接理解和调整，无需依赖研发。

5.2 线体配置（简化）

这张图展示了完整质检流程的编排视图，类似于一个可拖拽的流程图。

• 作用：将多个节点按照业务逻辑连接成“线体”（完整作业流程），并定义节点间的流转条件、分支、并行关系等。
• 意义：
• 过去需要在状态机和流转单中分散实现，现在可以一图呈现整个链路，清晰直观。
• 可直接在图中调整节点顺序、修改条件分支，实现“所见即所得”的流程配置。
• 支持复杂场景（如条件分支、并行节点、网关汇聚）而不增加开发成本。

6 未来展望

当前，自研流程编排引擎已稳定承载质检新业务的全流程运行。下一阶段，我们将推动存量旧流程的平滑迁移，实现新旧业务的统一调度与集中管理。同时，计划升级引擎架构，引入低代码能力，开放更丰富的可视化配置与扩展接口，以更高的灵活性与敏捷性响应业务变化。

关于作者 李冠，转转履约中台研发工程师，主要负责质检业务