Operaton Beta-3实测：Camunda 7老项目迁移与兼容性评估

1. Operaton是什么，为什么我要盯着Beta-3不放

1.1 Camunda 7的社区后继者

如果你最近在关注工作流引擎圈的动向，大概率知道Operaton这名字是怎么来的。Camunda官方把研发重心全部押到云原生架构的Camunda 8之后，老的Camunda 7就进入了一个"只维护、不加新功能"的状态。可是大量存量项目跑在Camunda 7上，BPMN流程、DMN决策表、历史数据全部绑在这个引擎里，要么花大代价迁移到8那套全新架构上重新建模，要么就得另找出路。Operaton就是这条路：社区把Camunda 7的代码fork出来，用Apache-2.0许可证继续往下做，目标简单直接——当Camunda 7的drop-in replacement，让老项目改改依赖就能接过来继续跑。

我自己的项目从Beta-1一路跟到Beta-3，这中间踩过不少坑，也看着这个项目的社区治理逐渐成型。说实话，一开始我对这种fork项目持观望态度，毕竟工作流引擎这东西一旦跑进生产，背后涉及的稳定性、数据兼容、社区维护意愿都是真金白银的成本。但跟到Beta-3之后，我改变了一些看法，所以才有了这篇文章。

1.2 Beta-3在版本节奏里的位置

要理解Beta-3的价值，得先看这个项目自己的版本节奏。Operaton的发布线不是一上来就奔着1.0去的：alpha阶段主要解决"能不能跑起来"的问题，Web应用能不能启动、REST接口通不通、数据库脚本能不能跑完，这个阶段我基本只做环境验证。到了beta阶段，项目就进入了"功能冻结、稳定优先"的状态，不再塞新功能，集中修bug、补兼容、梳理文档。Beta-3在这个节奏里已经非常接近release candidate了，核心功能定型，剩下的主要是边界问题和性能调优。

从社区运作方式来看，Operaton用的是比较透明的issue驱动模式，优先级高的改动会在GitHub上公示，用户可以去参与讨论和投票。Beta-3这版最明显的特点就是"收敛"：依赖版本统一升级，安全补丁跟进，Web端品牌彻底换成Operaton，同时把前几个beta版本遗留的兼容性问题集中处理掉。对于评估者来说，Beta-3比Beta-1、Beta-2更有参考价值，因为它基本能代表1.0正式版的形态。

1.3 我在这版上重点验证的四个面

我评估一个工作流引擎的beta版本，不会只看release note写了什么，而是会从四个方向做实测：第一是部署和升级是否顺畅，包括Docker镜像、Spring Boot集成、数据库schema变化；第二是引擎内核的稳定性，BPMN部署、作业执行、外部任务这一条链路在高并发下会不会出问题；第三是Web端的可用性，Cockpit、Tasklist、Admin这些后台工具是不是真的能用；第四是兼容性，这也是最关键的一点——老项目从Camunda 7迁移过来，代码要改多少、数据能不能复用、配置要动哪些。

这篇文章就把这四个面的实测过程完整记录下来。这篇是这个系列的第五篇，前几篇聊过引擎基础、BPMN建模、REST API接入和流程可观测性，如果你还没看，也不影响理解本篇内容，所有关键点我都会从Beta-3的视角重新交代。

2. Beta-3的部署与工程配置：拿到手先做这三件事

2.1 用Docker镜像先跑通环境

拿到Beta-3，我建议你第一件事别急着看代码，先把它跑起来，确认这个版本在你常用的数据库上能正常初始化。Operaton发布的是Tomcat整合包的Docker镜像，引擎、REST API、Cockpit、Tasklist、Admin都打在一个镜像里，环境变量沿用了Camunda 7那套约定，熟悉老版本的人基本没有学习成本。

这是一个我在Beta-3上实测可用的最小docker-compose配置：

services: db: image: postgres:16 environment: POSTGRES_DB: operaton POSTGRES_USER: operaton POSTGRES_PASSWORD: operaton healthcheck: test: ["CMD-SHELL", "pg_isready -U operaton -d operaton"] interval: 5s timeout: 5s retries: 10 operaton: image: operaton/operaton:1.0.0-beta-3 ports: - "8080:8080" environment: DB_DRIVER: org.postgresql.Driver DB_URL: jdbc:postgresql://db:5432/operaton DB_USERNAME: operaton DB_PASSWORD: operaton depends_on: db: condition: service_healthy

跑起来以后，浏览器打开http://localhost:8080/operaton，默认管理员账号是demo/demo，这是平台自带的管理员配置，生产环境一定要改。进到Cockpit首页能正常显示流程定义列表，说明环境没问题。如果启动日志里出现数据库连接错误，先检查DB_URL的写法，这个地址会被引擎直接拿去建数据源，host要写docker-compose里的服务名而不是localhost。

2.2 Spring Boot工程怎么改依赖

Docker镜像只是运行环境，真实项目大多还是用Spring Boot内嵌引擎的方式集成。Beta-3的Spring Boot Starter同样提供了BOM，方便做依赖版本统一管理。导入方式和你熟悉的Camunda 7一模一样，只是坐标变了：

<dependencyManagement> <dependencies> <dependency> <groupId>org.operaton.bpm</groupId> <artifactId>operaton-bom</artifactId> <version>1.0.0-beta-3</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>org.operaton.bpm.springboot</groupId> <artifactId>operaton-bpm-spring-boot-starter</artifactId> </dependency> </dependencies>

这里有个容易迷惑的点：Beta-3的Java包名大概率仍然保留org.camunda.bpm这套，因为官方为了贯彻"drop-in replacement"的思路，刻意不让你改Java代码里的import。也就是说，你的JavaDelegate、ProcessEngine类、Service接口都还是原来的包路径，代码可以原封不动地编译。但Maven的groupId确实改成了org.operaton.bpm，这个"依赖坐标变了、代码包名没变"的错位，是初次迁移时最常见的困惑。如果你拿到的官方BOM里坐标和上面不完全一致，以官方文档为准，beta阶段的小版本之间偶尔会调整artifactId。

Spring Boot版本方面，Beta-3对Spring Boot 3.x的支持已经比较完善，建议直接基于3.2以上的版本建工程。Java版本要求也跟进到了17，还在用Java 8的老项目要注意，这不是简单的依赖升级问题，编译级别和运行时环境都要一起动。

2.3 数据库schema与配置前缀

第三个要做的事是搞清楚Beta-3的配置变化。Camunda 7时代，Spring Boot工程的配置前缀是camunda.bpm，Operaton在Beta-3里引入了新的前缀operaton.bpm，同时保留了旧前缀的兼容读取。我的做法是新项目直接用operaton前缀，老项目迁移初期可以先用camunda前缀跑起来，等所有东西稳定了再全局替换。

operaton: bpm: admin-user: id: admin password: your-strong-password database: type: postgres schema-update: true generic-properties: properties: history-level: full

数据库schema这块，Beta-3还是沿用ACT_开头的那套表结构，引擎启动时如果检测到空库会自动建表。这里我要提醒一句：开发环境用schema-update: true可以，生产环境必须改成false，用引擎自带的SQL脚本手动执行建表，否则哪天启动参数写错，引擎版本和表结构不一致，会有莫名的报错。引擎初始化和表结构版本信息记录在ACT_GE_PROPERTY表里，升级前先看一眼这条记录，心里有个底。

3. 引擎内核实测：从BPMN部署、作业执行到外部任务

3.1 从部署到启动：一条完整的链路

引擎跑起来以后，我第一个要验证的就是老项目里的BPMN文件能不能直接部署。这个测试非常关键，因为如果BPMN解析层面有行为变化，意味着所有流程资产都要重新review，那是很大的工作量。

我拿了一个包含子流程、边界错误事件、多实例子流程的订单流程做测试，直接用REST API部署：

curl -X POST http://localhost:8080/rest/deployment/create \ -H "Accept: application/json" \ -F "deployment-name=order-process" \ -F "enable-duplicate-filtering=false" \ -F "order.bpmn=@order.bpmn"

部署接口返回的JSON里会带一个deployment id，然后查一下流程定义是否注册成功：

curl http://localhost:8080/rest/process-definition/key/order-process \ -H "Accept: application/json"

再用key启动一个实例：

curl -X POST http://localhost:8080/rest/process-definition/key/order-process/start \ -H "Content-Type: application/json" \ -d '{"variables":{"amount":{"value":1500,"type":"Double"},"customerId":{"value":"C-10086","type":"String"}}}'

实测下来，这份Camunda 7项目里直接用了几年的BPMN文件在Beta-3上部署解析没有任何问题，流程实例正常启动，历史表里的数据也都正确写入。这算是给老项目迁移吃了一颗定心丸。

3.2 作业执行器的行为变化

工作流引擎里最有技术含量的部分其实是作业执行器（Job Executor），它负责异步延续（async continuation）、定时器、重试这些机制。BPMN里凡是勾选了async before或者配置了定时边界事件，最终都会落到作业执行器上。

Beta-3这版在作业执行器上主要做的是稳定性和并发控制方面的收敛。我重点测了两个场景：一是大量流程实例同时触发定时器时，执行器是否能平滑扩展；二是失败作业的退避重试机制是否符合预期。在引擎内部，作业重试会按照退避策略逐渐拉长间隔，默认配置下第一次重试间隔几秒，后续逐渐递增，直到达到最大重试次数后被标记为incident。这个机制在Beta-3上没有出现异常，批量触发时锁竞争的情况比Beta-2要轻一些。

我建议你在压测环境里关注几个配置项：job-execution的开启状态、acquire-by-priority是否打开、最大线程池大小。尤其是acquire-by-priority，如果你的流程里设置了作业优先级，这个开关必须打开，否则优先级形同虚设。

3.3 外部任务模式：fetchAndLock实测

外部任务模式是我最关心的一块，因为现在微服务架构下，大量的业务逻辑都下沉到独立服务里，引擎只负责任务调度。外部任务的核心机制就是fetchAndLock，客户端主动向引擎拉取任务并加锁，处理完以后调用complete上报结果。

Beta-3的REST接口行为和Camunda 7基本一致，手动测一遍：

curl -X POST http://localhost:8080/rest/external-task/fetchAndLock \ -H "Content-Type: application/json" \ -d '{ "workerId":"worker-1", "maxTasks":1, "topics":[{"topicName":"order-pay","lockDuration":60000}] }'

拿到任务后处理完执行complete：

curl -X POST http://localhost:8080/rest/external-task/complete \ -H "Content-Type: application/json" \ -d '{ "workerId":"worker-1", "taskId":"<task-id>", "variables":{"payResult":{"value":"success","type":"String"}} }'

实测中最大的坑出在客户端的版本匹配上，这个我放在文章第六部分专门说，这里先给一个结论：外部任务客户端一定要用Operaton自己发布的版本，不要图省事继续用Camunda 7的旧客户端，哪怕当时跑通了，也容易在复杂场景下出现锁失效或序列化不一致。

3.4 消息事件与事务边界

流程引擎里消息事件的角色容易被低估。实际项目中，订单支付完成、出库结果返回这些外部系统通知，都是通过消息事件关联到等待中的流程实例上的。Beta-3对消息关联（message correlation）这块的修复比较实在，特别是多租户场景下的tenant匹配，之前Beta-2会有消息同时关联到多个租户同名流程的情况，这版处理得干净了。

REST接口还是老样子：

curl -X POST http://localhost:8080/rest/message \ -H "Content-Type: application/json" \ -d '{ "messageName":"paymentReceived", "businessKey":"ORDER-20250101-001", "variables":{"paymentTime":{"value":"2025-01-01T12:00:00","type":"String"}} }'

这里我想多说一句事务边界的问题。消息关联的调用发生在你的业务服务里，如果业务服务的事务提交晚于消息发送，消息先到引擎，引擎去关联一个还不存在的流程实例或者业务Key，就会关联失败。这个问题不是Beta-3特有的，任何工作流引擎都有，但我在操作时习惯配合本地消息表（outbox pattern），先把业务数据和待发送消息放进同一个事务，等事务提交后再把消息发给引擎，这样能从根本上避免事务不一致。

4. DMN、Tasklist和Cockpit：Web端这版的变化

4.1 DMN决策表和FEEL表达式

Operaton继承了Camunda 7的决策引擎，BPMN里内嵌DMN调用，或者独立部署决策表，都是日常操作。Beta-3在决策引擎上主要做了FEEL表达式引擎的升级和日期时间解析的修正。老项目里那些用了很多FEEL函数的决策表，部署和求值结果需要逐一验证。

决策表部署走通用的deployment接口，求值走：

curl -X POST http://localhost:8080/rest/decision-definition/key/order-decision/evaluate \ -H "Content-Type: application/json" \ -d '{ "variables":{ "customerAge":{"value":35,"type":"Integer"}, "orderAmount":{"value":8000,"type":"Double"} } }'

决策表里hit policy的选择直接影响结果语义，这个在Beta-3上没有变化，但我要提醒新接触的人：FIRST和UNIQUE两种hit policy的行为差别很大，FIRST允许多行命中但只取第一行，UNIQUE要求任何输入只能命中一行，否则求值报错。我在实际项目中见过因为把UNIQUE改成FIRST导致金额计算规则悄然变化的案例，如果你是做金融风控决策，这块务必人肉再验一遍。

4.2 Tasklist：人工任务与表单

Tasklist是给业务人员用的任务处理界面，Beta-3把这套界面的品牌切换成了Operaton，同时修了一批和任务筛选器（filter）相关的性能问题。我实测中印象最深的是候选组（candidate group）场景，一个组下挂几百个任务时，列表加载速度和滚动流畅度都比Beta-2明显好。

表单这块要区分两种：一种是嵌入式表单，HTML直接嵌在BPMN里；另一种是外部表单，前端自己实现。Beta-3对两种方式都做了兼容，嵌入式表单的变量回填、文件上传组件没有发现破坏性变更。配置候选组的方式还是老一套，在用户任务节点上指定camunda:candidateGroups="approvers,finance"，多个组用逗号分隔。

4.3 Cockpit：流程实例排查与Incident处理

Cockpit是运维人员的核心工作台，流程实例卡在哪、哪个作业失败了、变量值是什么，全在这里看。Beta-3的Cockpit有几个细节改动：流程实例列表的查询效率提升，incident的展示信息更全，批次操作（batch operation）的进度反馈更清晰。

我建议所有人把流程实例表中的"状态"列利用起来。引擎对incident的处理是：作业重试耗尽后，流程实例不会自动终止，而是进入等待状态，你在Cockpit里看到的是一行黄色的告警。处理incident的标准操作是先看异常堆栈，再决定是修数据后重试，还是直接取消实例。Beta-3里批量设置重试的操作入口很明显，选中多个失败实例，点"Retry"即可，底层是走批次任务执行的，数据量大时注意批次大小。

4.4 Admin：用户、组与权限模型

Admin负责用户、组、租户和权限管理。Operaton的权限模型和Camunda 7一脉相承：用户（User）、组（Group）、租户（Tenant）、授权（Authorization）四类实体共同决定谁能干什么。Beta-3在Admin界面上的改动集中在授权管理视图，权限矩阵的展示更直观了。

这块有一个老生常谈的坑：很多人以为配置了用户和组就够了，结果REST API调用时发现"无权限"，因为忘了配置授权。授权不是角色继承关系，而是显式的GRANT记录，比如你要允许"sales"组的用户启动"order-process"流程实例，需要显式创建一个类型为"Process Definition"的授权记录，资源ID填process key，权限选CREATE_INSTANCE。Beta-3的授权设置界面可以直接操作，不需要写SQL，生产环境建议把授权变更纳入变更管理流程，避免有人悄悄改权限。

5. 从Camunda 7或Beta-2迁移：兼容边界与清单

5.1 先说结论：drop-in到什么程度

很多团队问过我一个问题：Operaton说自己是drop-in replacement，那我把Camunda 7的依赖坐标一换就完事了吗？答案是"大部分情况下可以，但不能无脑换"。Beta-3能做到的兼容包括：BPMN/DMN/CMMN文件无需修改直接部署、Java API包名保留所以业务代码基本不动、数据库表结构延续ACT_体系所以数据可以复用、REST接口保持原有语义。需要你动手的地方集中在Maven坐标、配置前缀、少量依赖版本冲突，以及Web应用本身的部署方式。

这里我想强调"兼容不等于完全等同"。Operaton毕竟是一个独立项目，它有自己的版本节奏和安全策略，后续版本一定会有自己的新特性，不可能永远把自己钉在Camunda 7的兼容框架里。所以迁移前要想清楚：你是想要一个长期维护的Camunda 7延续版，还是只是临时糊一层壳。如果是后者，那没有意义。

5.2 依赖迁移对照表

我把自己项目中涉及到的核心依赖做了一张对照表，Beta-3阶段按这个表改基本能编译通过，但最终还是要以官方BOM为准：

改坐标的时候我建议用全局搜索替换，但每替换一个模块就编译一次，不要一次性全部替换完再编译，否则报错的时候根本定位不到是哪个依赖的问题。外部任务客户端这块尤其要注意版本号要和你部署的引擎版本完全一致，差一个minor版本都可能出问题。

5.3 代码层面的改动点

如果你的代码只是用了引擎的标准API，比如JavaDelegate、ExecutionListener、DelegateExecution，Beta-3下几乎不需要改代码。一个典型的JavaDelegate长这样：

import org.camunda.bpm.engine.delegate.DelegateExecution; import org.camunda.bpm.engine.delegate.JavaDelegate; public class CheckStockDelegate implements JavaDelegate { @Override public void execute(DelegateExecution execution) throws Exception { Integer stock = (Integer) execution.getVariable("stock"); if (stock != null && stock > 0) { execution.setVariable("stockEnough", true); } else { execution.setVariable("stockEnough", false); } } }

注意import路径还是org.camunda.bpm，这就是Operaton刻意保留兼容性的结果。你的Service类里通过注入方式拿到ProcessEngine、RuntimeService、TaskService这些对象，同样不需要改名。真正需要人工review的是那些直接操作引擎内部表的SQL、使用Camunda内部类的地方、以及依赖了Camunda特定版本行为的代码，这类代码没有统一的迁移规则，只能逐个看。

5.4 配置项迁移清单

配置文件层面，我整理了这份对照参考：

5.5 数据兼容与回滚方案

数据库这块是迁移的重头戏。Bloom到Beta-3，引擎表结构变化不大，理论上可以直接复用原有的Camunda 7数据库，但我强烈建议你在测试环境完成一次完整的升级演练，而不是直接在生产上赌。升级演练包括：备份原库、启动Beta-3指向备份库、观察引擎是否自动识别已有schema并做增量变更、跑一遍核心流程、对比历史数据完整性。ACT_GE_PROPERTY表里的schema版本信息在升级后会发生变更，这是正常的，但如果启动日志出现表名不存在的错误，说明schema变更没有执行成功，这时候唯一的出路是恢复备份。

回滚方案必须提前写好。最简单的回滚策略是"数据库还原+替换回旧版本部署包"。这里有一个关键点：升级后产生的历史数据不可逆，一旦写入新版本的低版本表结构，老版本引擎可能读不出来，所以回滚时数据库必须还原到升级前时间点的备份。生产环境的备份策略至少做PITR（时间点恢复），升级窗口要留足够的时间冗余，别把升级和发布压在同一天。

6. 实测踩坑记录：三个问题与规避方式

6.1 第一个坑：外部任务客户端版本不匹配导致锁丢失

这个坑的典型症状是：fetchAndLock能拉到任务，但任务处理完后complete时报错或者说任务在topic里反复出现、永远处理不完。我第一次遇到时查了半天，最后发现是外部任务客户端还是旧的Camunda 7版本，而引擎已经换成了Beta-3。两个版本之间对任务锁和变量的序列化字段存在细微差异，导致引擎认为客户端没有在锁时间内完成任务，把任务重新分配给其他worker，于是一边在处理、另一边又在拉同一个任务，形成循环。

解决方式很简单，外部任务客户端也换成Operatan的版本，并且版本号与引擎一致。我在Spring Boot工程里是这样配置的：

operaton: client: base-url: http://localhost:8080/rest worker-id: order-worker max-tasks: 10 async-response-timeout: 1000

这里再提醒一句，外部任务的锁时间（lockDuration）要结合你的业务处理时长来设置。别无脑设成60秒，如果你的业务处理通常要两三分钟，锁时间就要按分钟级往上调，否则再新的客户端也架不住锁反复失效。我一般按照"平均处理时间的3到5倍"来设锁时间，并加上监控告警。

6.2 第二个坑：History Cleanup在MySQL下的批量删除卡顿

我用MySQL 8跑了比较长的时间后，发现每周末凌晨的历史清理任务（History Cleanup）会出现卡顿，日志里有大量死锁报错，CPU和数据库连接数同时飙升。原因是历史清理本质上是大批量DELETE操作，Beta-3默认的批次大小对单表数据量极大的场景偏高，加上历史表的外键关联，一次删除涉及的行数过多，事务长时间持有锁，把其他业务的读写也拖住了。

我的处理方式是调小历史清理的批次，并把清理时间放到业务低峰期的后段。具体配置在generic-properties里：

history-cleanup-batch-size=200 history-cleanup-degree-of-parallelism=1 history-cleanup-execution-milliseconds=60000

另外我建议对ACT_HI_开头的表做分区或者按月归档。历史数据是越滚越大的，单靠清理任务永远追不上数据增长速度，更稳妥的做法是定期把历史数据归档到独立的历史库，再做清理。如果你的业务对历史数据有时效性要求，这一步在评估期就要想好，别等磁盘报警了再后悔。

6.3 第三个坑：CORS配置"照抄"导致REST接口无法跨域

前端项目要直接调引擎的REST API，就绕不开跨域配置。Camunda 7时代在网上能找到很多CORS配置示例，是在web.xml或者Spring配置里加一个CorsFilter。我迁移到Beta-3后，"照抄"了老配置，结果前端浏览器把请求直接拦了，报跨域错误。

查了半天发现原因很尴尬：Operaton平台自带的webapp里已经内置了CorsFilter，我又在应用层加了一个，两个过滤器重复处理，请求头的CORS响应字段叠加出现异常，浏览器不认。解决方式是删掉我自己的配置，直接用平台内置的跨域支持。如果你用Spring Boot Starter而不是平台整合包，那么在配置类里注册CorsFilter时要确保只有一个过滤器实例，并且allowed-origin配置要精确，不要图省事写*配合allow-credentials，浏览器会拒绝这种组合。

6.4 其他已知问题与资源占用观察

还有一个值得记录的观察点：Beta-3在Tomcat平台整合包默认堆内存设置偏保守，高并发场景下容易出现FullGC。如果压测发现吞吐量上不去，先别急着怀疑引擎效率，先看JVM参数。我在预生产环境把-Xms和-Xmx提到4GB后，同样的压测脚本，吞吐量直接提升了一倍。

日志方面，Beta-3的Spring Boot Starter默认走SLF4J，如果你项目里同时引入了log4j2的桥接包，偶尔会出现日志实现冲突。解决办法是全局排除掉多余的日志绑定，只保留一个实现。这个问题不特定于Operaton，Spring Boot项目都容易踩，但因为在迁移过程中依赖坐标变化，容易被忽略。

7. 我对Beta-3的整体评价：写在最后

7.1 适合谁现在上车

Beta-3这个版本，我认为适合三类团队：一是已经有Camunda 7存量项目、短期内不打算重写、但需要一个有社区活力的长期维护版的团队；二是新项目评估时倾向于成熟的工作流引擎模型、不追求云原生Kubernetes原生集成的团队；三是本身有Java能力、愿意自己修复和贡献代码的团队。第一类是我最明确的推荐场景，因为Operaton给了这类项目一个低成本的延续方案。

我的一个老项目就是典型的第二类场景：流程引擎只负责编排和状态管理，具体的业务逻辑全部在外部服务里，通过外部任务模式对接。这个架构下，引擎换代的摩擦面很小，我们花了两个周末完成了Beta-3的迁移验证，整体风险可控。

7.2 谁应该再等等

如果你的团队对厂商SLA有硬性要求，比如银行、政务类项目，那Beta版本直接上生产显然不合适。哪怕1.0正式版发布，也要走完自己的内部合规流程再动。如果你的项目已经开始用Camunda 8，也没有必要回退到Operaton，两套架构的目标场景完全不同。如果你要的是开箱即用的新功能，而不想参与社区共建，那也要降低预期，毕竟Operaton的路线图是由社区需求驱动的，不会像商业公司那样承诺具体功能的时间点。

7.3 我的做法与一个小技巧

我的做法是在预生产环境跑了一个月Beta-3，每天定时跑测试流程，检查历史数据写入和作业执行情况。一个月下来，稳定性接近Camunda 7.21的维护水平，几个早期beta版本的问题都没有复现。所以我的判断是：Beta-3已经具备"小范围试点"的条件，但正式生产我仍然建议等1.0，除非你的团队能接受在升级窗口内做一次数据迁移。

最后分享一个小技巧：生产环境里判断引擎是否健康，别只盯着进程有没有挂掉，要看REST API和作业执行器是否都活着。我习惯写一个定时任务，每隔五分钟用业务Key启动一个空流程实例，再调用查询接口确认它走到结束节点，任何一个环节失败就立刻告警。这个"合成监控"比单纯探活灵敏得多。至于REST API本身的探活，直接调：

curl http://localhost:8080/rest/engine

能正常返回引擎列表，就说明REST层是通的。剩下的，就交给你的流程设计和管理制度了。