架构师如何进行引擎技术选型?

0 阅读5分钟

沉默是金,总会发光

大家好,我是沉默

打开一个项目技术方案,你可能会看到一堆听起来很高级的词:

  • 流程引擎(Flowable / Camunda)
  • 工作流(Activiti)
  • 规则引擎(Drools)
  • 编排系统(LiteFlow)
  • 表达式引擎(QLExpress / Aviator)
  • DAG 调度(Airflow / DolphinScheduler)
  • 服务编排(Temporal / Conductor)

还有:

  • BPMN

  • Saga

  • Event-Driven

每个框架都说自己能解决问题。
每个概念看起来都差不多。

结果就是:

新人一脸懵。
老程序员也经常搞混。

说句实话:

干了十年开发,我自己也被这些名词绕晕过。

后来才发现,

很多技术选型,本质只需要回答四个问题。

不用背概念。
不用看架构图。

**
**

问完四个问题,答案基本就出来了。

**-**01-

1-2

第一问:你是在“改状态”,还是在“干活”?

这是 最重要的一道分水岭

很多系统看起来很复杂,但本质其实只有两种事情:

改状态
或者
干活

什么叫改状态?

举个最经典的例子:

请假审批。

流程是这样的:

员工提交申请

主管审批

HR审批

流程结束

这个过程中发生了什么?

没有计算
没有复杂逻辑
没有外部调用

只是:

pending → approved

本质就是:

状态流转

这种场景最适合的就是:

BPMN流程引擎

例如:

  • Flowable
  • Camunda
  • Activiti

它们本质就是:

一个可视化状态机。

什么叫干活?

再看电商订单流程:

下单

扣库存

调用支付

调用物流

这里发生了什么?

要计算金额
要调用API
要执行业务逻辑
要处理数据

这不是状态流转。

这是:

执行任务

所以如果你的系统主要是在 干活
就继续问第二个问题。

图片

第二问:主要是人处理,还是机器执行?

很多流程的区别,其实就在这里。

人处理流程

例如审批流程:

主管查看材料

主管判断

主管点击按钮

整个流程最大的特点是:

系统在等人。

典型场景:

  • 请假审批
  • 报销审批
  • 合同审批

这种系统本质是:

流程管理系统

推荐:

  • Flowable
  • Camunda

机器执行流程

例如数据任务:

读取数据库

清洗数据

转换格式

写入目标表

整个流程:

不需要人参与。

完全由机器执行。

这种场景就属于:

任务调度系统

典型工具:

  • Apache Airflow
  • Apache DolphinScheduler

它们的核心是:

DAG(任务依赖图)

任务A完成 → 才能执行任务B。

图片

- 02-

3-4

第三问:是本地逻辑,还是跨系统调用?

这一步决定:

你需要 规则引擎
还是 服务编排系统

本地逻辑

例如营销规则:

判断用户是否VIP

计算折扣

返回价格

所有逻辑都在:

一个服务内部

这时候最合适的是:

表达式 / 规则引擎

例如:

  • QLExpress
  • Aviator
  • Drools
  • LiteFlow

优点是:

规则可以动态修改
不用重新发版。

跨系统调用

例如订单流程:

调用库存服务

调用支付服务

调用物流服务

这时候问题就变成:

分布式流程管理

典型技术:

  • Temporal
  • Netflix Conductor

这种系统通常支持:

  • Saga事务
  • 重试机制
  • 补偿机制
  • 长流程恢复

图片

第四问:只是自己用,还是做平台?

这个问题很多人会忽略。

但其实非常关键。

自己团队使用

特点:

规则自己写
代码自己维护

这种情况:

表达式引擎就够了:

  • QLExpress
  • Aviator

做平台生态

如果你的系统是:

客户上传脚本
第三方扩展功能
支持插件机制

那就需要:

脚本 + 沙箱 + 插件体系

常见方案:

  • Groovy脚本

  • 插件机制

  • 动态扩展

图片

- 03-

程序员最常踩的三个坑

1 追求企业级架构

错误:

20人公司

Flowable + Airflow + Temporal

正确:

100行代码解决

2 为了灵活牺牲性能

错误:

所有逻辑写 Groovy

正确:

核心逻辑 Java
可变逻辑配置化

3 过度抽象

错误:

3个流程
上一个流程引擎

正确:

3个流程
写3个方法

图片

**-****04-**总结

很多架构问题,其实没有那么复杂。

真正复杂的是:

过度设计。

给你三个建议。

第一:

先用最简单方案。

很多需求:

100行代码就能解决。

第二:

出现瓶颈再升级。

正确顺序是:

代码

配置化

框架

而不是反过来。

第三:

技术必须为业务服务。

不要为了:

企业级
先进架构
高扩展

而去设计系统。

很多时候:

简单就是最好的架构。

图片

热门文章

一套能保命的高并发实战指南

架构师必备:用 AI 快速生成架构图

**-****05-**粉丝福利

我这里创建一个程序员成长&副业交流群, 


 和一群志同道合的小伙伴,一起聚焦自身发展, 

可以聊:


技术成长与职业规划,分享路线图、面试经验和效率工具, 




探讨多种副业变现路径,从写作课程到私活接单, 




主题活动、打卡挑战和项目组队,让志同道合的伙伴互帮互助、共同进步。 




如果你对这个特别的群,感兴趣的, 
可以加一下, 微信通过后会拉你入群, 
 但是任何人在群里打任何广告,都会被我T掉。