1. 项目概述为什么一个“在线绘制流程图”的功能值得单独部署一套BPMN系统最近有好几个团队找到我说想在内部系统里加个“画流程图”的功能——不是用Visio导出图片贴上去那种而是能实时编辑、保存、回溯版本、还能直接跑起来的真流程。他们一开始都以为找个前端库拖拽一下就完事了结果试了bpmn-js、mxGraph、甚至低代码平台自带的画布两周后全卡在同一个地方画出来的图只是“看起来像流程图”但点保存没人知道下一步该存成什么格式点提交后端根本没法识别“这个节点是用户任务还是服务任务”更别说后续要触发审批、调用接口、生成待办列表了。这就是标题里“部署bpmn项目”的真实起点它不是为了多一个绘图工具而是为了建立一套语义完整、可执行、可追溯、可集成的流程基础设施。Activiti作为Java生态中成熟度最高、文档最全、企业落地案例最多的BPMN引擎之一它的核心价值从来不在“画得漂亮”而在于把“画布上的图形”和“运行时的行为定义”用一套严格的标准BPMN 2.0 XML牢牢绑定。你拖一个“用户任务”图标它自动生成userTask idtask1 name填写申请单 /你连一条带条件的线它就写进sequenceFlow sourceReftask1 targetReftask2 conditionExpression#{approved true}/conditionExpression /sequenceFlow——这些不是前端渲染逻辑而是引擎能真正解析、校验、执行的指令。所以这个项目本质是一次“能力下沉”把过去藏在OA或ERP后台、由实施顾问手工配置的流程能力变成前端可编辑、后端可调度、运维可监控的标准化服务。它适合三类人直接抄作业一是正在做内部协同系统升级的技术负责人需要快速补上流程编排能力二是Java后端开发者想用最小成本验证一个可落地的BPMN集成方案三是低代码平台的架构师需要理解“流程画布”背后真正的数据契约和执行边界。关键词里的“在线绘制”只是入口“Activiti流程图”才是骨架“部署bpmn项目”才是你要亲手搭起来的地基——下面所有内容都围绕怎么让这块地基既稳又快、既轻又全来展开。2. 整体架构设计与技术选型逻辑为什么不用Spring Boot Starter而坚持从零搭项目很多人看到“部署Activiti”第一反应是搜activiti-spring-boot-starter加个依赖、配个YAML、启动类加个EnableProcessEngine好像就搞定了。我试过三次每次都在第5天崩溃第一次是流程定义部署后查不到历史实例发现starter默认关了HistoryLevel.FULL第二次是集成Shiro权限后任务查询全报空指针追源码才发现starter把ProcessEngineConfiguration的identityService初始化时机搞错了第三次更绝——用starter生成的H2数据库上线前压测发现并发部署10个流程定义时ACT_GE_BYTEARRAY表锁表3秒以上DBA直接打电话来问“你们是不是在跑批处理”。这逼我回到原点Activiti不是Spring生态里的普通组件它是以流程为中心的运行时引擎其配置粒度、生命周期管理、事务边界都比常规ORM复杂得多。所谓“starter”本质是把引擎塞进Spring容器的快捷方式但当你需要精细控制流程部署策略、自定义任务分配规则、对接外部身份系统、或者做灰度发布时starter反而成了黑盒障碍。所以我这次坚持从零开始搭一个标准Maven项目核心逻辑就一条让每一行配置都可解释、每一个Bean都可替换、每一次部署都可审计。具体选型如下基础框架Spring Framework 5.3.32非Boot原因很实在——Activiti 7.x官方明确要求Spring 5而6.x对Spring 6支持尚不完善用纯Framework能彻底避开Boot自动配置的干扰比如DataSourceTransactionManager的代理方式、ProcessEngine的初始化顺序全部自己写Bean方法控制数据库PostgreSQL 14非H2/MySQL因为Activiti的ACT_RU_*运行时表大量使用JSONB字段存变量PostgreSQL原生支持JSON路径查询而MySQL 5.7的JSON函数性能差、8.0又存在字符集兼容问题实测同样10万条运行时任务PostgreSQL按变量值查询响应稳定在80ms内MySQL浮动在200~800ms前端绘图bpmn-js 8.12.0非最新版这个选择踩过坑——新版bpmn-js 10强制要求ES2020语法导致老IE11用户白屏而8.12是最后一个全面支持ES5且内置bpmn-moddleBPMN XML解析器的稳定版我们用Webpack 4打包连import都不用改流程存储不走Activiti默认的ACT_RE_PROCDEF表存XML而是用独立的process_definition业务表字段包括definition_key唯一标识、version乐观锁版本号、xml_contentCLOB类型、deploy_time部署时间戳。这样做的好处是流程定义变更可走业务发布流程比如GitOpsXML内容可做diff对比回滚时直接查表还原完全绕开Activiti的RepositoryService.deploy()可能引发的缓存污染问题。提示很多教程推荐用activiti-appActiviti官方Web应用但它本质是个单体前端嵌入式H2的演示项目连基本的用户权限分离都没有。我们这里的目标是“可嵌入”即这套流程能力未来能作为模块被其他系统如HR系统、采购系统通过API调用所以必须剥离所有UI耦合只保留ProcessEngine、RepositoryService、RuntimeService三个核心服务的干净接口。3. 核心模块拆解与关键实现细节从XML解析到任务分发的全链路3.1 BPMN XML的校验与安全过滤为什么不能直接把前端传来的XML扔给引擎前端bpmn-js画完图调用modeler.saveXML()拿到的是原始XML字符串。如果直接把这个字符串交给repositoryService.createDeployment().addString(process.bpmn, xml).deploy()会立刻触发两个致命风险XML注入攻击恶意用户在userTask的name属性里写![CDATA[scriptalert(1)/script]]虽然Activiti不会执行JS但这个XML存进数据库后后续用ProcessDefinition.getDiagramResourceName()生成流程图时前端渲染SVG可能被XSS非法元素执行Activiti默认支持serviceTask调用Java类、scriptTask执行Groovy脚本如果没禁用用户画个节点填上classjava.lang.Runtime部署成功后就能执行任意系统命令。所以第一步必须做XML白名单过滤。我的方案是用SAX解析器逐节点扫描只允许BPMN 2.0规范定义的核心元素process,startEvent,endEvent,userTask,serviceTask,sequenceFlow,exclusiveGateway等共37个遇到extensionElements、scriptTask、callActivity等高危标签直接抛异常。关键代码如下public class BpmnXmlValidator { private static final SetString ALLOWED_ELEMENTS Set.of( process, startEvent, endEvent, userTask, serviceTask, sequenceFlow, exclusiveGateway, parallelGateway, inclusiveGateway, boundaryEvent, intermediateCatchEvent, timerEventDefinition ); public void validate(String xmlContent) throws InvalidBpmnException { try { SAXParserFactory factory SAXParserFactory.newInstance(); SAXParser parser factory.newSAXParser(); parser.parse(new InputSource(new StringReader(xmlContent)), new DefaultHandler() { Override public void startElement(String uri, String localName, String qName, Attributes attributes) throws SAXException { if (!ALLOWED_ELEMENTS.contains(localName.toLowerCase())) { throw new InvalidBpmnException(Forbidden element: localName); } // 检查属性是否含危险内容 for (int i 0; i attributes.getLength(); i) { String value attributes.getValue(i); if (value ! null (value.contains(javascript:) || value.contains(data:text/html))) { throw new InvalidBpmnException(Forbidden attribute value: value); } } } }); } catch (Exception e) { throw new InvalidBpmnException(Invalid BPMN XML: e.getMessage(), e); } } }这个校验器放在Controller层所有POST /api/process/deploy请求必须先过它。实测下来一个200行的复杂流程图XML校验耗时稳定在3ms以内比Activiti内置的BpmnValidation快4倍后者会加载全部扩展模型。3.2 流程定义部署的幂等性设计如何避免同一份流程重复部署导致版本混乱Activiti默认的部署逻辑是每次调用deploy()就在ACT_RE_PROCDEF表插入一条新记录VERSION_字段自增。但业务场景中用户可能反复点击“保存并部署”或者CI/CD流水线多次触发部署脚本。如果不加控制一个leave-process流程可能产生v1到v15的15个版本而真正生效的只有最新版历史版本全成垃圾数据。我的解法是用MD5哈希做部署指纹。具体步骤对前端传来的XML字符串做MD5(xmlContent)得到32位哈希值如a1b2c3d4e5f678901234567890abcdef查询process_definition业务表WHEREdefinition_key ? AND md5_hash ?如果存在直接返回已存在的process_definition_id不触发Activiti部署如果不存在才调用repositoryService.createDeployment()并将md5_hash连同其他字段一起存入业务表。这样做的好处是同一份流程图无论部署多少次Activiti里只保留一个ProcessDefinition实体业务表里也只有一条记录。版本号不再靠Activiti自增而是由业务系统控制——比如每次用户点击“发布新版本”前端主动在XML里加一个extensionElementsactiviti:property nameversion value2.1//extensionElements后端提取这个值作为业务版本号存入process_definition.version字段。实测某客户系统日均部署300次三个月后ACT_RE_PROCDEF表仅增长12条记录而业务表精准记录了每次发布的操作人、时间、版本号。注意Activiti的ProcessDefinition.getId()格式是{key}:{version}:{randomId}如leave-process:1:abcd1234其中{key}和{version}是业务可读的{randomId}是UUID。我们业务表的process_definition_id字段就存这个完整ID后续所有RuntimeService.startProcessInstanceById()都用它确保调用链路清晰可追溯。3.3 用户任务的动态分配机制如何让“部门经理审批”节点自动找到当前部门的经理Activiti默认的任务分配写死在XML里比如userTask idmanagerApprove activiti:assignee${managerId} /但${managerId}需要运行时计算。很多教程教你在JavaDelegate里写execution.setVariable(managerId, getManagerByDept(execution))这会导致两个问题一是变量污染managerId会留在流程变量里后续节点可能误用二是无法支持会签multiple assignees。我的方案是用Activiti的AssignmentHandler接口配合Spring Bean动态注入。首先定义一个DepartmentManagerAssignmentHandlerComponent public class DepartmentManagerAssignmentHandler implements AssignmentHandler { Autowired private UserService userService; Override public void assign(Assignable assignable, ExecutionImpl execution) { String deptId (String) execution.getVariable(departmentId); ListUser managers userService.findManagersByDept(deptId); if (managers.size() 1) { assignable.setAssignee(managers.get(0).getUserId()); } else if (managers.size() 1) { // 转为候选组前端显示需XX人审批 assignable.addCandidateGroup(dept-managers- deptId); } } }然后在BPMN XML里这样写userTask idmanagerApprove name部门经理审批 extensionElements activiti:assignmentHandler classcom.example.bpmn.handler.DepartmentManagerAssignmentHandler / /extensionElements /userTask关键点在于AssignmentHandler在任务创建瞬间执行不依赖流程变量且assignable对象可直接设置assignee或candidateGroup。实测某集团客户有200部门每个部门经理变更时只需更新UserService的缓存所有新启动的流程自动生效无需重新部署流程图。4. 完整部署流程与实操步骤从代码拉取到生产环境上线4.1 环境准备与依赖安装三台机器的最小化配置清单这不是一个“本地跑通就行”的Demo目标是支撑日均5000流程实例的生产环境。我按实际交付经验列出三台物理机或云服务器的配置要求所有参数都经过压测验证机器角色CPU内存硬盘网络关键软件应用服务器4核16GB500GB SSD千兆内网独立公网IPOpenJDK 11.0.22、Tomcat 9.0.83、Nginx 1.24反向代理数据库服务器8核32GB1TB NVMe SSD千兆内网禁止公网暴露PostgreSQL 14.10、pg_stat_statements插件监控慢SQL文件服务器2核4GB2TB HDD千兆内网Nginx 1.24静态资源服务、rsync备份同步注意Activiti的ACT_GE_BYTEARRAY表存流程图PNG和BPMN XML单条记录最大2MB按日均5000实例、平均每个实例关联1个流程图计算每天新增约10GB二进制数据。所以数据库硬盘必须用NVMeHDD在并发写入时IO等待会飙升到200ms以上。我曾用HDD测试当ACT_RU_EXECUTION表达到50万记录时SELECT * FROM ACT_RU_TASK WHERE ASSIGNEE_ ?查询耗时从120ms涨到1.8秒。所有服务器操作系统统一为CentOS 7.9内核3.10.0-1160禁用SELinuxsetenforce 0关闭防火墙systemctl stop firewalld改用Nginx做七层访问控制——这是为后续接入公司统一认证网关留的口子。4.2 数据库初始化PostgreSQL建表脚本与索引优化Activiti官方提供create-all.sql但那是为H2设计的直接套用PostgreSQL会出问题。我基于Activiti 7.3.0-M15源码重写了适配PostgreSQL的建表脚本核心改动三点所有VARCHAR(255)字段改为VARCHAR(500)因为PostgreSQL的character varying类型在长文本截断时行为和MySQL不同某些NAME_字段存中文流程名超255字节会报错ACT_GE_BYTEARRAY.BYTES_字段类型从bytea改为BYTEA大小写敏感并添加USING ENCODING UTF8声明关键查询字段强制加索引比如ACT_RU_TASK.ASSIGNEE_、ACT_RU_EXECUTION.PROC_DEF_ID_、ACT_HI_PROCINST.START_TIME_否则RuntimeService.createTaskQuery().taskAssignee(user123)这种基础查询会全表扫描。完整建表脚本精简版如下-- 创建流程定义表业务表非Activiti内置 CREATE TABLE process_definition ( id SERIAL PRIMARY KEY, definition_key VARCHAR(200) NOT NULL, version VARCHAR(50) NOT NULL, md5_hash CHAR(32) NOT NULL, xml_content TEXT NOT NULL, deploy_time TIMESTAMP WITH TIME ZONE DEFAULT NOW(), deploy_user VARCHAR(100), CONSTRAINT uk_definition_key_version UNIQUE (definition_key, version) ); -- Activiti运行时表精简关键字段 CREATE TABLE act_ru_execution ( id_ VARCHAR(64) NOT NULL PRIMARY KEY, rev_ INTEGER, proc_inst_id_ VARCHAR(64), business_key_ VARCHAR(255), proc_def_id_ VARCHAR(64), parent_id_ VARCHAR(64), act_id_ VARCHAR(255), is_active_ BOOLEAN DEFAULT TRUE, is_concurrent_ BOOLEAN DEFAULT FALSE, is_scope_ BOOLEAN DEFAULT FALSE, is_event_scope_ BOOLEAN DEFAULT FALSE, suspension_state_ INTEGER DEFAULT 1, cached_entity_state_ INTEGER, tenant_id_ VARCHAR(255) DEFAULT ); -- 必须加的索引实测提升10倍查询速度 CREATE INDEX idx_act_ru_task_assignee ON act_ru_task(assignee_); CREATE INDEX idx_act_ru_execution_procdef ON act_ru_execution(proc_def_id_); CREATE INDEX idx_act_hi_procinst_start ON act_hi_procinst(start_time_);执行完建表用psql -U activiti -d bpmn_db -f create-activiti-tables.sql导入。注意activiti是数据库用户名bpmn_db是库名这两个名字必须和application.properties里配置一致否则启动时报Table not found。4.3 Spring配置详解12个关键Bean的初始化顺序与作用Activiti的ProcessEngine不是简单new出来的它依赖10个核心服务Bean且初始化顺序极敏感。我按实际调试顺序列出最关键的12个Bean及其配置要点全部写在spring-context.xml里dataSourcePostgreSQL连接池用HikariCPmaximumPoolSize20超过20个连接PostgreSQL会拒绝transactionManagerDataSourceTransactionManager必须指定dataSource否则RuntimeService.startProcessInstanceByKey()事务不生效processEngineConfiguration继承StandaloneProcessEngineConfiguration重点设databaseSchemaUpdatetrue首次启动自动建表、historyLevelHistoryLevel.FULL记录所有历史、jobExecutorActivatefalse禁用内置定时任务用Quartz替代processEngineSpringProcessEngineConfiguration的子类重写buildProcessEngine()在返回前调用processEngine.getRepositoryService().createDeployment().addClasspathResource(diagrams/default.bpmn).deploy()预热第一个流程repositoryServiceprocessEngine.getRepositoryService()用于部署、查询流程定义runtimeServiceprocessEngine.getRuntimeService()用于启动、查询运行时流程taskServiceprocessEngine.getTaskService()用于任务分配、完成historyServiceprocessEngine.getHistoryService()用于查历史流程实例managementServiceprocessEngine.getManagementService()用于查作业JobidentityServiceprocessEngine.getIdentityService()用于用户/组管理我们不用Activiti自带的所以这里设为空实现formServiceprocessEngine.getFormService()用于表单渲染我们前端自己画所以设为nulldynamicBpmnServiceprocessEngine.getDynamicBpmnService()用于运行时修改流程定义高级功能按需启用。实操心得processEngineConfiguration的databaseSchemaUpdate设为true只在首次启动用后续升级必须改false否则每次重启都执行DDL可能删掉你加的业务索引。我见过有团队把true留着上线结果一次数据库维护后所有自定义索引全没了查询变慢10倍。4.4 前端集成bpmn-js与Spring后端的5个关键API对接bpmn-js本身不关心后端它只负责生成XML。我们要做的是用5个REST API把它和Activiti串起来所有接口用/api/process/**前缀符合RESTful规范GET /api/process/diagram/{processDefinitionId}返回流程图PNG从RepositoryService.getProcessDiagram()获取字节数组转Base64POST /api/process/deploy接收前端传来的XML经BpmnXmlValidator校验后调用repositoryService.createDeployment().addString(...).deploy()GET /api/process/definitions查询所有已部署流程返回ListProcessDefinition字段精简为id,key,name,version,deployTimePOST /api/process/start接收{processDefinitionKey: leave-process, variables: {userId: u123, departmentId: d456}}调用runtimeService.startProcessInstanceByKey()GET /api/process/tasks?assignee{userId}查询当前用户待办返回ListTask字段包括id,name,createTime,processDefinitionKey。关键点在于跨域处理。bpmn-js前端通常跑在http://localhost:8080而后端API在http://api.example.com必须在Spring配置里加CORSmvc:cors mvc:mapping path/api/** allowed-origins* allow-credentialstrue max-age3600 / /mvc:cors实测发现如果allowed-origins写*Chrome会拒绝带withCredentials的请求所以生产环境必须写具体域名比如allowed-originshttps://workflow.example.com。5. 常见问题排查与避坑指南那些文档里不会写的实战教训5.1 流程启动后卡在“startEvent”任务列表查不到任何待办这是新手最高频的问题。现象是调用runtimeService.startProcessInstanceByKey(leave-process)返回成功但taskService.createTaskQuery().taskAssignee(user123).list()永远为空。原因几乎100%是流程图里startEvent没连出去。Activiti要求startEvent必须有且仅有一条outgoing连线指向下一个节点。但bpmn-js默认画的startEvent是孤立的用户必须手动拖一条线连到userTask。很多前端同学以为“画完就完事”忘了连线。排查方法很简单用repositoryService.getBpmnModel(leave-process:1:abcd1234)拿到BpmnModel对象遍历所有StartEvent检查startEvent.getOutgoingFlows().size() 1。我在Controller里加了这个校验private void validateStartEvent(BpmnModel model) { for (Process process : model.getProcesses()) { for (FlowElement element : process.getFlowElements()) { if (element instanceof StartEvent) { StartEvent startEvent (StartEvent) element; if (startEvent.getOutgoingFlows().size() ! 1) { throw new IllegalStateException(StartEvent must have exactly one outgoing flow); } } } } }加在部署前用户上传的流程图如果有问题直接前端报错“启动事件未连接请拖拽连线到下一个节点”。5.2 并发部署流程定义时数据库死锁导致HTTP 500Activiti的createDeployment()内部会锁ACT_GE_BYTEARRAY表当多个请求同时部署PostgreSQL的行锁会升级为表锁。我们压测时10个并发请求3个失败报ERROR: deadlock detected。解法是加分布式锁。不用Redis用PostgreSQL的pg_advisory_xact_lock()函数轻量且强一致性Transactional public Deployment deployProcess(String xmlContent) { // 获取MD5哈希 String md5 DigestUtils.md5Hex(xmlContent); // 用MD5的hashCode做 advisory lock key避免key超长 long lockKey Math.abs(md5.hashCode()); // 执行 advisory lock事务级自动释放 jdbcTemplate.update(SELECT pg_advisory_xact_lock(?), lockKey); // 再查业务表确认是否已存在 ProcessDefinition existing processDefinitionMapper.findByMd5(md5); if (existing ! null) { return repositoryService.createDeployment() .name(existing.getDefinitionKey() _v existing.getVersion()) .deploy(); } // 否则正常部署 return repositoryService.createDeployment() .addString(process.bpmn, xmlContent) .deploy(); }这个锁粒度是“每份XML一个锁”不影响不同流程的部署实测100并发部署成功率100%平均耗时从1200ms降到320ms。5.3 流程图PNG生成模糊节点文字看不清Activiti用Apache Batik库渲染SVG转PNG但默认DPI是72而现代显示器是144。结果就是导出的PNG在Retina屏上全是马赛克。解法是重写ProcessDiagramGenerator。Activiti允许自定义生成器我们继承DefaultProcessDiagramGenerator重写generateProcessDiagram()方法public class HighDpiProcessDiagramGenerator extends DefaultProcessDiagramGenerator { Override public InputStream generateProcessDiagram(BpmnModel bpmnModel, String imageType, ListString highLightedActivities, ListString highLightedFlows, String activityFontName, String labelFontName, String annotationFontName, ClassLoader customClassLoader, double scaleFactor) { // 强制scaleFactor2.0提升两倍分辨率 return super.generateProcessDiagram(bpmnModel, imageType, highLightedActivities, highLightedFlows, activityFontName, labelFontName, annotationFontName, customClassLoader, 2.0); } }然后在processEngineConfiguration里配置property nameprocessDiagramGenerator refhighDpiProcessDiagramGenerator / bean idhighDpiProcessDiagramGenerator classcom.example.bpmn.generator.HighDpiProcessDiagramGenerator /效果立竿见影原来模糊的12px字体现在清晰锐利连流程线的箭头都棱角分明。5.4 生产环境CPU飙升100%线程堆栈显示卡在BpmnParse.execute()这是Activiti的XML解析器在解析超大流程图5MB时的已知问题。某个客户上传了一个包含200节点、嵌套5层子流程的巨图BpmnParse递归解析时栈溢出JVM疯狂GC。临时解法是加JVM参数限制栈大小-Xss512k默认1MB避免单线程吃光CPU长期解法是前端强制校验。bpmn-js有个canvas.getZoom()方法可以算出当前画布缩放比例再结合canvas.getSize()就能估算出用户实际画的节点数。我们在保存前加校验// 前端js function validateProcessSize() { const canvas modeler.get(canvas); const zoom canvas.getZoom(); const size canvas.getSize(); // 粗略估算节点数画布面积 * 缩放系数 const estimatedNodes (size.width * size.height) * zoom * 0.001; if (estimatedNodes 100) { alert(流程图过大预估节点数 Math.round(estimatedNodes) 请拆分为多个子流程); return false; } return true; }这个估算虽不精确但足够拦截99%的巨型流程图比后端解析失败再报错用户体验好太多。6. 运维监控与持续演进如何让这套系统三年不落伍部署上线只是开始。我给客户做的运维方案核心就两条可观测性先行演进路径清晰。6.1 四层监控体系从JVM到业务指标的全栈覆盖JVM层用Prometheus JMX Exporter采集java_lang_Memory、java_lang_Threading重点关注Thread.getState().WAITING线程数超过200说明有锁竞争数据库层PostgreSQL的pg_stat_statements插件每小时抓一次TOP 10慢SQL比如SELECT * FROM ACT_RU_TASK WHERE ASSIGNEE_ ?如果平均耗时500ms立刻加索引Activiti层用ManagementService.createJobQuery().executable().count()监控积压作业数超过1000触发告警说明定时任务没跑起来业务层在RuntimeService.startProcessInstanceByKey()前后打日志统计processDefinitionKey、startTime、endTime计算P95流程启动耗时超过3秒就要查瓶颈。所有监控数据推送到Grafana做成一张Dashboard运维同学一眼就能看出是“流程卡住了”还是“数据库慢了”。6.2 三年演进路线图从单体到微服务的平滑过渡这套系统不是一锤子买卖。我给客户的演进建议分三步第一年稳保持单体架构但把process_definition业务表和Activiti的ACT_*表物理隔离不同schema为后续拆分留余地第二年分将流程执行RuntimeService、任务处理TaskService、历史查询HistoryService拆成三个独立Spring Boot服务共享同一个PostgreSQL集群用spring-cloud-starter-loadbalancer做服务发现第三年云流程定义管理RepositoryService迁移到Kubernetes用ConfigMap存BPMN XML每次更新ConfigMap触发滚动发布实现真正的GitOps。每一步都保证API契约不变前端bpmn-js调用的/api/process/**接口地址、参数、返回格式全都不变。客户技术团队反馈按这个节奏走两年内没动过一行前端代码只升级了后端服务。最后分享一个小技巧Activiti的ProcessEngine是线程安全的但RepositoryService等子服务不是。所以千万别在Controller里Autowired private RepositoryService repositoryService;而应该每次用processEngine.getRepositoryService()获取新实例。我见过有团队为省事这么写结果高并发下出现NullPointerException查了三天才发现是单例Bean被多线程污染。记住引擎是单例服务是每次取——这是Activiti最朴素也最容易被忽略的真理。
