编排还是事件协作？用 AcmeFlow 讲清企业 Workflow 的控制权
企业工作流最容易被低估的设计问题，并不是“下一步调用哪个接口”，而是“谁有权决定下一步”。同一份客户服务开通申请经过运营审批、合同签署、到账、ERP 建档和 CRM 通知。每个团队都能把自己的接口接上，但只要审批、到账或 ERP 的一条消息迟到，就可能出现五个系统各自认为申请处于不同状态。某个系统显示“已经开通”，另一个系统还停留在“等待签约”；用户看到的究竟是什么？出了问题应该由谁修复？这才是编排与事件协作的起点。
本文延续 AcmeFlow 案例：教学租户为xinghe-demo，业务键为CUSTOMER-001，申请与实例均沿用第 03 篇的 UUID。核心规则不变：SUBMITTED经过人工审核可以成为APPROVED；当前资料版本的签署事实与到账事实齐备后成为READY；只有 ERP 确认创建，才能成为ACTIVE。READY是“开通条件齐备”，不是“服务已经创建”。ERP 结果为未知时，实例必须继续等待查询或人工对账。
图 1：教学架构示意。左侧集中编排决定主状态，右侧事件订阅适合独立的通知和分析。可编辑源文件：SVG。
先区分“控制流”与“业务事件”
编排是由一个明确的协调者保存流程进度，并据此要求参与方执行下一步。它可以是业务服务里的状态机，也可以是专门的流程引擎。协调者知道当前在等哪个事实、哪个任务已超时、下一步允许执行什么。事件协作则是参与方公开已经发生的事实，其他服务依各自职责订阅处理。发布方不需要知道全部消费者，也不负责指挥每个消费者内部的执行顺序。AWS 的 Saga 模式说明也把 choreography 与 orchestration 列为两种不同变体，并指出参与者增加时，纯事件链的依赖会更难追踪。
在 AcmeFlow 中，运营审批是一个命令和决策：操作者要求把指定资料版本的待办判定为通过，服务端检查身份、任务状态与实例版本，成功后保存状态迁移。APPLICATION_READY则是已经发生的事实：实例满足了进入READY的条件。通知服务收到它，可以给客户经理发提醒；分析服务收到它，可以更新报表。但两者都不能因为处理成功或失败而把实例改成ACTIVE。如果通知发不出去，核心申请仍然是READY。如果 ERP 的结果未知，通知成功也不能替代 ERP 的创建证据。
这里的关键不是技术协议。即便所有组件都通过 HTTP 通信，也可能是集中编排；即便使用 Kafka 等消息系统，也可能由一个协调者通过命令与回执来编排。把“同步 HTTP = 编排、异步消息 = 事件协作”当成定义，会让真正重要的状态所有权问题被传输方式掩盖。设计评审时应要求每个箭头标明：它承载的是命令、事实、查询，还是纯通知；接收方能改变什么；如果消息重复或丢失，谁负责恢复。
用同一申请画出主链
先不要急着选引擎。画出一个实例的主链：销售提交申请，运营审核当前资料版本；合同签署与到账各作为独立事实到达；AcmeFlow 判断两者是否都与申请匹配；满足门禁后进入READY；再通过稳定的操作键请求 ERP 建档；收到明确创建结果或通过对账确认结果后进入ACTIVE。签署和到账可能先后颠倒，因而不能写成“审核完成就等待签署，签署完成才接受到账”的硬编码串行脚本。主状态可以集中管理，但事实可异步进入。本文的“集中”指状态决策与等待责任集中，并不要求所有业务动作发生在一个进程中。
图 2：审批、签署、到账和 ERP 创建结果在主链上各有不同语义；该图是业务规则示意，不是运行截图。SVG。
假设签署回执先到，到账回执晚到。签署服务只陈述“合同版本 v1 已签署”，支付系统只陈述“指定金额到账”。AcmeFlow 在自己的事务里确认这些事实属于相同租户、申请和有效资料版本，然后决定是否从APPROVED进入READY。若让支付服务在“自己看到签署事件”后直接更新申请状态，签署版本是否仍有效、审批是否被驳回、是否已经有新资料版本等判断就散落在支付服务里。另一个团队增加“风控冻结”规则时，所有参与者可能都要修改，且容易出现一方漏改。
集中编排的价值，正在于把必须一致解释的业务门禁放到一个地方。它没有消除分布式问题：签署回执可能重复，ERP 响应可能丢失，消息转发可能延迟。它只是把“现在应该做什么”变成可查询、可审计的明确决定。第 05 篇的版本条件更新守同一实例并发，第 06 篇的 Outbox/Inbox 处理状态变化与事件发布之间的断点，第 07 篇把 ERP 的未知结果留给查询和对账。这些能力仍是编排的基础，换成一个可视化流程引擎也不能省掉。
哪些工作适合旁路事件协作
进入READY后，通知、报表、客户成功看板是很好的事件消费者。它们有共同触发点，却不应互相知道彼此。CRM 团队可以修改通知模板，报表团队可以增加维度，而主状态机不必随着这些变化重写。第 18 篇会让 n8n 订阅同一事件，再调用模拟 CRM；那是旁路集成，不是让 n8n 接管审批、到账和 ERP 激活。AWS 关于 协调方式的建议也区分跨服务事务协调与对其他服务有兴趣的事件广播；在本文案例中，具体边界来自业务所有权，而非某个产品的默认设置。
图 3：Outbox 发布事实后，CRM 与报表各自消费；它们不获得修改核心实例的权限。SVG。
事件应包含稳定的event_id、租户、申请 UUID、实例 UUID、事件类型、发生时间和必要版本信息。可读业务键方便排障，但不能单独当全局唯一键；不同租户可以有相同业务键。消费者应按“消费者名称 + event_id”记录处理进度，并把本地效果与去重记录放在同一事务里。若消费者调用外部 CRM，还需要 CRM 侧可接受的稳定操作键；本地 Inbox 不能保证远端只产生一次通知。第 06、07 篇已经分别演示本地去重和未知结果处理，这里应沿用，而不是再发明一个“事件平台保证 exactly once”的口号。
旁路的另一个标准是失败影响范围。客户经理邮件延迟十分钟，通常应生成通知积压与告警，不应把已满足条件的主申请退回APPROVED。但若某个“通知”实际上是监管要求的开通前确认，它就不再只是旁路动作，需要纳入主链门禁并写清失败后状态。名字叫“通知”不能决定架构位置，业务承诺与验收标准才能决定。FDE 在访谈里应直接问：这个动作失败时，客户服务可以继续开通吗？谁来补做？补做前用户界面应显示什么？
两种模式的故障不是同一种故障
集中编排常被批评为“单点”。这是合理风险，但需要说清是控制权单点、进程单点，还是数据存储单点。单一状态所有权并不意味着只能部署一个进程；多个无状态 worker 可以通过数据库条件更新竞争同一待办。真正要避免的是只有内存知道“执行到第三步”的脆弱实现。协调者必须持久化进度、待办、操作键和历史，恢复后能继续判断。若使用专门引擎，还要验证引擎本身的高可用、升级、备份和队列恢复，而不能把“引入平台”自动等同于可靠。
事件协作则容易产生“看不到全局”的故障。比如APPLICATION_READY先被 CRM 消费、又被分析服务消费，随后分析服务的写库失败。单看 AcmeFlow 的状态，申请一切正常；单看 CRM，也已通知；经营看板却缺这一条。如果没有按event_id聚合的投递状态、失败队列和重放机制，团队很难回答“哪个客户被漏算”。事件越多，隐式依赖越多。若 A 发事件触发 B，B 再发事件触发 C，某一步失败后的补偿与回退可能散在多个团队手里。AWS Saga choreography 文档提出的适用与局限，可作为评审参考；具体到 AcmeFlow，我们将跨系统开通结果留在主链，旁路只处理可独立恢复的效果。
图 4：通知失败、ERP 未知和最终确认分别走各自的恢复路径；示意图中的时间不代表实测延迟。SVG。
出现故障时，运维首先要查询实例当前状态及其等待原因，再查看相关 Outbox 事件和消费者进度。例如“实例 READY、ERP UNKNOWN、CRM 已成功、报表待重试”应被允许同时存在。这不是数据矛盾，而是四个不同维度。错误做法是为了让页面看起来统一，直接把实例改为ACTIVE；正确做法是查询 ERP 稳定操作键，拿到创建证据后才提交状态迁移。第 16 篇将把这类排障转成时间线、指标和受控修复命令。
一个最小可运行实验
本篇附带 demo.py。它使用 Python 标准库在内存中构造一份 AcmeFlow 申请，按审批、到账、签署、ERP 确认推动主状态；另以相同event_id两次投递APPLICATION_READY，分别给通知和报表消费者。消费者内部去重后各产生一次记录，主状态仍是READY。只有对核心对象执行erp_created命令，主状态才成为ACTIVE。运行方式为python code/demo.py，实际输出保存在 run-output.txt。
这个实验刻意没有搭建消息中间件，也没有声称跨系统 exactly once。它只把一条架构约束做成断言：旁路消费者不持有核心实例引用，不提供修改主状态的调用。若要接入第 03 篇的 FastAPI/PostgreSQL 基座，应在原有workflow_instances的实例服务里扩展READY、ACTIVE、事实与 ERP 操作状态，并由该服务统一做状态迁移；第 06 篇的 Outbox 对外发布APPLICATION_READY；通知与报表则在各自库内保存 Inbox。第 03 篇原始状态 CHECK 仅覆盖早期人工审核切片，实际迁移前必须调整约束并评审兼容旧实例。本文脚本不是“复制进第 03 篇即可运行”的集成补丁。
图 5：按业务责任而不是按通信技术选集中编排或事件协作；适用结论是案例判断。SVG。
设计评审的六个问题
第一个问题是：是否只有一个地方能回答“这份申请现在是什么状态”？如果运营后台、CRM 和 ERP 各有一个“最终状态”，必须标明哪个是权威来源，其他系统保存的是副本还是自己的局部状态。第二个问题是：每个转移依赖哪些证据？“支付成功”应落到支付事实来源、金额、租户与业务键，而不是只取一个布尔值。第三个问题是：外部结果未知时，能否查询？若没有稳定操作键和远端查询合同，重试策略就不能凭空假设安全。
第四个问题是：事件消费者失败是否允许主流程继续？如果允许，就应有独立的失败状态与重放入口；如果不允许，应把它纳入主链，明确谁审批、谁恢复。第五个问题是：业务规则新增后要改几个服务？只要“资料版本变化使旧签署失效”需要在多个订阅者重复实现，状态所有权就已泄漏。第六个问题是：谁能看到一份申请从提交到开通的完整时间线？一条追踪 ID 不等于完整业务历史，还需要状态迁移、外部操作、人工任务和事件投递的关联字段。
这些问题在项目初期很容易被“先做个 Demo”绕过。Demo 里每次接口都正常、消息恰好有序，任何模式都能跑通。上线以后真正决定成本的是失败路径：响应丢失、旧版本资料的回执、重复事件、多个部门同时补单、客户投诉时的证据链。架构并不是一张画得漂亮的图，而是把这些情况的所有权和处理动作说清楚。FDE 应在技术方案里写出至少一条失败时间线，并给业务负责人确认“此时客户看到什么、谁负责、多久处理”。
图 6：本篇离线实验只验证控制权与重复事件处理；真实鉴权、数据库与消息服务不在实测范围。SVG。
FDE Thinking：为什么不让每个系统自己做一点
因为“自己做一点”往往不包含一致性责任。运营团队知道审批、支付团队知道到账、ERP 团队知道建档，但客户需要的是一个可解释的开通结果。每个团队都保留自己的数据主权没有问题；跨领域的申请状态需要一个清楚的聚合和裁决边界。AcmeFlow 的协调者不替代支付账本，不替代 ERP 服务记录，也不拥有 CRM 通知内容；它只保存足以说明开通条件与下一步动作的事实引用和决策历史。这样的集中，范围可控。
事件协作也绝非次等方案。它能让不影响主状态的能力独立演进，是减少团队耦合的重要工具。问题出在没有划分主链与旁路，随后把每一个新需求都加成订阅者，让事件流暗中承担了没有人拥有的业务流程。FDE 的任务是把隐形流程显式化：对“谁做决定”给出唯一答案，对“谁处理副作用”允许多个独立答案，对“失败时谁修复”保留可操作的记录。AcmeFlow 的后续实践将继续验证这三个答案，而不是让工具名称替我们完成设计。
从事件清单推导控制权合同
落地时可以把所有消息整理成一张“控制权合同”，它比一张只有箭头的架构图更有用。每行写清触发方、消息名称、业务含义、目标、前置条件、持久化位置、失败后责任人，以及它是否可以改变主状态。以支付回执为例，支付系统只对“到账这一财务事实”负责，AcmeFlow 要检查该事实的租户、金额、业务键与申请关系，然后由实例服务决定是否进入READY。如果同一回执第二次到达，AcmeFlow 记录或识别重复，但不能再增加一次付款，也不能再触发一次状态迁移。CRM 通知的消息行则写“AcmeFlow 发布 APPLICATION_READY；CRM 消费并创建通知；失败归 CRM 集成值班；不改变主状态”。这两行看似都叫事件，所有权却不同。
控制权合同还应有“撤销或更新”列。申请资料从 v1 改到 v2 后，v1 签署不再满足当前资料门禁；如果早已发出APPLICATION_READY，下游收到旧事件可能继续通知。必须定义事件版本、后续更正事件或下游展示规则，而不是假设事件发出后不会变化。若业务禁止 READY 后改资料，就把禁止条件明确写进状态机，确保实例在 READY 阶段不会发生版本变更。若业务允许变更，则需要给签署与通知设计撤销、覆盖或重新确认语义。这不是编排与事件协作哪一种“更好”的问题，而是业务事实是否可变、谁有权宣布变更的问题。
同样要区分事件发布成功与业务动作完成。Outbox 行已提交，只表示未来可以投递；消息中继发送成功，只表示目标传输层接收；CRM 接口返回 200，才可能表示通知记录写入；客户经理真正看到通知又是另一件事。四个里程碑不能压成同一个done=true。若客户提出“READY 后五分钟客户经理必须看到通知”，我们需要的是通知链路的独立时限与端到端确认，不应偷用主申请的ACTIVE状态承载这一 SLA。一个状态字段承载多个承诺，后期必然难以解释。
复杂度增长时如何识别事件链已经失控
早期只有两个参与者时，事件链可能很直观：申请创建后发事件，通知服务消费即可。增加规则后，可以观察三个信号。第一，同一业务条件在多个消费者中重复编码。例如“签署必须是最新资料版本”如果同时写在 ERP 适配器、CRM 和报表作业里，规则的一次修改要跨多个仓库发布。第二，排障依赖人脑把事件顺序拼回去；没有一个实例视图能回答当前在等哪个业务条件。第三，新团队订阅事件时，必须知道一串历史消费顺序和旧团队的补偿约定，才能避免意外触发。这时所谓的“松耦合”已经变成隐式耦合。
改造不一定要立刻替换全部消息系统。可以先把最终状态判断收回一个 AcmeFlow 服务：各参与者仍发布自己的事实，实例服务订阅后记录、去重并判断门禁；原本直接互相触发的订阅者逐步改为监听权威状态事件。过渡期要防止新旧路径同时产生 ERP 创建命令。可以在数据库里为“申请 + 创建服务动作”建立稳定唯一键，让旧路径与新路径竞争时只有一个得到执行意图；但这仍要配合远端 ERP 的幂等或查询合同。迁移期间把旧消息订阅关系画出来，逐个下线并监控“是否仍有旧消费者在发命令”，比一夜之间全部换引擎更安全。
需要说明反方向的边界。集中协调者若开始处理 CRM 模板、报表字段、邮件发送细节，也会变成巨大的全能服务。它应持有状态门禁和跨系统补偿的必要上下文，而不是吞掉每个参与方的局部决策。评价一个动作是否留在核心，可问：它失败时是否阻止ACTIVE？它是否需要与申请版本一致？它的补偿是否改变对客户的服务承诺？三个答案都是否时，更可能放在旁路；只要有一个是是，就需要详细评审，而不是机械地一律放进协调者。
在接口层把命令、事实和查询分开
接口命名会影响团队理解。POST /tasks/{id}/decision是命令：要求系统基于当前 revision 作出审核决定，可能被拒绝。PAYMENT_RECEIVED是事实：支付侧声称某笔款已到账，AcmeFlow 校验后保存来源与去重键。GET /erp/operations/{operation_key}是查询：只读确认外部动作的结果，尤其适用于请求超时之后。若把三者都设计成一个POST /workflow/next，调用方可能误以为任何事件都能推动状态，重试策略也会混乱。命令需要防陈旧版本与权限；事实需要来源认证、关联与去重；查询需要一致性与“仍未知”响应。每一类都有不同的失败语义。
在数据库上，建议把实例状态、事实表、待办与历史分开。实例的revision是单条状态更新的并发边界；事实表保留支付和签署来源，不因主状态变化而删除；历史表记录每次被接受的迁移；Outbox 记录要公开的事件。一次“签署使 READY 条件齐备”的本地事务可以插入签署事实、条件更新实例、追加历史并写 Outbox。这样进程在事务后崩溃，状态与待发布事件仍一致。跨 ERP 或 CRM 的网络调用不应放进这个数据库事务里等待，这样会把外部延迟带进锁持有时间，远端失败也不能随本地事务自动回滚。
接口还要防租户穿透。business_key=CUSTOMER-001在别的租户可能也存在。事件消费者按业务键查询时必须加租户；实例服务处理审批时，应从已认证操作者的权限与任务所属租户校验，而不是相信请求体写的租户字符串。旁路服务使用最小只读或通知权限，不能为了“省一个 API”获得核心状态表的写权限。这样即便 n8n 工作流节点被误改，破坏范围也主要限于通知链，而不会直接造成错误开通。
把架构方案转成验收脚本
设计评审里可以准备五条端到端故事。第一，签署和到账逆序到达，实例仍只进入一次 READY；第二，ERP 请求已执行但响应丢失，实例保持 READY，查询到 CREATED 后才 ACTIVE；第三，CRM 消费者停机一天，主链照常等待 ERP，恢复后 CRM 只补一条通知；第四，同一 READY 事件重复投递，CRM 与报表分别按自己的 Inbox 去重；第五，审核资料从 v1 改到 v2，v1 回执不能满足 v2 的门禁。这些故事都比“消息通了”更接近用户会遇到的情况。
每条故事都应指定观察证据。主状态看workflow_instances与transition_history，签署和到账看事实来源与版本，事件看 Outbox/Inbox，外部操作看稳定键与 ERP 查询，通知看 CRM 记录。若某条故事只能靠“看起来没出错”证明，说明验收资料还不够。执行脚本可先用模拟系统跑，再在隔离环境接真实依赖；两种结果要分开记录。本篇 Python 小脚本仅覆盖其中“主状态所有权”和“重复 READY 事件两个订阅者各处理一次”的局部故事，不能冒充完整分布式验收。
给一次架构决策留书面记录
评审完成后，可以把结论压缩为一页决策记录。背景写“星河设备希望从申请到开通可查、可修复，CRM 通知可独立改版”；决定写“AcmeFlow 持有申请主状态，签署与支付提供事实，ERP 提供创建结果，Outbox 发布 READY 事件，CRM 和报表分别消费”；理由写“审核版本、到账与签署门禁、ERP 未知结果需要一个裁决者，通知与分析可以独立恢复”；代价写“AcmeFlow 需要维护实例与任务状态，旁路消费者需实现去重和失败队列”。最后加上重评条件：如果主链跨更多业务域、补偿和人工任务复杂度超出团队维护能力，再评估专门引擎。
这份记录还应有反例和禁止项。禁止 CRM 或通知工作流直接写workflow_instances.state；禁止仅凭一个 HTTP 200 将 ERP 操作标记为 CREATED；禁止在 ERP UNKNOWN 时更换新操作键重试创建；禁止只按business_key查实例而忽略租户。反例可写“CRM 停机一天，只影响通知链，不改变 READY；支付事实晚于签署，AcmeFlow 仍可判断条件齐备”。这些句子让设计原则在代码评审时可执行，而不是停留在“保持松耦合”这样的抽象口号。
每个责任人还需要明确替补。实例服务故障由核心后端值班；支付事实异常由财务接口团队核对；ERP UNKNOWN 由集成团队按操作键对账；CRM 投递失败由通知集成值班补投。跨团队事故中可以由一个 incident commander 统筹，但不能让所有工作都落到“平台组看看”。企业流程的可靠性最终依赖这些运营约定。技术图上多加一个重试箭头，不能代替“谁在夜里接到告警、能否查询证据、可执行什么动作”的答案。
还应规定如何处理“订阅者发现主事件有误”。CRM 消费者不应直接改 AcmeFlow 的历史；它应向事件所有者报告event_id、发现的问题和自身已产生的副作用。AcmeFlow 核对原始事实后，若确实需更正，应发布带关联 ID 的更正事件，消费者据此撤回或更新通知。这样错误的修复也可追踪，不会出现一个团队悄悄删消息、另一个团队继续按旧事实发邮件。事件一旦被外部系统消费，修复方案就需要面对已经发生的效果，而不是假设数据库回滚能够让世界恢复原样。
这也是第 10 篇 Saga 补偿思想在事件协作中的体现：补偿是新业务动作，不是时间倒流。是否需要给客户经理发送“此前通知无效”的补充通知、是否关闭 CRM 跟进任务，应由业务规则决定。技术团队负责保证更正事件的标识、顺序与审计可用，不能擅自代表客户决定该如何解释一次错误开通。把这种责任在设计时写清，比事故后临时讨论“谁删一条数据”更可控。
在验收会上还可以故意“拔掉”一个旁路消费者，再问所有人同一个问题：客户服务当前状态是什么？如果答案依赖 CRM 是否在线，说明主状态与通知状态混在一起；如果实例能明确回答 READY 或 ACTIVE、同时标出通知待补投，边界就比较清楚。这个演练比让各组件在正常情况下顺序跑完更能暴露所有权错误，也让非工程岗位理解为什么一条业务申请可以同时拥有多个局部进度。
来源与实验边界
模式定义与权衡参考 AWS 官方的 Saga patterns、选择协调方式及 Saga orchestration。文中 AcmeFlow 的状态所有权、旁路分界和验收问题是本系列的设计判断，并非 AWS 产品保证。本文本地 Python 实验已运行；未运行真实 broker、CRM、ERP、认证或第 03 篇 PostgreSQL 集成，生产行为需要按 README 单独验收。
