编排还是事件协作用 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 关于 协调方式的建议也区分跨服务事务协调与对其他服务有兴趣的事件广播在本文案例中具体边界来自业务所有权而非某个产品的默认设置。图 3Outbox 发布事实后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 发事件触发 BB 再发事件触发 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_READYCRM 消费并创建通知失败归 CRM 集成值班不改变主状态”。这两行看似都叫事件所有权却不同。控制权合同还应有“撤销或更新”列。申请资料从 v1 改到 v2 后v1 签署不再满足当前资料门禁如果早已发出APPLICATION_READY下游收到旧事件可能继续通知。必须定义事件版本、后续更正事件或下游展示规则而不是假设事件发出后不会变化。若业务禁止 READY 后改资料就把禁止条件明确写进状态机确保实例在 READY 阶段不会发生版本变更。若业务允许变更则需要给签署与通知设计撤销、覆盖或重新确认语义。这不是编排与事件协作哪一种“更好”的问题而是业务事实是否可变、谁有权宣布变更的问题。同样要区分事件发布成功与业务动作完成。Outbox 行已提交只表示未来可以投递消息中继发送成功只表示目标传输层接收CRM 接口返回 200才可能表示通知记录写入客户经理真正看到通知又是另一件事。四个里程碑不能压成同一个donetrue。若客户提出“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_keyCUSTOMER-001在别的租户可能也存在。事件消费者按业务键查询时必须加租户实例服务处理审批时应从已认证操作者的权限与任务所属租户校验而不是相信请求体写的租户字符串。旁路服务使用最小只读或通知权限不能为了“省一个 API”获得核心状态表的写权限。这样即便 n8n 工作流节点被误改破坏范围也主要限于通知链而不会直接造成错误开通。把架构方案转成验收脚本设计评审里可以准备五条端到端故事。第一签署和到账逆序到达实例仍只进入一次 READY第二ERP 请求已执行但响应丢失实例保持 READY查询到 CREATED 后才 ACTIVE第三CRM 消费者停机一天主链照常等待 ERP恢复后 CRM 只补一条通知第四同一 READY 事件重复投递CRM 与报表分别按自己的 Inbox 去重第五审核资料从 v1 改到 v2v1 回执不能满足 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 单独验收。