4. 平台架构概览：采购管理平台的整体技术架构、审批工作流引擎的位置、超时监控模块的集成方式
本章从平台整体技术架构出发，定位审批工作流引擎与超时监控模块在系统中的层级关系。理解这一架构是后续配置超时自动转审机制的基础，也是运维排错与性能调优的必备知识。
4.1 采购管理平台整体技术架构
平台采用微服务 + 事件驱动架构，核心分为四层：接入层、业务服务层、流程与规则层、数据与基础设施层。审批工作流引擎与超时监控模块均位于流程与规则层，但职责不同。
| 架构层 | 核心组件 | 职责说明 |
|---|---|---|
| 接入层 | API 网关、SSO、消息推送 | 统一认证、请求路由、限流熔断、移动端/PC 端适配 |
| 业务服务层 | 采购订单、供应商、合同、库存等微服务 | 业务数据管理与业务规则校验，通过事件驱动触发流程 |
| 流程与规则层 | 审批工作流引擎、超时监控模块、规则引擎 | 流程编排、节点路由、超时检测、自动转审、决策表执行 |
| 数据与基础设施层 | MySQL 集群、Redis、Elasticsearch、消息队列 | 持久化、缓存、搜索、异步解耦、日志审计 |
架构要点： 审批工作流引擎与超时监控模块同属流程与规则层，但超时监控模块以“旁路监听”方式集成，不阻塞主流程路径，避免因监控逻辑故障导致审批卡死。
4.2 审批工作流引擎的位置与职责
审批工作流引擎是流程与规则层的核心，负责解析 BPMN 2.0 流程定义、驱动节点流转、维护流程实例状态。引擎内部包含以下关键组件：
- 流程定义解析器： 加载 BPMN 文件，构建流程模型缓存。
- 令牌管理器： 维护每个流程实例的当前节点位置与变量上下文。
- 任务分配器： 根据候选人/候选组策略，将审批任务推送到待办列表。
- 事件监听器： 捕获流程事件（如任务创建、完成、超时），触发外部动作。
- 历史归档器： 将已完成的流程实例写入历史表，支持审计追溯。
引擎通过消息队列与业务服务层解耦：业务服务提交“启动流程”事件，引擎消费后创建实例；审批完成后引擎发布“流程完成”事件，业务服务消费后更新单据状态。
4.3 超时监控模块的集成方式
超时监控模块并非嵌入工作流引擎内部，而是以事件监听 + 定时扫描双机制集成：
- 事件监听机制： 引擎在任务创建时发布
TaskCreatedEvent，超时监控模块消费该事件，在 Redis 中记录任务超时截止时间戳（任务创建时间 + 节点配置的超时阈值）。 - 定时扫描机制： 独立的调度线程每 30 秒扫描 Redis 中的超时任务集合，将已超时且未完成的任务标记为“超时待转审”，并调用引擎 API 执行转审操作。
- 补偿机制： 若 Redis 宕机或事件丢失，每日凌晨执行全量数据库扫描，补偿处理遗漏的超时任务。
设计考量： 采用“事件驱动 + 定时补偿”双机制，既保证了超时检测的实时性（秒级响应），又通过补偿机制兜底，避免单点故障导致超时漏检。生产环境建议将 Redis 超时集合的 TTL 设置为节点超时阈值的 1.5 倍，防止任务提前过期。
4.4 超时监控模块与引擎的协作流程
以下时序图展示一次完整的超时检测与自动转审过程：
4.5 关键集成参数与配置项
超时监控模块的集成行为由以下核心参数控制，这些参数在平台配置中心统一管理：
| 参数名 | 默认值 | 说明 |
|---|---|---|
timeout.scan.interval |
30 | 定时扫描间隔，单位秒 |
timeout.redis.ttl.factor |
1.5 | Redis 超时集合 TTL = 节点超时阈值 × 该系数 |
timeout.compensation.enabled |
true | 是否启用每日全量补偿扫描 |
timeout.compensation.cron |
0 0 3 * * ? | 补偿扫描的 cron 表达式，默认凌晨 3 点 |
timeout.auto.escalate |
true | 超时后是否自动转审至上级审批人 |
生产注意事项： 若 Redis 集群发生主从切换，可能导致超时集合数据短暂不一致。建议为超时监控模块配置独立的 Redis 实例或至少使用专有 db 分区，避免与其他业务缓存混用影响超时检测的实时性。