Day31-05｜10.2.3 复合片段演化：在局部变化中保持整体协作稳定

一、教材定位

复合片段可以理解为由多个对象、组件、服务、消息、活动或数据步骤组成的较大协作单元。一个订单处理流程、一次支付事务、一段审批流程、一个报表生成任务，都不是单一对象，而是多个元素按一定顺序和规则共同完成的复合片段。随着业务和技术变化，这些片段会新增步骤、改变顺序、拆分职责、引入并行、增加补偿或替换参与者。

复合片段演化的难点在于，局部变化可能破坏整体不变量。增加一个风控步骤可能改变订单时延，拆分一个服务可能改变事务边界，引入异步消息可能改变顺序和一致性，删除一个活动可能使下游等待永远无法结束。因此，设计师不仅要看单个对象是否正确，还要分析片段的边界、控制流、数据流、状态、异常和质量属性。

二、复合片段的组成

1. 参与对象和组件

片段由执行活动的对象、服务、数据库、消息主题、外部接口和人工角色构成。要明确每个参与者的职责、输入、输出、所有权和故障处理。参与者过多且边界模糊，通常意味着片段已经难以演化。

2. 控制流

控制流描述步骤的顺序、条件分支、循环、并行和汇合。流程变化时要检查前置条件、后置条件、超时、取消和补偿。流程图只画“成功路径”是不够的，还要描述异常和恢复路径。

3. 数据流

数据流描述对象和步骤之间传递的业务数据、状态、标识和结果。复合片段演化时，数据可能从同步参数变成事件，从共享对象变成不可变消息，或从完整数据变成引用和查询。数据流变化会影响一致性、隐私和性能。

4. 事务和一致性边界

片段可能由一个本地事务完成，也可能跨多个服务和资源。拆分或异步化后，要明确哪些步骤必须原子完成，哪些允许最终一致，哪些失败需要补偿。原有事务边界不能因为增加服务而隐式消失。

5. 质量属性约束

复合片段要满足性能、可用性、可靠性、安全性和可追踪性。新增一个同步依赖可能增加延迟和故障传播，新增审计可能增加存储，改为异步可能提高吞吐却改变用户等待体验。每次演化都要重新评估质量场景。

三、复合片段演化的典型形式

1. 片段扩展

在原流程中增加校验、审批、风控、通知或审计步骤。扩展前要确认新增步骤的前置条件、失败语义和超时处理。若新增步骤是非核心副作用，通常可以异步化或采用旁路，避免阻塞核心交易。

2. 片段裁剪

删除过时步骤、废弃渠道或冗余转换。裁剪不能只删掉调用，还要清理数据、监控、权限、定时任务、补偿和文档。尤其要确认是否有其他系统依赖被删除步骤产生的消息或状态。

3. 片段重排

改变活动顺序，例如先库存预占再支付，或先风控再创建订单。顺序变化会改变失败窗口、并发和补偿逻辑。必须分析中间状态、重复执行和历史数据兼容。

4. 片段拆分

把一个大型流程拆成多个子流程或服务，以改善团队边界、扩展性和故障隔离。拆分会引入网络、消息、分布式事务和观测复杂度，必须配套幂等、追踪、超时和补偿。

5. 片段合并

把原本分散的活动合并，以降低调用开销、简化事务或消除重复。合并可能降低独立扩展和隔离能力，应确认变化频率、资源需求和故障域是否相近。

6. 片段并行化

把相互独立的步骤并行执行，降低总体延迟。并行化前要确认数据依赖、资源竞争、失败汇合和取消语义。一个分支失败时，是全部回滚、部分成功、重试分支还是转人工，必须明确。

四、复合片段的演化分析方法

1. 建立片段基线

记录当前参与者、流程、数据、状态、事务、外部依赖、耗时、失败率和业务结果。基线不能只是一张流程图，还要包括运行数据和关键约束。没有基线，就无法比较演化后是否改善。

2. 标出变化点和不变量

列出新增、删除、重排、拆分和合并的步骤，明确不变量，例如金额守恒、订单只能完成一次、库存不能负数、审批必须留痕、敏感数据不得越权。演化方案必须说明如何保持或重新建立这些不变量。

3. 分析影响传播

沿控制流、数据流、依赖和状态追踪变化影响，识别下游消费者、回滚路径、监控指标和测试场景。对跨服务流程，还要分析消息延迟、重复、乱序、部分成功和依赖不可用。

4. 设计过渡状态

大改造应将旧片段、新片段和转换逻辑同时描述。可以通过适配器、旁路、影子执行、双写、事件桥接和灰度切流实现渐进迁移。过渡逻辑必须有版本、监控、回滚和退出条件。

5. 验证质量属性和业务结果

比较演化前后的延迟、吞吐、故障率、恢复时间、数据一致性、发布影响范围和运维成本。核心业务还要执行端到端对账和状态校验，不能只看单个服务接口是否成功。

五、复合片段与事务演化

1. 从本地事务到分布式协作

本地事务通常可以依靠数据库原子性回滚。拆成多个服务后，无法简单依赖一个事务覆盖所有步骤。需要选择同步调用、可靠消息、Saga、补偿事务、TCC或业务状态机等方式，并明确一致性目标和失败处置。

2. 补偿不是简单反向操作

取消支付、释放库存和撤销通知并不一定是原操作的严格逆操作。补偿可能失败、延迟或受到业务规则限制，需要重试、人工介入、对账和幂等。设计补偿时要记录原事务、补偿状态和最终结果。

3. 读写分离与异步化

将非核心步骤异步化可以缩短主流程，但用户可能暂时看到处理中状态。要定义状态查询、超时、通知、重试和最终一致性。异步消息必须可追踪，避免用户不知道结果或系统重复执行。

六、复合片段与状态机演化

复杂流程最好显式建模状态，而不是由多个布尔字段隐式组合。状态机应描述状态、事件、守卫条件、动作和错误处理。新增状态要考虑旧状态数据、旧客户端、消息回放和人工操作。

例如订单增加“风控审核中”，就要明确支付是否允许、库存是否释放、用户是否可取消、审核超时如何处理、审核失败如何通知以及历史订单如何迁移。若只增加一个状态值而不更新其他参与者，流程会出现悬挂和不一致。

七、复合片段中的可观测性

流程跨越多个服务时，必须使用统一的业务关联号、链路标识和阶段状态。每个阶段记录开始、完成、失败、重试和补偿，监控整体耗时、积压、悬挂、失败率和状态分布。

可观测性应支持从用户结果反查技术路径，也支持从故障事件定位受影响业务。流程变更后要同步更新仪表盘、告警规则和运行手册，否则系统已经变了，运维仍按旧流程处理。

八、案例分析：订单支付流程演化

某平台原流程为创建订单、扣减库存、调用支付、发送通知，全部在一个应用内同步执行。为提高支付安全，计划增加风控审核；为降低延迟，计划把通知改为异步；为支持拆单，库存扣减也要按包裹处理。

这不是简单增加三个步骤。风控审核会改变订单状态和超时规则，通知异步化会改变用户可见结果和消息可靠性，拆单会改变库存事务和订单完成条件。正确的演化应先定义订单、支付、包裹和通知的状态机与不变量：订单金额只确认一次，库存扣减有幂等键，支付回调可重复接收，通知失败不影响核心支付，所有包裹完成后订单才能进入可履约状态。

过渡阶段可以保留旧流程，同时通过特性开关让部分订单进入新流程；对新流程采用状态编排、可靠消息和补偿，通知使用独立队列并设置死信；库存按包裹建立预占和释放记录。测试要覆盖风控超时、支付响应丢失、消息重复、单个包裹失败、节点重启和人工取消，并通过订单、支付、库存和通知对账验证最终结果。

九、综合知识练习

题1

为什么复合片段增加一个步骤可能引起大范围影响？

参考答案：新增步骤会改变控制流、数据流、事务边界、状态机、耗时、失败窗口、消息和下游依赖。它可能阻塞主流程、改变不变量或增加新的补偿路径，因此要进行端到端影响分析。

题2

把同步步骤改成异步消息时，需要重点检查什么？

参考答案：检查最终一致性目标、用户可见状态、消息可靠投递、重复和乱序、幂等、重试、死信、超时、补偿、回放、监控和对账，不能只关注响应时间降低。

题3

复合片段拆分后如何验证演化没有破坏业务不变量？

参考答案：先明确不变量和状态转换，再通过端到端场景、故障注入、消息重复和恢复测试验证；使用业务对账、状态校验和审计记录确认金额、库存、订单和消息最终一致，并比较演化前后的质量指标。

十、论文写作素材

论文中可以这样描述复合片段演化：

“针对原有订单流程步骤耦合、同步依赖过多和故障难以补偿的问题，我先建立流程、数据、状态和事务基线，识别核心不变量和非核心副作用。演化时将风控、库存和通知等变化点按业务边界拆分，核心交易保留明确状态机，非核心通知改用可靠事件，跨服务协作通过幂等、超时、重试、死信和补偿保证最终一致。迁移期间使用特性开关、适配器和灰度流量保持新旧流程共存，通过链路追踪、阶段指标和业务对账验证订单、支付、库存和通知结果，完成验证后再退出旧流程。”

十一、今日复盘

复合片段由多个对象、服务、数据和步骤组成，局部变化可能影响整体。
演化分析必须同时看控制流、数据流、状态、事务和质量属性。
拆分、异步化和并行化会引入一致性、顺序、幂等和补偿问题。
现状、过渡和目标片段都要有清晰的版本和退出条件。
端到端业务对账是验证复合片段演化的重要证据。
案例答题要写清不变量、故障路径、补偿策略和观测指标。