Activiti 7实战踩坑记：从本地单体到K8s云原生的迁移，我们经历了什么？

当我们的技术团队决定将核心业务流程系统从Activiti 5迁移到Activiti 7时，原本以为只是一次常规的版本升级。没想到这趟旅程彻底改变了我们对"流程引擎"的认知——从单体架构的简单工具，到云原生生态的复杂拼图。本文将还原我们踩过的每一个深坑，分享那些文档里没写的实战经验。

1. 迁移决策：为什么选择Activiti Cloud？

三年前搭建的系统基于Activiti 5.23，运行在传统的Tomcat+MySQL环境。随着业务量增长，我们面临三个致命问题：

• 性能瓶颈 ：高峰期并行流程实例超过5000个时，数据库连接池经常耗尽
• 扩展困难 ：无法实现动态扩缩容，新业务上线需要停机部署
• 监控缺失 ：缺乏分布式追踪能力，问题排查如同盲人摸象

对比主流方案时，我们发现三个关键事实：

方案	维护状态	架构特性	学习成本
Activiti 5/6	已停止维护	单体架构	低
Flowable	活跃	混合架构	中
Activiti Cloud	活跃	纯云原生架构	高

最终选择Activiti 7的原因很现实：我们的基础设施已全面Kubernetes化，需要深度集成的云原生方案。但这个决定带来的复杂度远超预期。

2. 架构重构：云原生带来的范式转变

2.1 组件拆分之痛

传统Activiti的"all-in-one"架构变成了分布式拼图：

# 新架构下的基础服务组成
kubectl get deployments -n activiti-cloud

NAME                            READY   UP-TO-DATE   AVAILABLE
runtime-bundle                  3/3     3            3
query-service                   2/2     2            2
audit-service                   2/2     2            2
connectors-service              2/2     2            2
notifications-graphql-service   2/2     2            2

每个组件都需要独立配置和监控。最坑的是 服务发现机制 ——原本在单体中自动完成的流程节点调用，现在需要处理：

1. Spring Cloud Kubernetes的服务注册延迟
2. Istio虚拟服务的路由规则
3. 跨命名空间的通信认证

我们最终采用的服务调用方案：

// 使用FeignClient调用Connector服务
@FeignClient(
    name = "connectors-service",
    fallback = ConnectorFallback.class,
    configuration = OAuth2FeignConfig.class
)
public interface ConnectorClient {
    @PostMapping("/execute")
    ExecutionResult execute(@RequestBody ConnectorRequest request);
}

2.2 BPMN兼容性陷阱

迁移第一个流程时就遭遇暴击——原本正常的BPMN文件报错"Unsupported element"。排查发现Activiti 7的BPMN支持度大幅缩减：

典型不兼容元素处理方案 ：

原元素类型	问题现象	解决方案
定时边界事件	引擎直接拒绝部署	改用信号事件+Quartz调度
复杂网关	运行时逻辑不一致	拆分为多个独占网关
邮件任务	无对应Service Task实现	开发自定义Connector
业务规则任务	缺少DMN引擎集成	改用独立微服务+HTTP调用

最棘手的 子流程调用 问题，我们通过组合方案解决：

1. 将共享子流程提取为独立Process Definition
2. 使用Call Activity元素调用
3. 配置跨Runtime Bundle的通信：

# application.properties
activiti.cloud.application.name=loan-process
activiti.cloud.service.type=runtime-bundle
spring.cloud.kubernetes.discovery.all-namespaces=true

3. 部署运维：K8s环境的特殊挑战

3.1 镜像构建的玄学

官方提供的Helm chart在GKE上运行良好，但在我们的私有化部署环境却频繁崩溃。根本原因是：

• 资源限制配置不当 ：默认的1CPU/1GB内存无法支撑中文流程变量处理
• Init容器顺序问题 ：DB初始化未完成时Runtime Bundle已启动
• 时区配置缺失 ：定时任务在UTC时间触发

修正后的values.yaml关键配置：

runtimeBundle:
  resources:
    limits:
      cpu: "2"
      memory: 4Gi
  env:
    - name: TZ
      value: Asia/Shanghai
  initContainers:
    - name: db-check
      image: busybox
      command: ['sh', '-c', 'until nc -z mysql 3306; do echo waiting...; sleep 2; done;']

3.2 监控体系的再造

原有基于日志文件的监控方式完全失效。新的监控方案需要整合：

1. Prometheus指标采集 ：

# 自定义指标暴露配置
management.endpoints.web.exposure.include=health,info,metrics,activiti
management.metrics.tags.application=${spring.application.name}

2. 分布式链路追踪 ：

// 在流程变量中注入TraceID
processInstance.setVariable(
  "X-B3-TraceId",
  MDC.get("traceId")
);

3. 业务级看板 ：

-- Grafana使用的查询语句
SELECT 
  process_definition_name,
  COUNT(CASE WHEN status='RUNNING' THEN 1 END) as running,
  COUNT(CASE WHEN status='COMPLETED' THEN 1 END) as completed
FROM activiti_cloud_query.process_instances
GROUP BY 1

4. 性能调优：云原生环境的特殊技巧

4.1 数据库连接风暴

当流程实例激增时，出现大量"Connection pool exhausted"错误。解决方案包括：

• 分级连接池配置 ：

# 主业务库配置
spring.datasource.hikari.maximumPoolSize=20
# Activiti专用配置
spring.activiti.datasource.hikari.maximumPoolSize=50

• 异步信号处理 ：

<bpmn:signal id="approvalSignal" activiti:async="true" />

• 批量操作优化 ：

runtimeService.createProcessInstanceQuery()
  .variableValueEquals("status", "pending")
  .listPage(0, 100)
  .forEach(instance -> {
      runtimeService.signal(instance.getId());
  });

4.2 缓存策略的平衡

分布式环境下的缓存需要特别设计：

1. 一级缓存 ：使用Redis作为分布式缓存

spring.cache.type=redis
spring.redis.timeout=3000

2. 二级缓存 ：流程定义本地缓存

@Bean
public ProcessEngineConfigurationImpl processEngineConfiguration() {
    SpringProcessEngineConfiguration config = new SpringProcessEngineConfiguration();
    config.setDeploymentCacheDir("/tmp/activiti-cache");
    config.setDeploymentCacheLimit(100);
    return config;
}

3. 防雪崩策略 ：

@CircuitBreaker(name = "queryService", fallbackMethod = "getCachedInstances")
public List<ProcessInstance> queryRunningInstances() {
    return queryService.createNativeProcessInstanceQuery()
        .sql("SELECT * FROM act_ru_execution WHERE SUSPENSION_STATE_ = 1")
        .list();
}

迁移完成后，系统在500节点K8s集群上的表现：

• 流程启动耗时从1200ms降至300ms
• 最大支持实例数从5k提升到50k+
• 扩缩容时间从分钟级降到秒级

但代价是运维复杂度指数级上升——这或许就是云原生的双刃剑。现在回看，如果团队没有成熟的K8s经验，可能Flowable会是更务实的选择。