Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

第 5 章 长生命周期业务流程方法论：状态机、编排、审批与恢复

本章讨论的不是“某个关键节点怎么一次性做对”，而是“一个业务对象如何在多个阶段中被持续推进、暂停、回退、超时、审批、恢复和审计”。读完这一章，你应该能区分：什么问题只是一个大事务，什么问题已经演化成长生命周期业务流程，以及状态机、Workflow、事件驱动和人工介入分别该放在什么位置。

上一章讲的是大事务。大事务解决的是一个关键时刻的一致性问题，例如创单时锁库存、占优惠、落订单，或者发布时更新主数据、推送索引、发送事件。

这一章讨论的是另一个层次的问题：

当一个业务对象要跨创单、支付、履约、售后，或者跨 Draft、审核、发布、下线等多个阶段持续推进时，系统该如何管理它的生命周期。

这里要明确一个边界：

  • 大事务，关注的是某个关键业务动作怎么最终收敛。
  • 长生命周期业务流程，关注的是业务对象如何跨阶段推进、治理和恢复。
  • Workflow，只是长生命周期业务流程的一种实现手段，而不是总概念本身。

例如：

  • 订单从创单到支付、履约、售后，是长生命周期业务流程。
  • 其中“创单”这一步里的锁库存、占优惠、落订单，是大事务。
  • 商品从 Draft -> QC Approval -> Publish -> Unpublish，也是长生命周期业务流程。
  • 其中 Publish 节点内部的数据更新与下游同步，则可能用 Saga 处理。

5.1 什么叫长生命周期业务流程

长生命周期业务流程，指的是一个业务对象不会在一次请求内闭环完成，而是要跨多个阶段、多个系统、多个角色、多个时间窗口持续推进。

它通常具有几个共同特征：

  1. 有明确阶段：例如待创建、待支付、待履约、已完成。
  2. 有等待点：要等用户支付、等供应商响应、等人工审批、等外部回调。
  3. 有角色切换：用户、系统、运营、客服、风控、审核员都可能参与。
  4. 有暂停与恢复：流程可能挂起几分钟、几小时，甚至几天。
  5. 有治理要求：必须知道现在走到哪一步、为什么卡住、谁能继续推进。

所以长生命周期业务流程的核心问题不是“接口怎么调”，而是：

如何让业务对象在跨时间、跨角色、跨系统的现实里，仍然保持可解释、可推进、可恢复。

5.2 为什么不能用大事务思维替代长流程思维

很多团队在系统早期，会把所有复杂问题都理解成“大事务再加几个状态”。这在短期内看起来省事，但一旦流程拉长，就会开始失控。

原因在于，大事务和长流程关注的是两个不同的问题：

维度大事务长生命周期业务流程
关注对象一个关键业务动作一个业务对象的完整生命周期
时间跨度通常秒级到分钟级分钟、小时、天甚至更长
核心问题如何最终一致如何持续推进与治理
典型能力补偿、幂等、回滚、对账状态流转、审批、超时、人工介入、恢复
实现手段Saga、TCC、Outbox状态机、Workflow、编排器、事件驱动

如果把长流程只当成一个加长版大事务，通常会出现几类问题：

  • 把所有状态都塞进一个“超大 Saga”里，最后没人能解释流程边界。
  • 为了等支付、等审核、等供应商，长期持有“事务进行中”的语义，系统状态越来越脆弱。
  • 审批、驳回、重提、超时取消、人工补单这些动作没有被建模成正式流转，只能靠脚本和人工改库兜底。

所以必须建立一个判断：

当问题的核心从“这一步怎么做对”变成“整个生命周期怎么治理”时，就应该切换到长流程方法论。

5.3 哪些场景天然属于长生命周期业务流程

5.3.1 订单生命周期管理

订单并不是“创单成功”就结束，而是会继续进入：

  • 创单
  • 支付
  • 风控审核
  • 履约
  • 签收
  • 售后
  • 关闭

这里的复杂度主要来自：

  • 每个阶段都可能由不同系统主导。
  • 支付和履约之间有明显等待点。
  • 售后、退款、逆向履约会把流程重新拉回中间阶段。
  • 客服、运营、仓库都可能参与人工处理。

所以订单本质上是一个长生命周期业务对象。

5.3.2 商品生命周期管理

商品系统里也经常有类似链路：

  • Draft
  • Editing
  • Submitted
  • QC Approval
  • Published
  • Archived 或 Unpublished

它的复杂度来自：

  • 商家编辑可能持续几天。
  • 审核节点通常需要人工或半自动处理。
  • 审核不通过会退回前一个阶段。
  • 发布后还会涉及搜索、推荐、详情、运营活动等下游同步。

这显然不是一个大事务，而是一个典型的生命周期流程。

5.3.3 退款、入驻、审批与结算流程

还有一些场景天然带有流程属性：

  • 退款申请 -> 审核 -> 退款执行 -> 回写结果
  • 商家入驻 -> 资料提交 -> 风控校验 -> 合同审批 -> 开店
  • 账单生成 -> 对账 -> 差异确认 -> 结算付款

这些流程的共同点是：

  • 阶段边界清晰。
  • 等待和审批很多。
  • 经常需要人工接管。
  • 需要正式审计记录。

5.4 长流程系统真正要设计的是什么

很多人说“我们上个 Workflow 就好了”，但这句话跳过了最关键的设计层。

长流程系统真正要设计的，不是某个引擎，而是下面这几件事。

5.4.1 流程阶段

先定义清楚业务对象一生要经历哪些阶段。

例如订单可以是：

  • PENDING_CREATE
  • PENDING_PAYMENT
  • PAYMENT_PROCESSING
  • PENDING_FULFILLMENT
  • IN_FULFILLMENT
  • COMPLETED
  • CANCELLED

例如商品可以是：

  • DRAFT
  • SUBMITTED
  • UNDER_REVIEW
  • REJECTED
  • PUBLISHED
  • UNPUBLISHED

没有阶段定义，就不会有后面的治理能力。

5.4.2 流转规则

不是所有状态都能互相跳转。系统必须显式定义：

  • 哪些状态可以进入下一个状态
  • 哪些状态允许回退
  • 哪些状态只能人工推进
  • 哪些状态在超时后自动转移

这一步本质上是在设计生命周期状态机。

5.4.3 等待点与唤醒条件

长流程一定会遇到等待：

  • 等支付回调
  • 等审核员处理
  • 等物流回传
  • 等外部系统补数

每个等待点都必须回答：

  1. 等的是什么事件？
  2. 最长等多久？
  3. 超时后转到什么状态？
  4. 谁有权限继续推进？

5.4.4 人工介入与审计

长流程一旦进生产，人工介入几乎不可避免。真正成熟的设计不会回避它，而是会把它纳入正式模型：

  • 谁可以审批、驳回、跳过、重试、关闭
  • 每次人工动作是否有理由、操作者和时间
  • 哪些动作需要双人复核
  • 人工介入后如何恢复自动推进

也就是说，人工介入不是“系统失败后的非正式补丁”，而是流程治理的一部分。

5.5 四种主流实现路线

围绕长生命周期业务流程，常见实现路线大致有四种。

5.5.1 纯数据库状态机

做法是把生命周期状态放在业务主表里，由应用服务按规则推进。

优点：

  • 简单直接。
  • 与业务模型贴合。
  • 适合阶段有限、主控方明确的流程。

缺点：

  • 流程一复杂，状态转移逻辑会散落在多个服务里。
  • 超时、审批、回放、观察能力需要自己补齐。
  • 长期容易演化成一堆难维护的条件分支。

它适合较短但明显分阶段的流程。

5.5.2 应用层编排器

做法是引入一个专门的 Orchestrator，由它负责推进主流程，业务服务负责完成各节点动作。

优点：

  • 主流程视角更清晰。
  • 超时、重试、补偿、通知更容易集中治理。
  • 很适合订单履约、退款审批、发布编排这类主控方明确的流程。

缺点：

  • 编排器本身会成为一个复杂系统。
  • 状态、权限、审计、重试策略都要认真设计。

它适合流程复杂度已经超出单个业务服务承载能力的场景。

5.5.3 Workflow 引擎

做法是把流程状态持久化、等待、超时、回放、人工任务等能力，进一步交给专门的工作流系统承载，例如 Temporal、Camunda、Zeebe。

优点：

  • 对长期运行流程很友好。
  • 更容易提供可视化、审计、人工任务、超时和恢复能力。
  • 能更系统地处理“等待外部事件再唤醒”的模式。

缺点：

  • 引入成本更高。
  • 团队需要建立新的建模和运维能力。
  • 如果流程并不复杂，可能过度设计。

这里要再次强调：Workflow 只是方法，不是总概念。

5.5.4 事件驱动流程

做法是多个系统通过事件彼此驱动，不一定有一个强中心编排器。

优点：

  • 系统耦合低。
  • 能沿着领域边界自然扩展。
  • 对多团队自治环境友好。

缺点：

  • 全局可见性较弱。
  • 审计、排障、人工介入更难。
  • 没有强约束时，流程边界容易失控。

它更适合主控方不强、但领域事件天然存在的场景。

5.6 长流程里的关键能力

无论采用哪种实现路线，真正决定系统是否可生产的，往往是下面这些能力。

5.6.1 状态持久化

系统必须记住：

  • 当前处在哪个阶段
  • 已完成哪些动作
  • 正在等待什么
  • 最近一次失败原因是什么

5.6.2 超时治理

每个阶段都要考虑：

  • 正常多久完成
  • 超时后自动取消、重试还是转人工
  • 超时是否影响上下游协同

5.6.3 恢复与重入

流程中断后，系统必须能回答：

  • 能不能从当前状态继续
  • 能不能安全重试
  • 哪些动作已经产生副作用，不能重复执行

5.6.4 观察与审计

要能快速看到：

  • 一个流程实例当前卡在哪
  • 上一步是谁推进的
  • 为什么失败
  • 最近一次人工介入做了什么

5.6.5 子节点内的大事务

这也是和上一章最重要的连接点：

长流程的每个关键节点内部，往往还会嵌套一个大事务。

例如：

  • 订单生命周期里的“创单”节点，内部可能用 Saga 处理库存、营销、订单创建。
  • 商品生命周期里的“发布”节点，内部可能用 Saga 处理主数据、索引、缓存、事件。
  • 退款生命周期里的“执行退款”节点，内部可能用补偿事务处理支付、权益、账务回冲。

所以实际系统中常见的组合不是二选一，而是：

  • 长流程方法论 管生命周期
  • 大事务方法论 管关键节点一致性

5.7 一个务实的选型框架

可以用下面几个问题来判断是否应该升级为长流程系统：

  1. 这个业务对象是否要跨多个阶段存在，而不是一次请求内结束？
  2. 是否存在等待点，例如支付回调、审核、外部响应？
  3. 是否需要回退、驳回、重提、暂停、恢复？
  4. 是否经常要人工介入？
  5. 是否需要对外解释“它现在卡在哪、下一步是谁处理”？

如果上面大部分答案都是“是”，那它已经不再只是一个大事务，而是长生命周期业务流程。

进一步选型时，可以参考：

场景特征推荐方案
阶段有限、等待少、主控服务明确数据库状态机
阶段较多、超时和通知复杂、需要统一主视角应用层编排器
长等待、审批多、恢复和审计要求高Workflow 引擎
多系统自治、领域事件天然存在、中心编排意愿弱事件驱动流程

5.8 方法论沉淀：如何在真实系统中做出选择

到这里可以把整章压缩成一组可复用判断。

5.8.1 五个判断句

  1. 只要一个业务对象要跨多个阶段长期存在，它就不是单次请求问题，而是生命周期问题。
  2. 只要流程里有等待、审批、驳回和人工接管，就不要再用“大事务延长版”去硬扛。
  3. 生命周期系统的核心不是“接口调用顺序”，而是“阶段、流转规则、等待点和恢复点”。
  4. Workflow 只是长流程的一种实现方式，不是总概念；先定义流程治理模型，再决定是否引入引擎。
  5. 真实系统里最常见的组合是：用长流程管理生命周期，用大事务保证关键节点一致性。

5.8.2 面试与评审中的一句话表达

如果要把这一章压缩成一句可直接复用的话，可以这样讲：

长生命周期业务流程方法论，解决的不是某个关键动作怎么一次做完，而是一个业务对象如何跨阶段被持续推进、被明确治理、在异常时被安全恢复；状态机、编排器和 Workflow 只是不同复杂度下的实现手段。