1. 为什么要在微服务里单独搞一个流程引擎模块?
大家好,我是老王,一个在Java后端和微服务领域摸爬滚打了十来年的老码农。最近几年,我发现在很多企业级应用里,工作流引擎的需求越来越普遍,比如OA审批、订单处理、工单流转这些场景。以前我们可能会用一些简单的状态机,或者干脆硬编码流转逻辑,但随着业务越来越复杂,这种做法的维护成本高得吓人,改个流程跟重写一遍代码似的。
所以,引入一个成熟的流程引擎就成了刚需。Flowable 作为 Activiti 的一个分支,这几年发展得挺不错,社区活跃,文档也相对齐全,特别是对 Spring Boot 的支持非常友好。我这次选的是 Flowable 7.1.0 和 Spring Boot 3.2.0 的组合,算是比较新的版本,能享受到 Java 17 和新框架特性带来的红利。
那为什么非要单独建一个模块呢?这其实是我在微服务架构里踩过坑之后的经验。如果你把流程引擎的代码直接塞进某个业务服务里,比如用户服务或者订单服务,初期是省事了,但后期会非常痛苦。想象一下,当你的请假审批、报销审批、合同审批都需要流程时,难道每个服务都集成一遍 Flowable 吗?数据库表、配置、API 都会重复,维护起来简直是噩梦。
因此,我的思路是模块化、服务化。创建一个独立的 pm-process(流程服务)模块,让它专门负责所有和流程相关的“发动机”工作。其他业务服务,比如 pm-system(系统服务),只需要通过 HTTP 或 RPC 调用这个流程服务提供的接口就行了。这样职责清晰,也方便未来对流程引擎本身进行升级或替换。接下来,我就手把手带你,在一个已有的 Spring Cloud 微服务脚手架里,把这个流程引擎模块从零搭建起来。
2. 环境与依赖准备:打好地基才能盖高楼
在开始敲代码之前,咱们得先把“地基”打好。这里的地基,指的就是项目依赖和版本管理。版本不一致是集成过程中最常见的坑,我强烈建议你跟着我的版本走,成功跑起来之后,再根据自己的情况调整。
2.1 父工程 POM 的关键配置
我是在一个已有的微服务父工程(eal-pm)里增加模块。父工程的核心作用就是统一管理所有子模块的依赖版本,避免冲突。下面是我在父 POM 的 <properties> 和 <dependencyManagement> 里添加的关键配置,你重点看 Flowable 和 Spring Boot 相关的部分:
<properties>
<!-- 其他版本定义... -->
<springboot.version>3.2.0</springboot.version>
<springcloud.version>2023.0.0</springcloud.version>
<mysql.version>8.0.33</mysql.version>
<mybatis-plus.version>3.5.9</mybatis-plus.version>
<!-- Flowable 7.1.0 版本定义 -->
<flowable.version>7.1.0</flowable.version>
</properties>
<dependencyManagement>
<dependencies>
<!-- Spring Boot 依赖管理 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${springboot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- Flowable Spring Boot 启动器 -->
<dependency>
<groupId>org.flowable</groupId>
<artifactId>flowable-spring-boot-starter</artifactId>
<version>${flowable.version}</version>
</dependency&


1万+

被折叠的 条评论
为什么被折叠?



