审批流系统技术架构如何设计？模块边界、扩展性与性能取舍

从模块边界到性能取舍：审批流架构的设计逻辑

企业级审批流系统不是简单的“提交-通过-驳回”三步走。当组织规模超过百人、流程分支超过二十种、日均审批量达到数千次时，架构设计中的每一个模块划分、每一层缓存策略、每一条消息队列的使用方式，都会直接影响系统的可维护性和响应速度。

本文从模块化、前后端交互、缓存、消息队列和扩展性五个维度展开，讨论架构设计中的关键决策点。不罗列技术名词，也不提供“万能方案”，而是给出基于项目经验的判断逻辑和取舍依据。

模块边界划分：核心引擎与业务解耦

审批流系统的核心矛盾在于：流程引擎需要通用，而业务节点需要定制。如果两者耦合在一起，每次新增业务都会修改引擎代码，最终导致系统无法维护。

**合理的做法是将系统拆为三层：**

• 流程定义层：负责节点、连线、条件、审批人规则的建模。这一层不感知具体业务，只处理图结构和状态机。推荐使用 BPMN 2.0 标准或简化后的有向图模型。关键接口是“根据流程定义 ID，执行一次流转”。
• 业务挂载层：每个节点可以挂载业务表单、回调函数、权限校验逻辑。这一层通过 SPI 或事件机制与流程引擎交互。引擎不直接调用业务代码，而是抛出事件或调用注册的处理器。
• 数据持久层：流程实例、任务实例、审批记录、操作日志。建议使用独立的数据源或至少独立的表空间，避免与业务表混用导致锁竞争。

这样划分后，新增一个“采购合同审批”时，只需要在业务挂载层注册新表单和校验逻辑，流程引擎无需修改。模块边界清晰后，单元测试和回归测试的范围也大幅缩小。

前后端分离下的状态同步

审批流的前端交互复杂度远高于普通 CRUD 页面。审批人需要看到“当前节点、历史轨迹、待办列表、可操作按钮”，而且这些状态会随着他人操作实时变化。如果前端只依赖页面刷新时拉取数据，用户体验会很差。

**推荐的前后端协作模式：**

• 后端提供 RESTful API 用于查询流程定义、启动流程、获取待办列表、提交审批意见。这些接口是无状态的，便于水平扩展。
• 对于“待办数”和“当前节点状态”这类高频变化的数据，使用 WebSocket 推送增量更新。推送内容只需包含“任务 ID”和“新状态”，前端根据 ID 更新本地缓存，避免全量刷新。
• 前端本地维护一个“操作乐观锁”：用户点击“通过”时，立即更新 UI 状态为“已提交”，同时发送请求。如果后端返回冲突（例如该任务已被其他人处理），前端再回滚状态并提示。

这种设计下，后端不需要为前端维护复杂的 session 状态，前端也能保证操作反馈的即时性。性能瓶颈通常出现在 WebSocket 连接数上，单个节点承载 5000 个长连接是常见上限，超出后需要引入 WebSocket 网关集群。

缓存策略：什么该缓存，什么不该缓存

审批流系统的缓存设计容易走两个极端：要么什么都不缓存，导致每次加载待办列表都要扫描全表；要么缓存所有数据，导致流程状态变更时缓存一致性问题频发。

从实践经验来看，以下数据适合缓存：

• 流程定义元数据：包括节点配置、连线规则、审批人角色映射。这些数据一旦发布就很少变更，TTL 可以设为 30 分钟或更长。变更时通过消息通知清除缓存。
• 用户权限与角色映射：审批人判断时需要频繁查询用户所属角色和部门，这部分数据可以缓存在 Redis 中，使用 Hash 结构存储，过期时间设为 5 分钟。
• 待办列表的计数：每个用户首页显示的“待审批数量”可以缓存，但具体列表内容不适合缓存。因为列表需要分页、排序、过滤，缓存命中率低且一致性维护复杂。计数缓存更新策略是：每次审批操作完成后，异步更新相关用户的计数。

以下数据不建议缓存：

• 审批实例的状态：状态变更频繁，且每次查询都需要最新的准确值。缓存带来的性能收益不足以弥补一致性问题。
• 审批意见和附件：这类数据写入后极少读取，且读取时通常需要全文检索，缓存意义不大。

缓存粒度上，优先使用“单条”而非“列表”。例如缓存“流程定义 ID -> 定义对象”比缓存“用户 ID -> 待办列表”更稳定。

消息队列在审批流中的三种用法

消息队列（如 RabbitMQ、Kafka）在审批流系统中不是必选项，但当系统达到一定规模后，它是解耦和削峰的关键工具。根据项目经验，消息队列主要解决三个问题：

**1. 异步通知与事件驱动**

审批状态变更后，需要通知多个下游系统：发送邮件、更新企业微信消息、触发第三方系统接口、记录审计日志。如果这些操作都在审批请求的同步链路中完成，接口响应时间会从 50ms 飙升到 2s 以上。正确做法是：审批操作完成后，只更新数据库状态，然后发送一条“审批完成事件”到消息队列。消费者各自处理自己的逻辑，互不影响。

**2. 高并发下的任务分配**

当数千人同时发起审批时，任务分配逻辑（例如“按角色轮询分配审批人”）可能成为瓶颈。将分配请求写入消息队列，由后台 worker 批量处理，可以平滑处理峰值。需要注意的是，任务分配通常要求顺序性（例如同一流程实例的任务必须依次分配），此时应使用分区键（如流程实例 ID）确保同实例的任务进入同一队列分区。

**3. 数据最终一致性**

跨服务的事务场景（例如审批通过后需要扣减库存），不能依赖分布式事务。使用“本地消息表 + 消息队列”模式：审批服务先写入本地消息表，再发送消息；库存服务消费消息后执行扣减，成功后确认消息。如果扣减失败，库存服务发送补偿消息，审批服务回滚状态。这种方案比 TCC 或 Saga 更容易实现，且对业务侵入性小。

消息队列引入的代价是运维复杂度增加。如果团队没有专职运维人员，建议优先使用云服务商提供的消息队列托管服务，避免自建。

扩展性设计：流程模板与动态节点

审批流系统的扩展性常常被误解为“支持所有流程类型”，这会导致引擎过于复杂。实际项目中，90% 的扩展需求集中在以下三个方面：

**1. 动态审批人规则**

审批人不是固定的“张三”或“经理角色”，而是根据业务数据动态计算。例如“金额超过 10 万元的采购单需要 CFO 审批”，这里的“CFO”需要根据当前组织架构实时查找。设计时，审批人解析器应该做成可插拔的，每种解析规则（按角色、按部门负责人、按申请人上级、按自定义脚本）注册为独立实现类。新增规则时不需要修改引擎。

**2. 条件分支的扩展**

条件判断逻辑（例如“如果金额大于 5 万走 A 分支，否则走 B 分支”）需要支持动态表达式。常见方案是集成 Groovy 或 MVEL 脚本引擎，将条件表达式存储在流程定义中，运行时动态求值。安全方面需要限制脚本执行时间和可调用的类白名单，防止恶意脚本。

**3. 节点超时与自动处理**

超过指定时间未审批的节点，需要自动转交、升级或跳过。实现方式有两种：一是使用定时任务扫描超时任务，二是使用延时消息队列（如 RabbitMQ 的 TTL 或 Redis 的 Keyspace Notification）。延时消息队列的实时性更好，但需要处理消息丢失后的补偿扫描。两种方案可以结合使用：延时消息作为主要触发，定时扫描作为兜底。

性能取舍：读写分离与索引设计

审批流系统的性能瓶颈通常出现在“待办列表查询”和“历史审批记录查询”上。前者是高频写入（审批操作）与高频读取（用户刷新待办）的冲突，后者是数据量膨胀后的全表扫描问题。

**待办列表查询优化：**

核心思路是减少扫描范围。不要查询“所有待办任务”，而是查询“当前用户在当前节点上的待办任务”。索引设计为联合索引：(审批人 ID, 节点状态, 流程实例创建时间)。如果审批人角色是动态的（例如“部门经理”），则需要将角色解析结果缓存或预计算，不能在查询时动态解析。

当单表数据量超过 500 万行时，考虑按流程实例的创建时间做范围分区（例如按月分区）。查询待办时带上时间范围条件，可以快速定位到少数分区。

**历史审批记录查询优化：**

历史数据通常用于审计和报表，对实时性要求低。建议将超过 30 天的已完结流程实例迁移到历史表或归档数据库。归档后，主表只保留活跃流程，查询性能大幅提升。归档操作使用定时任务，在业务低峰期执行。

读多写少的场景（例如报表统计），可以使用只读副本。但需要注意，审批流系统对数据一致性要求较高（例如“用户刚刚驳回的流程，不应该在报表中显示为通过”），因此只读副本的延迟必须控制在 1 秒以内，否则会导致业务逻辑错乱。

部署与运维：单体起步，按需拆分

不少团队一开始就设计微服务架构，结果引入服务发现、分布式事务、链路追踪等复杂度，项目进度被拖垮。对于大多数企业级审批流系统，单体架构配合读写分离，足以支撑日均 1 万次审批操作。当业务量增长到需要拆分时，优先拆分“通知服务”和“归档服务”，这两个模块与核心流程的耦合度最低。

部署时，建议将流程引擎与业务应用部署在同一进程内，减少网络延迟。如果必须拆分（例如流程引擎需要独立升级），使用 gRPC 或 HTTP 长连接通信，避免每次流转都建立新连接。

监控方面，重点监控以下指标：

• 流程实例创建速率（峰值时是否超过数据库写入能力）
• 待办列表查询的 P99 延迟（超过 500ms 需要优化索引或缓存）
• 消息队列的堆积数量（堆积超过 1 万条时触发告警）
• WebSocket 连接数和重连频率（异常断开可能表明网络或服务不稳定）

在 SystemDo 参与的一个制造企业审批流项目中，我们采用了上述的单体+消息队列架构，初期支撑了 800 人的日常审批，后续通过拆分通知服务和引入只读副本，扩展到了 3000 人规模，整个过程中没有重构核心引擎。

总结：架构决策的本质是权衡

审批流系统的架构没有银弹。模块边界清晰是为了应对业务变化，缓存是为了降低数据库压力，消息队列是为了解耦和削峰，索引设计是为了查询性能。每一个决策都有代价：缓存增加一致性维护成本，消息队列增加运维复杂度，索引增加写入开销。

架构师的工作不是选择“最好的技术”，而是在当前团队能力、业务规模和未来预期下，找到最合适的平衡点。对于大多数企业来说，一个设计良好的单体应用，配上合理的缓存和消息队列，比一个过度设计的微服务架构更可靠、更易维护。