Conflux BPM 流程中台：BPMN 建模、架构选型与落地运营

流程这件事有个很有意思的现象业务部门觉得流程是 IT 的事IT 部门觉得流程是业务的事最后谁都没真正管起来落地形态就是一堆散落在各系统里的审批按钮外加几张谁也说不清版本的 Excel 台账。这两年企业侧的数字化基础设施在整体换代服务器、数据、接口这些硬底子越来越标准化反倒是业务怎么跑这一层成了瓶颈。Conflux BPM这个标题里的组合本质上说的就是这件事把业务流程当成一项基础设施来建设和运营而不是当成一个又一个临时开发的功能点。这里说的 Conflux BPM是我们内部对这套流程中台的叫法它是一个以 BPMN 规范为内核、把流程建模、表单编排、规则判断和外部系统集成打包在一起的平台型产品。它能干的事听起来不新鲜——画流程图、配表单、发任务、走审批——但真正的价值在于让改一条流程从一次版本迭代变成一次配置。这篇文章适合三类人看正在做流程类系统选型的技术负责人、被审批需求追着跑的后端开发、以及想把线下流程搬到线上但不知道从哪下手的业务侧同学。我会把架构取舍、建模约束、落地步骤、容量估算和踩过的坑都摊开讲能抄的部分直接抄。1. 先把问题定义清楚Conflux BPM 在数字化版图里站哪个位置1.1 从电子审批到业务编排的三级跳大部分团队接触流程平台都是从一张请假单开始的。这个起点没问题但很容易把认知锁死在第一层。我把企业流程能力分成三级第一级是电子审批核心诉求是把纸单子变成系统里的待办解决的是留痕和远程签字第二级是流程管控开始关心节点时限、超时升级、转办委托、流程效率分析解决的是跑得快不快第三级是业务编排流程引擎不再只是给人派任务还要给系统派任务——调用库存服务、触发对账、等待外部回调、失败自动补偿这时候流程定义本身就是一份可执行的业务契约。绝大多数上 BPM 失败的案例根子都在于用第一级的心态去采购第三级的平台或者反过来用第三级的复杂度去做第一级的事。判断自己该在哪一级有个很土但很好用的方法数一数你现有流程里有多少节点是需要调用外部系统并等待结果的。如果超过三成那你就已经在第二级往第三级走了纯审批模型撑不住如果不到一成老老实实从审批做起别一上来就上 BPMN 全套团队学不动平台也会变成摆设。Conflux BPM 这类平台真正的分水岭就卡在这个给人派任务和给系统派任务的混合能力上。人任务的特点是耗时长几小时到几天、状态不可控可能驳回、可能加签、需要权限校验系统任务的特点是耗时短毫秒到秒级、需要幂等、需要重试和死信处理。这两类东西塞进同一个流程实例里事务边界、并发控制、失败恢复的逻辑完全不同这是后面所有架构设计的出发点。1.2 为什么自研审批流最后都会变成负债我见过太多团队的第一版自研审批流一张approval_record表字段是biz_id、current_node、approver_id、status加上若干个if-else。第一版通常两周就能上线业务还挺满意。问题出在第六个月业务说采购金额超过五万要加一级总监审批你说好加个判断再过两个月不同事业部审批链不一样你开始往表里加dept_type再往后要支持会签、要支持驳回到任意节点、要能看每个节点平均耗时——每一个需求单独看都不难合在一起就是一场灾难。自研审批流的核心负债不是代码量而是状态机散落。流程的状态被拆散在业务表字段、代码分支、前端页面判断里没有一个单一事实来源。你想回答这个单子现在到底卡在谁那里得写三段不同的查询拼起来你想做流程改版得先祈祷没有在途实例。相比之下专业流程引擎的价值不在于帮你写 if-else而在于它把流程状态收敛成了一套标准模型流程定义模板带版本、流程实例一次运行、任务待办单元、变量业务数据载体、历史审计与统计。这五样东西一旦标准化改流程就变成了改模板发新版本在途实例还跑在老版本上互不干扰。这是自研方案很难低成本复现的能力。1.3 什么样的组织适合上流程平台不是所有组织都该上。我一般用三个问题做初筛第一流程数量是否超过 20 条且还在增长低于这个量级自研或者用现成的轻量工具更划算平台化的固定成本摊不平。第二是否存在跨部门、跨系统的长链路如果一条流程从发起到结束只在一个部门内、只碰一个系统那它更像个功能模块不值得走平台。第三流程变更频率是否高于每季度一次变更越频繁平台配置代替开发的收益越明显如果流程五年不动那把它硬编码进去反而是最省事的。三个问题里有两个答是我建议认真评估流程平台三个都是是那基本不用犹豫。反过来如果一个都不沾别被数字化转型这四个字推着走先把手上的单点系统做扎实。2. 架构与选型把流程引擎当成基础设施来设计2.1 四层结构引擎、表单、规则、集成我在做 Conflux BPM 这类平台的架构设计时习惯把它切成四层每层职责单一层与层之间只通过明确定义的契约通信。这个切法的好处是任何一层出问题能快速定位任何一层要换实现不至于牵一发动全身。层次核心职责关键设计点常见误区流程引擎层流程定义解析、实例调度、任务分派、状态流转状态机唯一事实来源、版本隔离、事务边界把业务规则写进网关条件表达式里表单层数据结构定义、渲染、校验、字段权限与流程解耦、Schema 化、支持版本表单字段和数据库列一一硬绑定规则层审批人计算、条件分支、金额阈值判断规则外置、可热更新、可测试审批人写死在流程模板里集成层调用外部服务、接收回调、消息驱动幂等、重试、超时、补偿同步长事务阻塞流程推进这四层里规则层最容易被忽视也最容易出事。很多团队把金额大于五万走总监直接写进排他网关的条件表达式一开始很爽后来业务说阈值要按事业部差异化你就得改流程模板再后来业务说阈值要从配置中心动态读条件表达式就彻底撑不住了。正确做法是把这类判断抽成独立的规则服务流程里只留一个调用规则、拿到结果的服务任务规则怎么算、阈值多少全在规则层解决。2.2 三种技术路线的取舍对照真到选型那一步绕不开三条路直接用成熟的开源流程引擎二次封装、采购商业流程平台、完全自研轻量状态机。我把这几年的对比结论整理成下面这张表注意这里的成本估算都是按中型团队5 到 8 人口径。维度开源引擎二次封装商业流程平台自研轻量状态机首版上线周期6 到 10 周3 到 6 周2 到 4 周复杂流程支持度高BPMN 全套中高看产品成熟度低超出预期就得重写长期维护成本中要跟版本、要吃透源码低到中受厂商路线影响高需求一复杂就失控定制自由度高中受产品边界限制极高团队能力门槛需要懂 BPMN 和引擎内部模型需要懂配置和集成需要极强的抽象能力适合场景流程多、变更频繁、有技术积累流程标准化程度高、要快速见效流程少于 20 条、结构稳定我的实际倾向是如果团队里有至少一个人能把引擎的表结构和执行语义讲清楚走开源引擎封装这条路性价比最高否则宁可买商业产品也别硬啃源码半懂不懂地魔改引擎是给自己埋雷。至于完全自研只在流程数量少、结构极其稳定、且团队对业务理解极深的情况下才成立。2.3 部署形态与数据边界部署形态这个事很多团队一开始想得太简单后面迁移代价极大。核心要决定两件事流程引擎的数据和业务数据放不放在同一个库以及引擎是独立服务还是嵌在业务应用里。嵌入式部署引擎作为 jar 包跑在业务应用里的好处是事务简单——业务数据落库和流程推进可以在同一个本地事务里完成不用担心一致性问题。坏处是升级引擎版本要动所有业务应用且引擎的执行器线程会和业务线程抢资源压测时很容易互相拖累。独立服务部署引擎单独跑一个集群业务通过 API 调用的好处是升级独立、资源隔离、多个业务系统共用一套流程能力坏处是引入了分布式事务问题——业务单据已经落库但流程启动调用失败了怎么办我的处理方式是本地消息表加最终一致业务落库时同时写一条待发送消息由定时任务或消息中间件保证流程启动最终成功流程侧用业务单据号做幂等键。这套方案不优雅但极其可靠我在生产环境跑了很久没出过数据错乱。注意无论哪种部署形态都要给流程实例表和任务表规划分区策略。这两张表的增长速度会远超你的预期等到单表过亿再想分区停机窗口和迁移风险都很难接受。3. 建模与设计细节决定成败的六个硬约束3.1 BPMN 元素只用一个安全子集BPMN 规范里的元素多到能出本书但生产环境里真正该用的我建议收敛到一个安全子集开始事件、结束事件、用户任务、服务任务、排他网关、并行网关、子流程、边界定时事件。就这些足够了。像包容网关、事件子流程、补偿事件这些语义复杂、引擎实现差异大、出问题极难排查除非有非用不可的场景否则一律不用。这个约束不是保守是血泪。我踩过一个坑某条流程用了嵌套的包容网关测试环境一切正常上了生产之后在特定并发下出现分支没有被正确激活单据卡死在中间状态。翻引擎源码翻了两天才搞明白是条件求值顺序的问题。从那以后我给自己定了规矩能用排他网关表达的绝不用包容网关能用两个排他网关拼出来的绝不用嵌套。复杂度是要还的早还晚还的区别而已。另一个硬约束是流程模板的节点数量。单条流程超过 40 个人工节点业务人员基本就看不懂了改起来也容易出错。遇到这种情况正确做法是拆成主流程加子流程或者干脆承认这条流程本身的业务设计就有问题——真正需要四十个审批节点的业务大概率是在用流程弥补制度缺失。3.2 表单与流程解耦的具体做法表单和流程耦合是流程平台最常见的架构失误。典型症状是表单加一个字段流程模板要跟着改流程加一个节点表单渲染直接报错。解耦的关键是让表单只描述数据长什么样流程只描述数据流向哪两者通过变量名这根细线连接。具体做法是把表单定义成 JSON Schema 结构的描述包含字段名、类型、校验规则、显示条件、字段级权限流程模板里只出现变量名比如${purchaseAmount}它不关心这个变量在表单上是输入框还是下拉框。这样做的直接收益是同一套表单可以挂到多条流程上同一个流程也可以在不同步骤展示不同的表单视图。{ formKey: purchase_apply_v3, version: 3, fields: [ { key: purchaseAmount, type: number, label: 采购金额, required: true, min: 0, max: 10000000 }, { key: purchaseType, type: select, label: 采购类型, required: true, options: [设备, 耗材, 服务] }, { key: budgetCode, type: text, label: 预算编号, required: true, visibleWhen: purchaseAmount 50000 } ] }这段 Schema 里有两个细节值得说。一是visibleWhen表达式它让字段的显隐由数据驱动而不是由流程节点驱动财务类流程里金额超过五万才填预算编号这种需求就能直接表达。二是version字段表单版本必须和流程实例绑定否则在途单据会因为表单升级而渲染错乱——这是我在生产环境被投诉过的问题改完表单忘了处理在途实例用户打开待办看到一片空白。3.3 会签、加签、退回、撤销怎么落地这四个动作几乎每个流程项目都会被提而且每个都比看起来麻烦。我一个个说。会签本质是多实例任务流程走到某个节点同时生成 N 个任务全部完成或按比例完成才继续往下。实现上要用引擎的多实例特性配置完成条件常见的是全部同意和一票否决两种。需要注意的是会签节点的变量作用域——每个会签参与者的审批意见必须存在局部变量里不能都往全局变量写否则后一个人会覆盖前一个人的意见。加签是运行时的动态行为不是流程模板里能预定义的。常见实现是在任务上加一个加签操作由引擎动态创建一个新的任务实例并在数据模型里记录它和原任务的父子关系。这块的坑在于加签后的流程推进逻辑如果加签任务是前置的必须先处理原任务要挂起如果是后置的并行处理原任务保持激活。这两种模式一定要和业务确认清楚我见过因为没确认加签完单据直接卡死的案例。退回要区分两种语义退回上一个节点和退回到任意已走过的节点。前者简单引擎一般内置支持后者需要在流程实例上维护一条已访问节点的路径记录退回时按路径回跳同时要处理中间节点的任务清理。撤销则是发起人的特权前提是流程还没走到不可回退的节点比如已经付款了就不能撤销。这两个功能我建议在平台层统一实现别让每条流程自己处理否则一致性根本保证不了。3.4 数据可见性与字段级权限流程类系统最容易被忽略、出问题又最尴尬的是权限。用户 A 能看到这条单据但只能看到其中三个字段用户 B 是部门负责人能看到本部门所有单据但不能看金额明细。这类需求在采购、人事、财务场景里极其普遍。实现上分三层实例级控制谁能看到这条流程实例通常是发起人、当前处理人、历史处理人、指定干系人节点级控制当前节点能看到哪些字段字段级控制具体某个字段是只读、可编辑还是隐藏。三层叠加最终渲染时取交集。这套逻辑一定要收敛在平台层统一实现如果散落到各个业务模块迟早会出现越权访问。提示字段级权限的配置不要写在流程模板的 XML 里也不建议写在前端。放在服务端的权限配置表中每次渲染表单时由后端计算好字段状态再下发前端只负责按状态渲染。前端藏字段等于没藏这个道理不用多解释。4. 从零跑通一条采购申请流程4.1 环境与工程结构准备光说架构没意义我把一条完整的采购申请流程从头走一遍你能照着复现。环境上我假设JDK 17、关系型数据库一套MySQL 8 或同级别、缓存一套、消息中间件一套。工程结构我建议拆成四个模块对应前面说的四层conflux-bpm/ ├── engine-adapter/ # 引擎封装层对外屏蔽引擎细节 ├── form-service/ # 表单 Schema 管理与渲染数据组装 ├── rule-service/ # 审批人计算、条件判断、阈值规则 └── gateway-api/ # 对业务系统暴露的统一 API 与回调接收engine-adapter这一层别省。它的作用是把引擎的 API 包一层对外只暴露启动流程、完成任务、查询待办、撤回这几个语义清晰的方法。为什么要多这一层因为引擎的 API 往往又细又绕业务方直接用会写出各种奇怪调用更重要的是将来换引擎实现时改一个适配层就够了。这个抽象成本很低收益很高。4.2 流程定义与表单 Schema流程定义我一般用 JSON 描述而不是直接写 BPMN XML。原因是 XML 太啰嗦人工维护容易错而 JSON 结构清晰前端可视化建模器也更容易对接最后由平台统一转换成引擎能识别的格式。{ processKey: purchase_apply, version: 1, nodes: [ { id: start, type: startEvent }, { id: apply, type: userTask, assignee: ${initiator}, formKey: purchase_apply_v3 }, { id: gw_amount, type: exclusiveGateway, expression: ${purchaseAmount 50000} }, { id: dept_approve, type: userTask, assigneeRule: deptLeaderOf(${initiator}) }, { id: director_approve, type: userTask, assigneeRule: directorOf(${deptCode}) }, { id: finance_approve, type: userTask, assigneeRule: financeRole(purchase) }, { id: notify, type: serviceTask, handler: notifyApplicant }, { id: end, type: endEvent } ], flows: [ { from: start, to: apply }, { from: apply, to: gw_amount }, { from: gw_amount, to: director_approve, when: true }, { from: gw_amount, to: dept_approve, when: false }, { from: director_approve, to: finance_approve }, { from: dept_approve, to: finance_approve }, { from: finance_approve, to: notify }, { from: notify, to: end } ] }注意assigneeRule这个字段它没有把审批人写死而是引用了规则层的函数。这样部门负责人具体是谁由规则服务在运行时算人员变动、组织调整都不需要改流程。这是前面说的规则外置的具体落地形态。另外formKey只出现在需要用户填写的节点上服务任务和网关不挂表单保持干净。4.3 服务任务与外部系统集成采购流程走到最后要通知申请人还要回写预算占用这些都是服务任务。集成的核心原则是短事务、可重试、可幂等。我通常用这样的方式用户任务完成后引擎推进流程遇到服务任务时不是同步调用而是投递一条消息给消息中间件由消费者异步执行。public class NotifyApplicantHandler implements ServiceTaskHandler { Override public void execute(ProcessContext ctx) { String applyNo ctx.getVariable(applyNo); String idempotentKey notify: applyNo : ctx.getNodeId(); if (idempotentStore.exists(idempotentKey)) { return; } notificationClient.send(applyNo, ctx.getVariable(applicant)); idempotentStore.mark(idempotentKey, Duration.ofDays(7)); } }这段代码里最关键的是idempotentKey。消息中间件默认是至少一次投递意味着同一个消息可能被消费多次如果没有幂等控制用户就会收到重复通知。幂等键的构造要包含流程实例标识和节点标识这样即使流程因为退回重走了一遍这个节点也能区分开。Duration.ofDays(7)是幂等记录的保留期太短会导致重复消费防不住太长会让存储无限增长七天是个经验上的平衡点。另一个必须处理的点是失败补偿。服务任务失败不能把整个流程卡死我一般配置三道防线第一道是自动重试三次间隔递增第二道是重试耗尽后把任务标记为异常待处理挂起当前分支但不阻塞其他分支第三道是超过一定时限自动触发人工介入提醒。这三道配齐基本不会出现流程静默卡死的情况。4.4 压测与容量估算容量估算不能拍脑袋我给一套实打实的算法。假设场景5000 人的组织其中 2000 人是流程活跃用户人均每天发起或处理 20 条任务那么日均任务量约 4 万条。峰值怎么算办公场景的流量高度集中在上午 9 点到 11 点这两个小时此区间承载全天大约 40% 的操作量即 1.6 万次任务操作。峰值 TPS 16000 / 7200 ≈ 2.2 次/秒。这个数字看起来很轻松但要注意两个放大器一是批量提交月末报销集中提交时可能瞬间来几百条二是重试放大一次失败的重试会瞬间把负载翻倍。所以我通常按基础峰值再乘一个 5 到 8 倍的余量也就是目标承载 12 到 18 TPS按 20 TPS 做压测基准。存储侧更值得关注。每条任务平均产生一条任务记录、若干条变量记录、一条历史记录保守按 3 倍计算日均新增记录 12 万条一年是 4400 万条左右。这个量级必须做分区——按流程实例启动月份做范围分区历史表单独规划归档策略热数据保留一年冷数据转归档库。这件事要在上线前做完而不是等表大了再补我见过太多项目在单表八千万行的时候开始讨论分库分表那个时间点的选择空间已经很小了。注意压测一定要压完成任务这个动作而不是只压查询待办。查询可以加缓存提交任务涉及状态流转、变量写入、后续节点激活是最重的写路径也最容易暴露锁竞争问题。同一个流程实例上的并发操作是天然的冲突点压测时要专门构造这种场景。5. 常见问题与排查实录5.1 故障速查表流程平台的故障有个特点现象和根因往往隔了好几层。我把这几年遇到的高频问题整理成一张速查表按现象反查原因能省不少排查时间。现象大概率根因排查动作待办列表里任务重复出现任务查询未去重或多实例任务生成逻辑有误查任务表的流程实例 ID 加节点 ID 是否有重复行流程卡在某节点不动服务任务异常未抛出分支被静默挂起查引擎的作业表和历史表看有无失败作业记录审批人显示为空规则服务返回空或组织架构数据同步延迟单独调用规则服务接口验证返回再查组织数据同步时间退回后重复生成历史任务退回逻辑未清理中间节点任务检查回跳路径上的任务状态是否被正确置为已取消并发审批导致数据覆盖全局变量被并发写缺乐观锁检查变量写操作是否带版本号校验表单渲染空白表单版本和流程实例绑定的版本不一致核对实例上的表单版本号与已发布版本是否匹配流程实例启动失败但业务单据已生成分布式事务未补偿检查本地消息表是否有未发送成功的记录5.2 几条用血换来的避坑经验第一条别在流程模板里写业务逻辑。网关条件里放简单的数值比较可以一旦出现多表关联查询、复杂字符串处理立刻抽到规则服务或服务任务里。模板里逻辑越重改版风险和测试成本越高。第二条流程变量要克制。有些团队图省事把整个业务对象序列化塞进变量里结果变量表膨胀得比业务表还大每次流程流转都要读写一个几 MB 的 JSON。正确做法是只存判断流转需要的少量字段完整业务数据留在业务表通过业务单据号关联。这个原则我们叫变量存指针不存实体。第三条流程定义发布要带完整校验。发布前检查所有网关分支是否都有出口、所有用户任务是否都有审批人规则、所有服务任务是否有处理器实现、是否存在不可达节点。这四项检查写成自动化校验能拦掉八成以上的低级错误。我踩过的坑是发了一条没有配置审批人规则的流程上线后任务生成失败用户点了提交什么反应都没有投诉电话直接打到技术负责人那里。第四条留好操作日志。谁在什么时间对哪个实例做了什么操作必须全量记录且不可修改。这不只是为了合规更是排障的基础。没有操作日志用户说我的单子被谁退回了你根本答不上来只能靠翻引擎日志猜。6. 上线只是开始版本治理与运营指标6.1 流程版本与灰度流程模板的版本管理和代码版本管理不一样它有一个绕不开的约束在途实例必须能跑完。我的做法是版本只增不改——流程模板发布后即冻结任何修改都产生新版本新发起的实例走新版本在途实例继续跑老版本直到结束。这套机制的关键点是流程实例启动时要把模板版本号固化到实例记录上后续所有节点跳转、表单渲染都基于这个固化的版本。灰度发布同理。新版本先对某个小范围组织或某类业务开放观察一周的完成率、耗时、异常率没问题再全量。这里有个容易忽略的细节灰度期间如果发现问题需要回滚回滚的是入口而不是已发起实例已经按新版本跑起来的实例只能修正后继续不能整体回退。所以新版本的第一批实例最好选那种影响面小、可人工兜底的业务。6.2 该盯的五个指标流程平台上线后如果不看数据很快就会退化成能跑就行的工具。我日常盯五个指标每个对应一个具体动作。流程完成率发起后最终走完的比例。低于 85% 就说明有大量单据被撤回或长期挂起要去查是流程设计不合理还是审批人不作为。平均流转时长从发起到结束的中位耗时注意用中位数不用平均值少数超长实例会把平均值带偏。节点等待时长定位到具体节点的平均停留时间超过 24 小时的节点是重点优化对象通常是审批人权限过大或者节点设置冗余。退回率某个节点退回率高说明前置节点的填写质量有问题该加校验的地方加校验。异常任务数服务任务失败后没被处理的存量这个数字要当成告警指标超过阈值必须清。这五个指标不需要多复杂的技术从历史表里按天聚合就够了。关键是有人看、有人管最好做成每周一早上自动推送到群里形成习惯。我个人在实际操作中的体会是流程平台的价值一半在建设一半在运营只建不运营的平台两年后一定变成没人愿意碰的历史包袱。最后分享一个特别小但特别管用的做法给每条流程配一个流程负责人写进流程模板的元数据里出了问题直接找他不要找技术团队。技术团队负责平台的稳定流程负责人负责流程的合理这条边界划清楚了扯皮能少一大半。