Day34-24｜15.10.2 业务流程分析：把跨服务协作转化为可执行的架构模型

对应教材：第15章 面向服务架构设计理论与实践——15.10.2 业务流程分析

学习目标：掌握 SOA 业务流程分析的对象、步骤和建模方法；理解流程、服务、规则、数据和组织角色之间的关系；能够设计同步、异步、补偿、状态和监控机制；能够在案例题和论文中完整描述跨服务业务流程。

一、为什么 SOA 必须进行业务流程分析

服务化不是把系统拆成若干接口后让调用方自由串联。一个完整业务通常跨越多个部门、应用和服务，具有顺序、条件、并行、人工审核、异常补偿和合规审计等特征。如果没有流程分析，服务边界就无法验证，通信方式也无法选择，最终容易出现流程逻辑分散、规则重复和故障后无法恢复的问题。

业务流程分析关注“业务如何完成”，而服务设计关注“能力由谁提供”。两者需要相互校验：流程步骤应能映射到服务能力；服务不能承担不属于自己的流程职责；跨服务流程必须有明确协调者、状态和异常处理。

流程分析链路如下：

业务目标 → 参与者与事件 → 流程步骤 → 服务能力 → 数据与状态 → 通信方式 → 异常补偿 → 质量与治理

二、流程分析的基本对象

1. 参与者

参与者可以是用户、业务人员、外部机构、应用系统或自动化服务。识别参与者有助于确定权限、责任和交互边界。例如订单流程中的客户、商城、库存、支付、仓储和财务各自承担不同职责。

2. 触发事件

事件可以是用户提交、定时任务、外部通知、状态变化或异常告警。触发事件决定流程何时开始，也影响同步或异步设计。用户点击“提交订单”通常需要立即受理；支付渠道回调则可能是异步事件。

3. 活动与规则

活动是流程中可执行的步骤，规则决定条件、分支、权限和状态迁移。业务规则应归属相应领域服务，流程模型负责组织步骤和分支，不应在多个系统中复制同一规则。

4. 数据与状态

流程需要输入、输出、中间数据和持久状态。状态应有清晰定义，例如待支付、支付中、已支付、履约中、已完成和已取消。状态迁移必须受合法条件约束，不能允许任意服务直接修改。

三、流程分析步骤

第一步确定流程目标和边界，写清开始条件、结束条件和不属于本流程的内容。第二步识别参与者、事件、主要活动和业务规则。第三步梳理正常路径、并行路径和异常路径。第四步把活动映射到服务和数据所有者。第五步确定同步调用、异步消息、人工任务和定时补偿。第六步定义流程状态、超时、重试、回滚或补偿。第七步补充安全、性能、可用性、审计和监控要求。第八步用案例和测试验证流程。

流程分析不能只画正常路径。真正影响架构质量的往往是：下游服务超时怎么办；消息重复怎么办；人工审核等待多久；业务已完成但响应丢失怎么办；某一步不可逆后如何补偿；流程版本升级时旧实例怎么办。

四、流程编排与流程协同

1. 集中编排

由流程协调器或编排服务明确控制步骤、条件和补偿。优点是流程可见、状态集中、审计方便，适合复杂流程、严格顺序和需要人工管理的场景。缺点是编排器可能变得复杂，参与服务对中心依赖较强。

2. 事件协同

服务完成本地处理后发布事件，其他服务根据事件自主反应。优点是松耦合、扩展方便，适合通知、积分、分析和跨领域广播；缺点是全局流程不直观，调试、顺序、一致性和错误补偿更复杂。

两种方式可以组合：核心交易流程由编排器管理关键状态，外围通知和分析通过事件协同。选择依据包括流程复杂度、业务可见性、参与者数量、实时性、一致性和治理要求。

五、同步、异步与人工步骤

实时校验、用户必须立即获得结果的步骤通常采用同步调用，但要控制超时和调用链长度。耗时任务、削峰、通知和可最终一致的步骤适合异步消息。人工审核必须持久化任务状态和截止时间，不能占用长连接等待。

同步不等于强一致，异步也不等于不可靠。同步调用仍可能在响应丢失时产生不确定结果；异步流程可以通过持久化、重试、幂等、死信和对账实现可靠处理。流程设计的关键是明确用户看到的状态和后台最终结果。

六、跨服务事务与补偿

当流程跨越多个服务时，通常不能把所有步骤放在一个长事务中。应先识别哪些步骤可逆，哪些步骤不可逆，再设计补偿动作。例如库存预占可以释放，订单可以取消，但外部支付可能已经扣款，需要退款或人工对账。

Saga 是常见方法：每个参与服务完成本地事务并记录结果，流程继续；若后续失败，按相反顺序执行补偿。补偿不是数据库回滚，而是一个新的业务操作，可能失败、重试或需要人工介入。因此补偿必须具备幂等、审计和状态管理。

七、流程状态机

状态机把流程状态、事件和合法迁移显式化。以订单为例：待创建 → 待确认 → 待支付 → 已支付 → 履约中 → 已完成；任一阶段可能进入取消中、已取消或异常待处理。每次迁移都要记录事件、操作者、时间和原因。

状态机能防止重复和非法操作。例如已完成订单不能再次支付，已取消订单不能直接进入履约；支付超时不能立即改成失败，必须根据渠道查询结果决定。流程状态应存储在可靠系统中，服务重启后能够恢复。

八、流程质量属性

性能方面要估算流程总延迟、同步链长度、并发流程数和消息积压；可用性方面要考虑协调器、消息平台、状态存储和外部依赖；可靠性方面要设计重试、幂等、死信、补偿、对账和恢复；安全方面要控制参与者权限、敏感数据、审计和跨系统身份传递；可维护性方面要支持流程版本、可视化追踪、回放和人工干预。

流程版本非常重要。旧流程实例可能仍在运行，新版本不能强行按新规则处理所有旧实例。可以记录流程版本，让旧实例继续完成或迁移到明确节点；新请求使用新版本；变更前分析在途实例和外部契约。

九、案例：电商订单履约流程

用户提交订单后，订单服务校验商品、价格和用户资格，创建订单并返回受理结果；流程协调器发起库存预占，成功后请求支付；支付成功后发布订单已支付事件；仓储服务创建出库任务；物流服务发货；完成后通知客户和财务。

流程可以抽象为：

提交订单 → 创建订单 → 预占库存 → 发起支付 → 支付确认 ↓ ↓ ↓ ↓ 失败返回 取消订单 释放库存 查询/补偿 ↓ 履约、物流、财务

设计要点包括：创建订单使用幂等键；库存预占具有有效期并可释放；支付超时进入待确认而不是直接失败；支付结果通过回调和主动查询双通道确认；库存、支付和发货均记录业务流水；事件消费者幂等；流程协调器持久化状态；异常进入补偿队列并支持人工处理。

十、流程分析中的常见错误

错误一是只画快乐路径，不分析异常和补偿；错误二是把流程规则复制到多个服务；错误三是把所有步骤同步串联，导致延迟和级联故障；错误四是使用共享数据库实现跨系统事务，破坏数据所有权；错误五是没有持久化流程状态，服务重启后无法恢复；错误六是忽略人工和外部渠道的不确定性；错误七是流程版本变更时没有处理在途实例。

改进方法是建立异常优先的流程设计：为每个步骤定义超时、重试、失败、补偿和人工升级；为每个状态定义合法迁移；为每个外部调用设置幂等和查询；为每个事件设置版本和追踪；为每个流程设置监控指标和恢复演练。

十一、考试答题模板

题目问“如何进行业务流程分析”，可按流程目标与边界、参与者和事件、活动与规则、服务映射、数据与状态、同步异步、事务与补偿、质量安全、监控与版本展开。题目问“如何设计跨服务流程”，要写编排或事件协同的选择理由、状态机、幂等、超时、重试、死信、补偿和对账。

论文中可以写：我先以业务目标梳理正常、异常和人工路径，再将活动映射到领域服务和数据所有者；对需要立即反馈的校验采用短同步调用，对通知和分析采用事件；跨服务流程使用持久化状态机和补偿机制，支付等不确定外部操作通过回调、查询和对账确认；所有步骤携带 traceId 和业务流水，以保证流程可观测、可恢复和可审计。

十二、课后练习

练习1

为什么流程分析必须包含异常路径？

参考答案：分布式系统中超时、重复、乱序、下游不可用和人工等待是常态；异常路径决定状态、补偿、重试、降级和恢复设计，只画正常路径无法证明架构可运行。

练习2

支付请求超时后，订单是否应立即标记支付失败？

参考答案：不应直接判断。请求可能已在渠道侧成功而响应丢失，应进入待确认状态，通过回调、主动查询和对账确认；根据最终状态执行成功、关闭或退款补偿。

练习3

流程编排和事件协同如何选择？

参考答案：复杂、顺序严格、需要集中审计和人工干预的流程适合编排；通知、广播、可扩展外围处理和允许最终一致的场景适合事件协同；实际系统可以组合使用。

十三、今日复盘

业务流程分析把业务目标、服务能力、数据状态、通信方式和异常治理连成一个整体。高级架构题不能只画流程箭头，而要解释谁负责、数据在哪里、失败怎么办、如何恢复以及质量如何验证。第15章到此完成，后续将进入第16章嵌入式系统架构设计理论与实践。