2. 业务骨架定义：什么是企业业务系统骨架？核心模块的职责划分
企业业务系统骨架（Business System Skeleton）并非一个具体的开源框架或中间件，而是一种架构模式。它定义了在审批流、订单流、工单流等长周期、多步骤、跨服务的业务场景中，用于支撑业务稳定运行、处理异常与恢复一致性的最小必要结构。这个骨架由三个核心模块构成：流程引擎、状态机和补偿管理器。
如果把企业业务系统比作一栋大楼，那么骨架就是它的承重墙与管线系统——平时看不见，但一旦发生地震（异常），它决定了大楼是整体坍塌还是局部修复。
2.1 核心模块职责总览
三个模块各司其职，共同构成业务骨架的“铁三角”。下表清晰划分了它们的核心职责与关注点：
| 模块 | 核心职责 | 关注点 | 类比 |
|---|---|---|---|
| 流程引擎 | 编排业务步骤，驱动任务流转 | “下一步做什么？”——顺序、并行、条件分支 | 交响乐指挥 |
| 状态机 | 管理业务对象生命周期，确保状态合法 | “当前是什么状态？”——状态定义、事件、转移规则 | 交通信号灯 |
| 补偿管理器 | 处理失败步骤，执行回滚或修复 | “出错了怎么办？”——补偿动作、重试策略、事务边界 | 消防系统 |
架构原则：流程引擎负责“正向流”，状态机负责“状态合法性”，补偿管理器负责“逆向流”。三者解耦，但通过事件或回调紧密协作。任何业务骨架的设计，都应首先明确这三个模块的边界。
2.2 流程引擎：业务步骤的编排者
流程引擎是骨架的大脑。它不关心业务对象的具体数据，只关心任务节点的流转逻辑。在审批流中，流程引擎负责：
- 节点解析：读取流程定义（如 BPMN、JSON 或 DSL），解析出审批节点、会签节点、条件网关。
- 任务分发：将待办任务推送给指定的审批人、角色或服务。
- 路由决策：根据条件表达式（如金额 > 10000 需总监审批）决定下一步走向。
- 超时与重试：当任务长时间未处理时，触发超时策略（自动跳过、转交或驳回）。
典型的流程引擎实现包括 Activiti、Flowable、Camunda，但在企业自研骨架中，更常见的是轻量级状态驱动引擎，避免引入过重的 BPMN 依赖。
2.3 状态机：业务对象的生命周期守护者
状态机是骨架的神经系统。它确保每一个业务对象（如“审批单”、“订单”）的状态变迁是合法且可追溯的。状态机通常包含以下要素：
- 状态（State）：业务对象的稳定阶段，如“草稿”、“审批中”、“已通过”、“已驳回”。
- 事件（Event）：触发状态转移的动作，如“提交审批”、“审批通过”、“驳回”。
- 转移（Transition）：从当前状态到目标状态的规则，包含前置条件与后置动作。
- 动作（Action）：状态转移时执行的业务逻辑，如“发送通知”、“更新库存”。
常见陷阱：很多团队将状态逻辑散落在 Service 层的 if-else 中，导致状态转移不可控、不可审计。状态机必须集中管理，且状态转移表应作为配置而非代码硬编码。
2.4 补偿管理器：事务一致性的最后防线
补偿管理器是骨架的免疫系统。在分布式系统中，无法保证所有步骤都成功，补偿管理器负责在失败时执行逆向操作，将系统恢复到一致状态。其核心职责包括：
- 补偿动作注册：每个正向步骤都必须注册对应的补偿动作（如“扣减库存”对应“释放库存”）。
- 失败检测与触发：当流程引擎报告某步骤失败，或状态机检测到非法状态时，启动补偿流程。
- 补偿执行与重试：按逆序执行补偿动作，支持幂等重试，直到补偿成功或达到最大重试次数。
- 补偿日志记录：记录每一次补偿的输入、输出、结果，用于人工介入审计。
2.5 三模块协作关系图
下图展示了在典型审批流中，三个模块如何协作完成一次完整的业务处理与异常恢复：
2.6 模块职责边界示例
以一个“采购审批单”为例，展示三个模块在具体业务中的职责边界：
- 流程引擎：定义审批步骤为“申请人提交 → 部门经理审批 → 财务审批 → 采购执行”。当部门经理审批通过后，引擎自动将任务推送给财务审批人。
- 状态机：审批单的状态变迁为“草稿 → 审批中 → 财务审批中 → 已通过”。当财务审批人点击“驳回”时，状态机拒绝从“财务审批中”转移到“已通过”，并触发事件让流程引擎执行驳回分支。
- 补偿管理器：假设财务审批通过后，采购执行步骤调用库存服务失败。补偿管理器执行：
1. 调用财务服务：回滚财务审批（将审批单状态恢复为“财务审批中”） 2. 调用部门经理服务：回滚部门审批（将审批单状态恢复为“部门审批中”） 3. 通知状态机：将审批单状态设置为“草稿”
关键设计决策：补偿管理器不直接操作业务数据，而是调用各服务的补偿接口。每个服务必须提供幂等的补偿 API，且补偿动作本身也要记录日志，形成完整的审计链路。
2.7 骨架设计的核心原则
在定义业务骨架时，需遵循以下原则：
- 职责单一：流程引擎不处理状态校验，状态机不负责任务分发，补偿管理器不参与正向流程。任何跨职责的耦合都会导致骨架僵化。
- 事件驱动：三个模块之间通过事件（Event）通信，而非直接 API 调用。例如，流程引擎发出“TaskCompleted”事件，状态机监听后更新状态，补偿管理器监听失败事件后启动补偿。
- 可观测性：每个模块都必须暴露健康检查、指标（如当前活跃流程数、状态转移次数、补偿成功率）和日志，便于运维人员快速定位问题。
- 可替换性：骨架不应绑定具体实现。例如，流程引擎可以从 Flowable 替换为自研引擎，只要保持对外接口不变，状态机和补偿管理器无需改动。