可靠系统设计与电商架构

System Design: Reliable Systems and E-Commerce Architecture

这是一本面向中高级工程师、技术负责人和架构师的系统设计实践书。全书围绕“如何设计能够长期运行的复杂系统”展开，覆盖系统设计方法论、生产可靠性、数据一致性、长流程治理，以及商品、库存、营销、计价、订单、支付和履约等电商核心领域。

本书不止讨论如何画出架构图，更关注系统在真实生产环境中如何面对流量增长、故障恢复、数据不一致、业务变更、对账补偿和资损风险，帮助读者建立从问题定义、边界划分、数据建模、架构权衡，到上线治理、故障复盘和持续演进的完整系统设计方法。

本书强调三个判断：

• 系统设计首先是业务边界、数据事实和失败语义的设计，不只是组件堆叠。
• 架构方案必须能经受生产环境的流量、故障、变更、对账和资损风险考验。
• 电商系统是理解复杂业务系统的高密度样本，商品、库存、营销、计价、订单、支付和供应商同步能覆盖大量通用架构问题。

适合读者

• 已有后端开发经验，希望系统化提升架构设计能力的工程师。
• 正在负责业务系统拆分、重构、稳定性治理或技术方案评审的技术负责人。
• 准备系统设计面试，希望把项目经验组织成清晰表达的候选人。
• 希望通过电商场景理解交易链路、一致性、对账、补偿和资损防控的读者。

本书结构

1. 系统设计方法论（第 1-9 章）：问题定义、方案设计、业务边界、内部结构、系统集成、架构质量与编码落地。
2. 生产治理（贯穿第 3、4、7 章和第 11-14 章）：覆盖可靠性、对账补偿、DLQ、故障恢复、资损防控、容量规划、限流、熔断和降级。
3. 电商系统设计实战（第 10-14 章）：电商全景、商品供给、库存、营销与计价，以及 C 端交易全生命周期。
4. 附录面试题库（附录 D-F）：附录 D 保留原有系统设计训练题库，附录 F 收录 1-10 年互联网后端工程师高频系统设计 50 题，附录 E 提供后端基础知识题单。

全书逐章速览

第一部分：系统设计方法论

第二部分：电商系统设计实战

附录

阅读路线

• 架构主线：第 1-9 章，配合第 10-14 章电商实战。适合希望建立完整系统设计框架的读者。
• 电商实战主线：第 10-14 章。适合正在做交易系统、供给系统或支付系统的读者。
• 可靠性主线：第 3、4、7 章，结合第 14 章订单、支付和交易闭环阅读。适合做稳定性、故障恢复和资损防控治理。
• 面试主线：附录 E 用于补齐后端基础知识，附录 D 用于系统设计题训练。先按小主题复习基础题，再选择核心案例或约束变体，并使用附录 D 中的限时模拟面试进行演练。
• 基础补齐主线：附录 E。适合按小主题补齐系统设计背后的计算机基础和编码能力。

使用建议

读这本书时，不建议只记结论。更好的方式是每读完一个系统章，都回答四个问题：

1. 这个系统的权威数据是什么？
2. 它负责什么，又明确不负责什么？
3. 它和上下游如何协作，失败后由谁补偿？
4. 它的监控、对账、灰度、回滚和资损防控怎么设计？

如果能把这四个问题说清楚，就已经从“功能设计”进入了“系统设计”。

本地构建

需安装 mdBook。本书复用 tools/mermaid-preprocessor.py 处理 Mermaid 图表。

cd books/reliable-system-design
mdbook build
mdbook serve

也可以在仓库根目录生成到 Hexo 本地预览目录并启动服务：

npm run server:reliable-system-design

启动后访问：

http://localhost:3000/reliable-system-design/

第 1 章 系统设计与架构方法论：从业务建模到工程落地

系统设计不是从选择组件开始，而是从理解业务、定义边界和识别约束开始。本章建立从问题定义、技术方案、架构组织到评审演进的工作链路；后续章节再分别展开编码、分布式一致性、可靠性和电商实战。

面对“做订单系统”“提升并发”“拆微服务”这类需求，最常见的误区是立刻讨论数据库、缓存、消息队列和服务数量。组件只能回答“怎么实现”，不能回答“为什么这样实现、由谁负责、失败后怎样收敛”。架构的价值在于：在业务目标、质量属性、团队能力和成本约束之间，做出可以解释、验证和演进的决策。[1][3]

本章以一条工作链路组织内容：

问题与约束 → 设计画布 → TD 与决策记录 → 业务边界 → 内部结构
→ 系统协作 → 架构表达与评审 → 运行反馈与持续演进

其中，六维画布、8 段式 TD 和四阶段评审是本书为日常工程协作归纳的工作框架；DDD、Clean Architecture、CQRS、Outbox、Saga 等模式则是应对不同问题的工具，不是默认答案。

1.1 系统设计与工程决策

从问题开始，而不是从组件开始

系统设计首先要定义问题。一个完整的问题定义至少包含四件事：谁在什么场景下遇到了什么困难；业务希望改善什么结果；哪些条件不可违反；哪些事情本次明确不做。没有这些信息，“高可用”“低延迟”“支持百万用户”都只是缺少上下文的口号。

例如，“提升下单性能”可能对应完全不同的问题：高峰期接口 P99 过高、库存热点导致大量失败、支付回调重复、运营活动成本超标，或客服无法解释订单状态。它们可能分别需要排队削峰、库存分片、幂等设计、容量治理或状态机与审计，而不是统一地“加缓存”。

这张表的目的不是一次写全，而是把隐含假设公开化。设计讨论中最值得争论的往往不是“Kafka 还是 RabbitMQ”，而是“允许多长时间的最终一致”“库存扣减失败谁来补偿”“是否必须保留可追溯事实”。

用数量级建立共同现实

容量估算不追求伪精确，而是防止方案脱离现实。对核心链路，至少估算请求量、峰谷比、读写比例、单次请求的数据量、存储增长、可接受延迟和可接受错误率：

峰值 QPS ≈ 日请求量 × 峰值占比 ÷ 峰值持续秒数
日增数据量 ≈ 日写入次数 × 单次有效载荷

公式的价值在于暴露假设。例如日均一千万次请求、20% 集中在两小时内，峰值并不是“日均 QPS 乘几个倍数”可以轻易带过；一条业务事件若需要保留七年，存储、索引、冷热分层和审计成本也必须在方案阶段讨论。容量应围绕实际负载、服务目标与增长预期持续校准，而不是只按当前机器余量决策。[2]

权衡不是妥协，而是设计本身

可靠、可扩展、可维护是数据密集型系统的长期目标，但它们不会自动同时达到。[1]

好的方案会写出取舍，而不是宣称“既高可用、又强一致、又低成本、还零复杂度”。当某项质量属性被优先保障时，也要明确它带来的代价、适用范围和重新评估的触发条件。[3]

从单机思维切换到分布式思维

单机程序中，一个函数调用通常意味着同一进程、同一事务和明确的成功或失败；分布式系统中，网络会超时、消息会重复、节点会部分失效、时钟并不可靠。因而设计需要先回答：

• 请求超时后，调用方能否确认服务端没有执行？
• 同一个命令被重试时，业务结果会不会重复？
• 本地成功、远端失败时，谁拥有最终收敛责任？
• 用户看到“处理中”时，系统如何告知最终状态？

这些问题使失败路径与正常路径同等重要。不要把分布式设计理解成服务越多越先进；服务拆分只有在业务边界、团队责任、独立扩展或故障隔离的收益足以覆盖网络复杂度时才值得采用。

用质量属性场景校准讨论

“系统要高性能”无法直接指导设计。更有效的表达是把质量要求写成可观察的场景：在什么条件下，哪个刺激作用于哪个部分，系统应如何响应，如何测量结果。例如“活动开始后的十分钟内，订单创建接口 95% 请求在 300 ms 内返回受理结果；库存依赖故障时，不得重复下单，并在一分钟内将请求转为可查询的处理中状态”。这样的表述把性能、可用性、正确性和恢复行为放进同一个可测试的边界。[3]

质量属性场景还可以防止团队在不同层次争论同一个词。产品关心的是用户何时得到明确结果，研发关心的是同步链路和资源上限，运维关心的是告警与恢复窗口；把它们写成一个场景后，才有可能设计出共同接受的指标、降级行为和验收测试。

需求澄清：把一句话需求拆成可验证的设计输入

真实项目很少以完整的技术问题开始。更常见的表达是“把订单系统做成平台”“支持多渠道库存”“让结算更快”，这些句子同时混合了业务愿望、解决方案暗示和组织目标。直接把它们翻译成服务、表和接口，容易在还没有确认问题之前就锁定实现。需求澄清的任务不是替业务方写一份更长的需求说明，而是把一句话拆成可以共同验证的设计输入。

可以先连续追问五个问题：谁遇到了问题；在什么业务事件发生时最明显；当前损失是什么；成功结果由哪个事实证明；本次明确不处理什么。以“支持多渠道库存”为例，真正需要确认的可能是渠道库存展示不一致、库存分配规则无法配置、渠道订单回传延迟，或者仓库无法解释锁定库存。它们的事实源、时效目标、责任团队和补偿路径都不相同。

中文工程实践中对 DDD 的总结也反复强调，模型的价值在于表达业务事实，而不是把技术分层换一套名称。[14][15] 因此，需求澄清应当产出术语表、业务事件时间线、目标与非目标、初步指标和争议问题清单，而不是先产出一张“微服务架构图”。这些产出会成为后续 TD、上下文地图和验收测试的共同输入。

常见误区：把架构问题误写成组件问题

系统设计初期有几类错误非常稳定。第一类是“先选技术”：因为团队熟悉某个数据库、消息系统或云产品，就把业务问题改写成它能解决的问题。第二类是“先拆服务”：把每个名词都做成一个服务，却没有定义数据主权、失败语义和独立运维能力。第三类是“只画正常链路”：架构图上只有成功箭头，超时、重复、乱序、回滚和人工处理被留到上线后再补。第四类是“用平均值替代尾部”：平均延迟很好看，但 P99、排队时间和依赖失败时的响应才决定用户体验。第五类是“把历史兼容当作永恒事实”：为兼容旧接口不断增加旁路，最终没有任何团队敢删除旧路径。

识别误区后，不能只给出相反口号。例如“不要微服务”并不能替代边界分析；“全部异步化”也不能解决用户必须立即知道结果的场景。更有效的做法是把每个争论改写成可验证的问题：该组件消除了哪个瓶颈？服务拆分后谁拥有数据和告警？异常路径如何收敛？新旧接口何时可以停止兼容？如果答案只能依赖“以后再补”，说明方案还没有达到可评审状态。

1.2 技术方案设计与 TD

TD 的目的：让决策可评审、可执行、可追溯

技术方案（Technical Design，TD）不是把需求换成架构图，也不是为了在评审会前制造一份长文档。它的作用是让团队在编码前对目标、边界、备选方案、风险和验证方式形成共同理解。优秀的 TD 让读者知道：要解决什么、为什么选择此方案、谁需要配合、失败后怎么办，以及上线后如何证明设计有效。

对影响边界、数据模型、接口契约、容量或发布方式的变更，TD 通常值得投入。小范围、可逆、无需跨团队协作的改动，可以在 Merge Request 中说明背景与验证即可。ADR 适合记录一项已经做出的关键决策及其后果；它应当短小、不可随意改写，并在决策被替代时链接到新的记录。[4]

设计阶段：六维画布

在写 TD 前，先完成一轮显式设计。六维画布不是标准规范，而是本书建议的思考顺序：它避免团队只讨论技术选型，却漏掉边界、数据、失败和运行现实。

一张带假设的容量表、一条主链路时序图、一张上下文图和一份风险清单，通常比几十页组件介绍更能帮助评审。信息不完整时，应把未知项列为待验证假设，而不是用“后续再看”掩盖它。

8 段式 TD 骨架

完成画布后，可以按下列顺序组织 TD。顺序对应评审者理解方案的路径：先判断值不值得做，再判断是否做对，最后判断能否安全落地。

简单需求可以合并段落，跨系统变更则必须把接口、异常路径和发布计划写清楚。关键是让文档与决策复杂度匹配，而不是把模板当成官僚流程。

一个最小 TD 的推导示例

以“订单创建后异步通知履约”为例，需求表面上只是增加一个通知动作。若不先做设计，它很容易演化为订单服务在数据库事务里直接调用履约接口：接口慢时拖慢下单，接口异常时订单是否应回滚没有答案，重试又可能重复创建履约单。

用六维画布推导后，问题会被改写得更准确：订单创建必须先稳定落库；履约接收可以异步，但事件不得丢失；重复通知不能重复履约；用户需要能查询订单是否已进入履约流程。相应的 TD 不需要长篇代码，只需明确以下决策：

这个例子说明，TD 的价值不在于提前规定每个类和每张表，而在于提前暴露“同步还是异步”“谁拥有事实”“失败怎样收敛”这些会影响长期成本的问题。实现细节可以在编码阶段调整，边界和验收标准则应在开发前取得一致。

决策记录、评审与交付

技术评审应围绕事实和选择展开。评审者不应只问“图画得是否完整”，还应挑战：目标是否能通过指标验证；关键假设不成立时方案会怎样失效；数据所有权和接口责任是否一致；是否存在更简单、可逆或更容易迁移的方案；灰度、回滚、补偿和人工处理是否真的可执行。

建议把有长期影响的选择抽成 ADR，例如“订单域采用读写分离”“库存预占采用异步确认”。ADR 不替代 TD：TD 解释一次完整变更，ADR 固化其中值得长期记住的关键取舍。[4] TD 的最后一页也不应停在“待开发”，而要转化为接口契约、迁移步骤、验收指标、负责人、依赖方、灰度开关和回滚预案。

当需求仍有较大不确定性时，可以把方案拆成“先验证、再扩展”的两步：先用最小实现验证业务规则、流量假设或用户行为，再决定是否投入完整的平台化能力。TD 要写清第一步能够证伪什么、达到什么阈值才进入第二步。这样既避免把探索性需求过度架构化，也避免在关键假设未验证前锁死后续选择。

1.3 架构设计核心方法

技术方案并非一次性文档：当关键假设、边界、依赖或发布策略变化时，应同步审阅相关 TD 与 ADR；过期文档比缺少文档更容易误导后续决策。

文档更新不必追求重写全文，但必须能让后来者找到仍然有效的决策、已被推翻的假设，以及下一次评审应重点检查的风险。

一套递进的组合拳

复杂业务系统不需要先选择“DDD 项目”或“Clean Architecture 项目”。更有用的顺序是：先用领域建模划清业务边界，再用依赖规则建立内部秩序；当读写特征显著不同，再考虑 CQRS；当一次业务动作跨越多个边界，再用事件、Outbox、Saga 和对账建立协作机制。每一层都应由实际复杂度触发。

业务复杂度高      → DDD 战略设计：术语、子域、限界上下文、ACL
内部依赖失控      → 分层与依赖向内：端口、用例、领域模型、适配器
读写模型冲突      → CQRS：命令模型与查询模型按需分离
跨边界事务复杂    → 事件、Outbox、Saga、幂等、补偿与对账
设计持续失真      → 架构/设计/代码/上线前四阶段评审

先划业务边界：DDD 战略设计

许多大泥球系统的根因不是类写得不够优雅，而是所有概念都被假定为同一个模型。例如商品在供给侧可能表示可编辑的资料，在交易侧表示下单快照，在搜索侧表示面向检索的文档；强行共享一个对象，只会让每个团队都被其他场景的字段和节奏牵制。

领域驱动设计强调从领域语言与模型开始处理复杂性。[5] 在战略层面，最重要的产出是：

• 通用语言：业务、产品、研发和运营对关键术语有可追溯的一致定义。
• 限界上下文：一个模型在哪个边界内成立；同名概念在不同上下文可以有不同含义。
• 上下文映射：上下文之间如何协作，谁是上游，谁维护契约，哪里需要防腐层（ACL）。

以交易为例，商品、库存、订单、支付可以先作为不同上下文，而不是急于拆成四个独立服务。先明确谁拥有价格快照、谁决定库存可售、谁维护订单状态、谁确认支付事实，再决定它们以模块、进程还是独立服务的形式部署。限界上下文首先是模型和责任边界，微服务只是可能的部署结果。

事件风暴、领域故事和四色建模可以帮助发现事件、命令、角色、规则与生命周期；但它们是协作手段，不是必须照抄的图形语言。一次有效的建模工作坊至少应产出一条业务事件时间线、争议术语清单和初版上下文地图。

从模型边界到部署边界

模型边界并不自动等于进程边界。把限界上下文立即拆成微服务，往往会过早引入远程调用、分布式追踪、独立发布和跨服务一致性等成本；反过来，把所有上下文长期塞进同一模块，也会让模型和团队责任重新混杂。更稳妥的做法是把部署视为一个后续决策，并先建立可验证的模块边界。

一个上下文先以模块化单体落地，通常已经能获得不少收益：目录和依赖清晰、数据访问受控、测试可以围绕用例运行、团队能够明确模块负责人。只有在下面的信号持续出现时，才认真评估拆分：某个边界需要独立扩缩容或独立故障隔离；变化节奏与发布窗口长期不同；数据主权与安全要求必须隔离；团队已具备独立构建、部署、观测和 on-call 的能力。

这个判断避免把“微服务化”当成成熟度标志。架构演进的目标是降低未来变更的总成本，不是增加可展示的组件数量。即使最终决定拆分，也应先定义契约、迁移数据、保留兼容窗口，再逐步切换流量；不要把一次组织调整或技术潮流变成不可逆的大爆炸改造。

从模块化单体走向独立部署，通常可以按“封装、观测、复制、迁移、切流、删除”的顺序推进。先封装模块的入口和数据访问，阻止新增跨模块直连；再补齐调用链、业务指标和所有权；随后为候选边界复制出独立实现或影子读模型；通过双写、回放或校验任务验证结果；最后用小比例流量切换，并在兼容窗口结束后删除旧路径。这里的双写不是天然正确的方案，它会制造新旧数据漂移，因此必须配套版本号、校验任务和停止双写的退出条件。渐进式替换旧实现的思路，也可参考绞杀者模式对兼容层、切流和删除旧路径的总结。[19]

如果拆分只是为了追赶技术潮流，迁移成本往往高于收益。只有当边界能够独立变化、独立扩展、独立隔离故障或满足明确的数据治理要求时，才值得承担远程调用、部署、监控和一致性成本。AWS 的领域服务设计建议也把“围绕业务领域和能力聚焦”作为服务边界的重要依据，同时提醒团队不要让服务跨越多个业务边界。[17]

拆分后的第一项验收也不应是“服务已经启动”，而应是边界是否真的独立：调用方是否只能通过契约访问能力，是否仍有跨库读写，失败是否被限制在可接受范围，发布与回滚是否不再依赖所有团队同步操作。若这些条件尚未满足，拆分只是把进程内耦合换成了网络耦合。

再建内部秩序：依赖方向比目录名称更重要

传统三层架构擅长回答“接口、业务和数据访问代码放在哪里”，适合大多数业务系统起步。随着业务规则、外部依赖和测试要求增长，真正需要约束的是依赖方向：核心业务不应依赖 HTTP、数据库、消息队列或具体框架，而应由外层适配这些技术细节。

Clean Architecture 的价值正在于此：让依赖朝向稳定的业务规则和抽象接口，而不是让领域模型被基础设施吞没。[6]

对于复杂领域，DDD 的战术模式帮助代码承载模型：实体表达身份，值对象表达无身份的业务概念，聚合守护一致性不变量，Repository 隔离持久化细节。聚合的关键不是“把关联对象都装进来”，而是定义一次业务事务中必须共同保持正确的最小边界。跨聚合引用通常使用标识符；跨边界协作则通过明确的命令、查询或事件完成。[5]

一个订单聚合可以守护“已取消订单不能支付”“应付金额不可为负”等本地不变量；它不应直接承担调用支付渠道、更新搜索索引或通知营销系统。这些动作属于用例编排或异步协作。

CQRS：只在读写矛盾真实存在时分离

命令查询职责分离（CQRS）允许写入模型和读取模型使用不同的数据结构。它适合写侧需要严格业务规则、读侧需要多维查询或高并发展示的场景，例如订单写入要守护状态机，运营查询却需要按用户、商品、渠道、时间和状态聚合。

但 CQRS 会引入投影延迟、数据同步、回放、监控和排障成本。Martin Fowler 也特别提醒：它对少数复杂场景有价值，对大多数系统却可能增加风险性复杂度。[7] 因而选择前应回答：单一模型是否已经无法同时满足写入正确性和读取性能？读模型多久同步一次，用户是否能接受该延迟？投影失败、重复消费和重建时谁负责修复？团队是否具备观测和运营两套模型的能力？

如果答案不充分，先保持同一模型或采用轻量的读库、缓存和预计算通常更好。CQRS 不等于事件溯源；前者是职责分离，后者是把事件作为状态事实的存储方式，两者可以组合，也可以独立采用。

一个贯穿式案例：从“订单平台化”推导出可交付方案

下面用一个简化案例说明方法如何串联。假设业务提出“把订单系统平台化，支持多个销售渠道，并在大促时保持稳定”。如果直接进入技术选型，讨论很快会变成“是否上微服务、消息队列选什么、订单表是否分库”。先按本章工作链路拆解，才能知道哪些设计问题真正重要。

第一步是定义范围。订单平台负责接收下单意图、保存订单事实、维护订单生命周期，并向库存、支付、履约和营销上下文发布稳定事件；它不负责库存可售计算、支付渠道路由和仓库内部作业。第二步是写出约束：创建请求需要在 300 ms 内返回受理结果，订单事实不能因下游暂时不可用而丢失；库存和支付可以在后续阶段收敛，但用户必须能够查询处理中、成功或失败的明确状态。第三步是画出状态机：待确认 → 已创建 → 待支付 → 已支付 → 履约中 → 已完成，并列出取消、超时和人工介入等旁路状态。

这个案例中，微服务不是第一项决策。先确定订单事实和生命周期，才能判断订单是否需要独立部署；先确定受理结果和最终结果的区别，才能决定哪些调用同步、哪些事件异步；先定义重复请求和未知结果，才能评估幂等键、状态查询和对账。最终方案可能是模块化单体，也可能是多个服务，但它们都应能通过同一组业务事实和验收指标被验证。

架构评审时可以要求团队走完三条路径：正常下单、支付超时、库存服务不可用。每条路径都要指出状态如何推进、哪个组件写入事实、哪些消息会重试、用户看到什么、谁负责最终修复。如果只能讲清正常路径，说明方案还没有把业务状态和运行治理真正设计出来。

系统协作：把一致性设计成一条链路

跨上下文业务动作很难用一个数据库事务保证。例如创建订单后要预占库存、确认支付、发放权益；任何一步失败，都可能出现局部成功。此时最重要的不是“有没有分布式事务”，而是明确状态、消息、补偿和对账责任。

本地事务：更新业务状态 + 写入 Outbox 事件
        ↓
Relay 可靠投递事件（允许至少一次）
        ↓
消费者以幂等键处理，更新自己的本地事实
        ↓
失败时重试、补偿或转人工；定期对账发现遗漏与漂移

Transactional Outbox 将业务更新和待发布消息写入同一事务；独立 Relay 再向消息系统投递。它避免了“数据库已提交但事件尚未发出”的窗口，但仍可能重复投递，因此消费者必须具备幂等能力。[8] Saga 将跨服务长事务拆成一组本地事务；失败时执行显式补偿，而非期待全局自动回滚。[8]

设计时必须写清：幂等键来自哪里、重复请求返回什么、补偿是否真的可逆、消息乱序如何处理、对账依据哪个事实源、人工介入后的状态如何回写。对账不是失败的象征，而是最终一致系统中验证和修复业务事实的最后防线。

把容量与韧性写进设计，而不是上线后补救

一致性方案如果没有容量和故障设计，通常难以在生产环境中成立。Outbox 表会积压、消费者会落后、重试会形成流量放大、下游故障会反向拖垮上游。因此，在 TD 中至少应说明核心队列或事件流的正常积压水位、可接受恢复时间、重试上限、死信处理方式和人工介入入口。

容量规划不是只算机器数量，而是为关键业务状态留出缓冲。降级也不是简单返回错误：对下单这类链路，可能是返回“已受理、处理中”；对查询类链路，可能是返回带时间戳的旧数据；对非关键功能，则可以暂时关闭。每一种降级都必须被产品、客服和运营理解，否则技术上成功保护了系统，业务上却制造了不可解释的用户体验。

用分阶段评审防止设计失真

只在 Pull Request 阶段做 Code Review 往往太晚：聚合边界、服务职责或一致性路线若有问题，代码写完后才发现会让返工成本急剧上升。本书建议把评审前移为四个阶段：

代码评审仍然非常重要：Google 的公开指南将设计、功能、复杂度、测试、可读性和长期代码健康视为评审重点，而不是只检查格式。[12] 但评审者不应试图在 PR 中重新设计整个系统。若发现架构问题，应把讨论升级为设计决策，再回到实现。

四个阶段的边界并不意味着四次冗长会议。低风险改动可以把架构与设计判断浓缩在 TD 或 MR 描述中，高风险改动才需要专门评审。关键在于问题要在仍然容易改变的阶段被提出：边界问题在编码前发现，错误语义在合并前发现，容量与回滚问题在发布前发现。这样，评审不是减慢交付的关卡，而是减少返工、事故和跨团队沟通成本的反馈机制。

1.4 架构表达与评审

图不是装饰，而是不同层次的共同语言

架构图的目标不是把系统所有组件塞进一张图，而是帮助特定读者在特定问题上做判断。C4 Model 以系统上下文、容器、组件和代码等层次组织静态结构，并补充动态与部署视图；团队不必每次画齐所有层次，只画能增加决策价值的视图。[9]

静态图负责定边界：谁拥有数据、谁依赖谁、哪些模块可替换。动态图负责拉主轴：一次请求或事件如何穿过系统、何处同步等待、何处异步交接、失败怎样处理。图中的箭头必须有语义，例如 HTTP 查询、发布领域事件、读取只读投影，而不是只画无标签连线。

让图、文档和代码相互校验

一张图不能替代设计文档，设计文档也不能替代代码；三者应形成可相互验证的关系。上下文图中的边界应能在 TD 的职责与数据所有权部分找到解释；时序图中的每一次跨边界交互应能在 API 或事件契约中找到定义；代码中的模块依赖应不违背容器图和 ADR 的关键选择。发生偏差时，应先判断是实现偏离了设计，还是新的事实证明原设计需要调整，而不是让图、文档和代码各自演化。

对长期维护的系统，图也应有生命周期。核心上下文图、主链路时序图和部署图应跟随重大边界、协议和运行变化更新；临时讨论图可以在决策沉淀后归档。这样既避免把画图变成额外负担，也避免新成员只能从过期文档或源码猜测系统意图。

让图能够经受挑战

评审中的图至少应让读者回答四个问题：这张图的范围和读者是谁？每个节点负责什么，数据由谁拥有？每条连接是同步还是异步，失败时会发生什么？图上的设计选择如何对应质量目标和监控指标？

若无法回答，通常不是图画得不够漂亮，而是边界、协议或异常语义尚未想清楚。C4 的图表检查清单也强调标题、范围、图例、元素语义和关系标签的明确性。[9]

评审是一种协作机制

高质量评审不等于找到最多问题，而是让团队以最低成本提升决策与代码质量。评审材料应在会前提供；会上优先讨论有分歧的假设、不可逆决策和高风险链路；会后记录结论、待办和责任人。对“应该用什么模式”的争论，应回到问题：它改善了哪项质量属性，新增了什么运行成本，何时需要撤销或替换？

技术方案、ADR、架构图、测试、仪表盘和复盘记录共同构成系统的可解释性。它们不是额外负担，而是让未来维护者理解“为什么这样做”的工程资产。[4][10]

评审要覆盖主链路，也要覆盖变化路径

一次技术评审至少选择一条成功路径和两类失败路径。成功路径验证职责、数据和协议是否连贯；依赖失败路径验证超时、降级、重试和补偿是否明确；变更路径则验证版本兼容、数据迁移、灰度发布与回滚是否真的可执行。对于跨团队接口，还应确认字段新增、枚举扩展、事件重放和消费者升级的兼容规则。

评审结论不必追求“所有问题都一次解决”。更重要的是把问题分类：阻塞上线的风险必须解决；可以接受但需要监控的风险要写入 ADR 或发布计划；暂不处理的债务要说明触发重访的条件。这样，评审既不会退化为形式化签字，也不会因为追求完美而阻塞合理交付。

1.5 架构师工程思维

从局部最优转向长期价值

架构师的职责不是替所有人决定技术细节，而是在不确定性下持续改善团队的决策质量。一个看似合理的局部优化，可能把复杂度转移给下游团队、运维人员或未来维护者。因此，每个重要决策都应经过至少五个滤网：业务价值、质量属性、实现与运行成本、组织协作，以及未来变化的可逆性。

康威定律提醒我们，系统的沟通结构往往会反映组织的沟通结构。[13] 这不是把组织图机械映射为微服务图，而是要求设计者看见责任边界、认知负荷和交付流。若一个模块必须由三个团队同时修改，或者一个服务的运行知识只掌握在个人手里，再漂亮的模块划分也难以长期健康。

简单是管理复杂度，不是否认复杂度

奥卡姆剃刀在工程中的含义不是“永远选最少组件”，而是避免引入不能证明价值的机制。系统确实需要复杂性时，应让复杂性集中在边界清晰、可观测、可测试的位置；不需要时，应保留更简单、可理解的实现。

例如，模块化单体往往比过早微服务更适合作为起点；一张明确定义的事件契约比共享数据库更容易演进；一次可逆的灰度发布比大爆炸式重构更可控。演进式架构主张把变化视为常态，并通过适应度函数、自动化验证和渐进式迁移保护关键架构特性。[11] 遗留系统的领域模型也不应被当作一次性设计；业务认知变化后，模型、边界和实现需要通过反馈持续调整。[16]

工程思维也意味着把“谁来做”纳入设计。一个方案即使技术上正确，如果没有明确的服务所有者、值班责任、接口维护者和迁移负责人，最终仍会在组织边界处失效。架构师应帮助团队把责任写入运行手册、代码所有权和发布流程，并通过复盘持续修正；这比单次输出一份完美架构图更能提高系统的长期质量。

组织边界还会影响架构演进速度。一个需要多个团队同时修改、共同值班却没有单一责任人的模块，会产生排队、反复沟通和风险转移。反过来，盲目按组织现状拆服务也会把暂时的汇报关系固化成长期的技术边界。更稳妥的做法是先识别端到端交付流，再检查团队是否拥有完成该交付流所需的能力；如果能力缺失，可以通过平台能力、清晰的契约和短期协作降低认知负荷，而不是马上复制更多服务。团队拓扑的讨论也强调，应让团队边界服务于交付流和认知负荷，而不是让系统被组织图机械切割。[20]

用质量属性场景做取舍

ATAM 等架构评估方法的核心启发是：不要抽象地讨论“系统要高可用”，而要用具体场景表达质量属性。[3]

在大促峰值期间，订单创建接口在 95% 请求中应在 300 ms 内返回受理结果；当库存服务不可用时，系统应在 1 秒内降级为“排队处理中”，不得重复创建订单，并在恢复后完成或取消处理。

这个场景同时明确了负载、响应目标、故障条件、降级行为和正确性约束。它比“高性能、高可用”更容易指导架构、测试和监控。

ATAM 的另一个重要启发是把“质量属性场景”与“敏感点、权衡点和风险”联系起来：某个缓存策略可能改善延迟，却增加数据新鲜度风险；某个同步校验可能改善正确性，却压缩高峰吞吐；某个服务拆分可能改善独立发布，却增加跨边界故障。评审不应只列出属性名称，而要指出哪项设计同时影响了多个目标，以及将用什么实验或指标验证它。SEI 对 ATAM 的正式说明也把场景、架构决策和权衡分析放在同一个评估过程中。[18]

架构师要留在反馈闭环里

架构设计不会在评审通过时结束。上线后的指标、告警、故障、用户反馈、研发效率和团队协作摩擦，都会检验原先的假设。架构师需要定期回看：哪些决策产生了预期收益，哪些复杂度没有回报，哪些边界已经不再适合业务变化。

复盘时不必把每次故障都归因于“实现不够仔细”。更值得追问的是：当时遗漏了哪项假设？边界、契约、监控或发布流程中缺少了什么反馈？将答案写回 ADR、Checklist、自动化测试或运行手册，才能让一次经验真正降低下一次决策成本。

当同一类问题反复出现时，应把它视为系统性信号：也许是模型边界不清，也许是接口契约缺少版本策略，也许是团队缺少足够的演练和所有权，而不应只靠某位工程师更谨慎来维持质量。

最有价值的架构能力，最终不是记住多少模式，而是持续把模糊问题转化为可验证假设，把复杂选择转化为清晰边界，并让团队有能力在变化中安全地改进系统。

1.6 小结与阅读导航

本章建立的是一条工程决策主线：从问题、约束与数量级开始，用六维画布形成设计，再用 TD、ADR 和评审把决策沉淀下来；随后以领域边界、依赖方向、读写分离和可靠事件协作组织系统，最后通过架构视图、运行反馈和演进思维持续验证。

后续章节将把本章的概念拆开落地：

• 第 2 章：编码、重构与 Code Review 讨论架构意图如何进入日常代码与评审。
• 第 3 章：生产治理与韧性保障 展开 SLO、观测、限流、熔断、降级和故障治理。
• 第 4 章：大事务与跨系统编排 深入 Saga、Outbox、补偿、幂等与对账。
• 后续方法论章节分别处理长生命周期流程、任务处理、强一致、复杂读与高并发写；第二部分则用商品、库存、订单、支付等场景验证这些方法。

读完本章后，读者不必急于采用所有模式，但应能够拿一个真实需求回答：目标和非目标是什么？谁拥有业务事实？关键质量属性怎样排序？失败后如何收敛？为什么当前复杂度值得承担？

1.7 参考文献与延伸阅读

本节汇总正文引用源。正文中的编号用于就近说明概念来源；完整书目按“先建立主线、再按问题深入”的方式组织。链接优先指向作者、出版方或长期维护的官方页面。

架构决策、可靠性与容量

[1] Kleppmann M. Designing Data-Intensive Applications[M]. O’Reilly Media, 2017. 建立可靠性、可扩展性、可维护性，以及数据系统权衡的主线。

[2] Beyer B, Jones C, Petoff J, Murphy N R, eds. Site Reliability Engineering[M]. O’Reilly Media, 2016；《The Site Reliability Workbook》 提供容量、服务目标和运行实践的补充。

[3] Bass L, Clements P, Kazman R. Software Architecture in Practice[M]. 4th ed. Addison-Wesley, 2021. 适合系统理解质量属性、架构视图、评估与演进。

[4] Fowler M. Architecture Decision Record[EB/OL]. 适合了解短决策记录的背景、状态与替代关系；概念由 Michael Nygard 在 2011 年的实践中推广。

领域建模、内部结构与读写分离

[5] Evans E. Domain-Driven Design: Tackling Complexity in the Heart of Software[M]. Addison-Wesley, 2003. 重点阅读通用语言、限界上下文、聚合与战略设计。

[6] Martin R C. Clean Architecture: A Craftsman’s Guide to Software Structure and Design[M]. Prentice Hall, 2017. 用于理解依赖倒置、边界与独立于框架的核心业务规则；实现时应结合项目复杂度谨慎取舍。

[7] Fowler M. CQRS[EB/OL]. 2011. 说明读写模型分离的价值与额外复杂度，适合作为 CQRS 选型的反过度设计提醒。

[8] Richardson C. Saga；Transactional Outbox[EB/OL]. Microservices Patterns. 用于理解跨服务本地事务、补偿、可靠发布和幂等消费的关系。

架构表达、评审与持续演进

[9] Brown S. The C4 Model for Visualising Software Architecture[EB/OL]. 重点参考 diagram levels 与 review checklist，按受众选择必要视图。

[10] Clements P, Bachmann F, Bass L, et al. Documenting Software Architectures: Views and Beyond[M]. 3rd ed. Addison-Wesley, 2011. 适合系统学习架构文档的视图、受众与记录方式。

[11] Ford N, Parsons R, Kua P. Building Evolutionary Architectures[M]. O’Reilly Media, 2017. 适合进一步学习演进式架构、适应度函数与渐进式变更。

[12] Google. Engineering Practices: Code Review Guide[EB/OL]. 重点参考 What to look for in a code review，将设计、正确性、测试和可维护性纳入日常评审。

[13] Conway M E. How Do Committees Invent?[J]. Datamation, 1968, 14(4): 28–31；Skelton M, Pais M. Team Topologies[M]. IT Revolution, 2019. 共同用于理解组织结构、团队认知负荷和系统边界之间的关系。

[14] 文彬, 子维. 领域驱动设计在互联网业务开发中的实践[EB/OL]. 美团技术团队, 2017. 用于补充中文互联网业务中从模型、分层到代码落地的实践观察。

[15] 阿里云开发者社区. 领域驱动设计（DDD）-基础思想[EB/OL]. 阿里云, 2020. 用于说明 DDD 与具体架构风格的关系，以及领域层、应用层和基础设施层的职责边界。

[16] Nik Silver, Mat Wall. 演进架构中的领域驱动设计[EB/OL]. InfoQ 中文, 2009. 中文译文；用于补充业务模型演进、遗留系统重构和架构适应变化的案例。

[17] AWS. Build services focused on specific business domains and functionality[EB/OL]. AWS Well-Architected Framework, 2023. 用于服务边界、业务领域聚焦和避免跨领域服务的实践说明。

[18] Carnegie Mellon Software Engineering Institute. Architecture Tradeoff Analysis Method Collection[EB/OL]. SEI. 用于质量属性场景、敏感点、权衡点和风险分析。

[19] Fowler M. Strangler Fig Application[EB/OL]. Martin Fowler’s Bliki. 用于说明通过兼容层、渐进切流和逐步删除旧实现推进架构迁移。

[20] Skelton M, Pais M. Team Topologies[EB/OL]. Team Topologies. 用于理解团队认知负荷、流对齐团队、平台团队与系统边界之间的关系。

建议阅读路径

若刚开始建立系统设计方法论，可按 1 → 3 → 5 → 9 建立数据、架构、领域与表达的共同语言；正在处理跨系统一致性时，重点阅读 8，并结合本书后续的大事务章节；希望提升方案评审与团队协作时，重点阅读 4、10、12 与 13。全书范围内的资料索引见附录 B：参考文献与延伸阅读。

第 2 章 编码、重构与 Code Review：构建可演进代码的实践方法

把架构意图写成可读、可测、可重构、可审查的代码，并通过高质量 Review 持续阻止系统走向腐化。

第 1 章讨论的是系统设计与技术方案写作，回答了“为什么这样设计”和“如何把设计讲清楚”。但真正决定系统长期质量的，往往不是 PPT 上的架构图，而是每天进入仓库的代码。

很多团队在方案阶段讲得很好，落地时却迅速失真：

• 设计文档里分层清晰，代码里却出现跨层直连；
• 领域边界在图里很优雅，提交里却把 Controller、Service、DAO 和第三方调用揉成一团；
• 大家都知道要做幂等、超时、补偿和监控，但真正写代码时这些保障常常遗漏；
• 团队也做 Code Review，但流于“看起来没问题”或“只是挑格式”，没有真正拦住设计偏移和线上风险。

所以这一章不再把“编码”理解成语法熟练度，也不把“重构”理解成推倒重写，更不把“Code Review”理解成合并前的礼貌动作，而是把它们一起看成架构执行力的一部分。一个成熟的工程团队，至少要在三个层面上同时达标：

• 编码阶段：把复杂业务拆成清晰边界、稳定抽象和可验证实现。
• 重构阶段：在不停止交付的前提下，持续修复边界失真、抽象退化和历史包袱。
• 评审阶段：在缺陷、耦合和错误模式进入主干前，把问题尽可能提前暴露。

这种闭环在 AI 辅助编码普及后反而更重要。代码生成工具可以快速补齐 DTO、适配器和测试骨架，却不会自动拥有当前业务的隐含约束，也不会替团队承担并发、幂等、数据一致性和回滚责任。代码越容易生成，团队越需要把边界和验证写成机器能够检查的规则。

读完本章，你应该能建立三件事的共同语言：

• 什么样的代码，才算真正支持系统长期演进。
• 老代码开始腐化时，应该如何小步重构，而不是等到必须重写。
• Code Review 到底在审什么，而不只是“帮忙看一眼”。
• 架构师、开发者、Reviewer 分别应该承担什么责任。

2.1 为什么架构最终会输在代码细节上

2.1.1 架构不是画出来的，是提交出来的

系统设计常常失败，不是因为没人知道应该分层、隔离依赖、控制一致性，而是因为这些原则没有被持续写进代码。架构图表达的是目标形态，代码库体现的才是真实形态。

如果一个团队长期容忍下面这些现象，再好的技术方案也会被慢慢掏空：

• Handler 直接拼 SQL；
• 领域对象里混入远程调用和缓存访问；
• “临时”分支逻辑逐步堆成主流程；
• 为了赶需求，把异常处理、超时控制、回滚语义留给“后面补”。

时间一长，团队面对的就不再是“如何实现新需求”，而是“改一行为什么会炸三处”。这类问题本质上不是功能问题，而是代码结构已经不再承载架构意图。

2.1.2 代码质量差的真实代价

很多人把代码质量理解成审美问题，仿佛只是“优雅不优雅”。但对业务系统来说，代码质量的代价非常具体：

架构师尤其不能把这些问题看成“实现细节”。系统能否长期演进，往往不是取决于是否用了微服务、CQRS、Saga 这些名词，而是取决于每一次提交是否在强化还是侵蚀边界。

2.1.3 架构师为什么必须懂编码和 Review

架构师不一定要承担最多业务代码，但必须对代码落地保持足够近的距离。原因很简单：

• 设计是否真的可实现，只有进入代码以后才会暴露真实摩擦；
• 团队抽象是否过度、边界是否失真，Review 时最容易看出来；
• 如果架构师长期离开编码现场，方案会越来越像“理想模型”，而不是可落地工程。

一个可操作的底线是：核心链路的关键模块，架构师至少要能定期深度 Review，并能亲自写出代表团队标准的样例代码。

flowchart LR
	A[架构设计] --> B[代码实现]
	B --> C[Code Review]
	C --> D[合并与发布]
	D --> E[线上反馈]
	E --> A

这条闭环里，编码和 Review 不是末端动作，而是把设计变成现实、再把现实反馈给设计的关键环节。

2.1.4 AI 辅助编码时代的架构防守

AI 辅助编码改变的是代码生产速度，不是业务约束本身。它很擅长生成重复性高、局部上下文充分的代码，例如请求对象、数据访问适配器、序列化逻辑和测试样板；但它很难仅凭一个函数或一个文件判断以下问题：

• 领域规则是否必须由聚合根保护，而不是由每个调用方自行记忆；
• 一个超时后的重试是否可能重复扣减、重复发消息或重复创建订单；
• 新模块是否越过了依赖边界，直接访问了数据库、缓存或第三方客户端；
• 旧接口、旧数据和旧消费者是否仍然兼容；
• 失败后系统最终应该进入什么状态，以及由谁负责补偿。

因此，AI 时代的 Review 重点不是“代码是不是 AI 写的”，而是把人工注意力放到 AI 无法替团队决定的地方：业务不变量、状态迁移、并发语义、分布式一致性、权限边界和恢复路径。语法、格式、简单的错误检查和部分依赖约束，应尽量交给编译器、Lint、测试和 CI。

可以把 AI 生成代码的验收分为三层：

这也是架构师在 AI 编程时代的新职责：不是亲自审查每一行生成代码，而是把团队的设计原则转化成 Prompt 约束、代码模板、静态检查、测试夹具和发布门禁。只有这样，Review 才不会成为吞噬所有注意力的人工补丁。

2.2 好代码首先是边界清楚

2.2.1 先问职责，再写函数

很多坏代码并不是因为工程师不会写，而是因为下笔前没先回答一个问题：这段代码到底属于哪一层、承担什么职责。

以电商下单为例，至少有几类不同职责：

• Handler：接收请求、参数绑定、鉴权、返回协议；
• Use Case / Application：编排下单流程，协调库存、计价、订单持久化；
• Domain：表达订单、库存、金额、不变量与业务规则；
• Infrastructure：数据库、缓存、MQ、RPC 客户端实现。

这些职责一旦混在一起，短期会觉得“写起来更快”，长期就会出现两个典型后果：

• 业务逻辑无法脱离接口或存储独立测试；
• 每次改动都必须理解整条链路的全部技术细节。

关于「这些职责在真实工程里如何落到目录结构上」，第 1 章给出了两套完整的 Go 目录映射（三层架构版与 DDD 版），第 2.6 节会基于配套示例仓库中的 examples/product-service 做完整走读。示例工程独立于本书仓库维护，本文只保留关键片段。

2.2.2 用例编排层要显式，不要隐式散落

业务系统最常见的腐化方式，不是类太多，而是“关键业务流程没有稳定的编排层”。于是下单的一部分逻辑藏在 Handler，另一部分藏在 Service，另一部分又埋在 Repository Hook 或异步消费者里。

更健康的做法是让“流程在哪里发生”这件事一眼可见：

type PlaceOrderUseCase struct {
	inventory InventoryService
	pricing   PricingService
	repo      OrderRepository
}

func (uc *PlaceOrderUseCase) Execute(ctx context.Context, cmd PlaceOrderCommand) (string, error) {
	if err := cmd.Validate(); err != nil {
		return "", err
	}

	quote, err := uc.pricing.Quote(ctx, cmd.UserID, cmd.Items)
	if err != nil {
		return "", fmt.Errorf("quote price: %w", err)
	}

	if err := uc.inventory.Reserve(ctx, cmd.Items); err != nil {
		return "", fmt.Errorf("reserve inventory: %w", err)
	}

	order := NewOrder(cmd.UserID, cmd.Items, quote.PayableAmount)
	if err := uc.repo.Save(ctx, order); err != nil {
		return "", fmt.Errorf("save order: %w", err)
	}

	return order.ID, nil
}

这段代码未必复杂，但它提供了两个重要价值：

• 流程顺序显式可读；
• 下层依赖是抽象接口，便于测试和替换。

但它仍然是教学用的最小骨架，不能被误读成完整的分布式事务方案。库存预留成功而订单保存失败时，必须有释放预留、进入待补偿状态或由后续任务重试的语义；重复请求时，Reserve 和 Save 也必须围绕同一个幂等键设计。第 4 章会系统讨论 Saga、Outbox 和补偿，这里只要求读者在 Review 时意识到这些边界不能被省略。

2.2.3 写“业务语言”，不要写“技术噪音”

很多代码难读，不是逻辑太深，而是表达层级不对。调用方真正关心的是“预留库存”“计算应付金额”“创建订单”，而不是一堆技术性细节。

反例通常长这样：

func CreateOrder(ctx context.Context, req *Request) error {
	if req == nil {
		return errors.New("nil")
	}
	// 混着校验、查库、拼对象、写缓存、打日志、改状态
	return nil
}

问题不在于函数短，而在于它没有向读者提供清晰语义。好的业务代码，读起来应该像在追踪一个真实业务动作，而不是在猜作者想做什么。

2.2.4 参数太多，通常说明抽象不对

参数列表过长，往往意味着以下几种问题之一：

• 缺少输入模型，调用方必须自己拼装上下文；
• 一个函数做了太多事，需要的上下文过多；
• 中间状态没有被显式建模，只能靠参数平铺传递。

例如下面这种签名几乎注定不可维护：

func CalcPrice(userID string, city string, channel string, skuID string, qty int, couponCode string, vipLevel int, usePoints bool) (int64, error) {
	return 0, nil
}

更合理的做法是让输入拥有清晰语义：

type PriceQuoteQuery struct {
	UserID     string
	City       string
	Channel    string
	Items      []QuoteItem
	CouponCode string
	VIPLevel   int
	UsePoints  bool
}

这样做不只是“好看”，更重要的是：

• 新字段扩展不会破坏大批调用方；
• 测试构造输入更自然；
• Review 时更容易判断字段语义是否合理。

2.3 重构不是推倒重来，而是持续纠偏

很多团队嘴上都知道“代码要可维护”，但一旦老逻辑开始变形，第一反应要么是继续堆条件，要么是豪情万丈地说“找时间重写”。前者会让代码越改越烂，后者通常永远没有时间真正发生。对业务系统来说，真正可执行的路径往往只有一条：在持续交付中小步纠偏。

重构的目标不是把代码变得“更漂亮”，而是降低未来每一次变更的摩擦成本，让系统重新回到可理解、可替换、可测试、可评审的状态。如果一段代码已经让团队不敢动、不愿改、每次修改都伴随高回归风险，那么它就已经不是局部实现问题，而是生产效率和系统演进能力的问题。

2.3.1 什么信号说明已经不能再继续堆逻辑

下面这些现象，通常意味着代码已经进入“继续堆功能比及时重构更危险”的阶段：

• 一个函数同时处理校验、编排、持久化、远程调用和异常恢复。
• 改一条业务规则要同时改多个层次，甚至多个服务。
• 同一类逻辑在不同分支里复制粘贴，只是改了几个字段名。
• 命名已经和真实业务语义对不上，只能靠口口相传理解。
• Reviewer 看到代码时会说“能跑，但我不敢保证后面还好改”。

这些信号的共同点是：代码已经不再帮助团队表达业务，而是在迫使团队绕着历史包袱工作。

2.3.2 重构的第一原则：先收口边界，再优化内部实现

很多失败的重构，不是因为方向不对，而是因为一上来就想把所有问题一起解决：顺手改命名、顺手换框架、顺手改协议、顺手统一抽象。结果系统还没变好，风险面先被扩大了。

更稳妥的路径通常是：

1. 先识别最关键的腐化点，到底是编排层缺失、依赖泄漏，还是领域规则散落。
2. 先把边界收口，让调用关系清楚，职责归属明确。
3. 再逐步替换内部实现，而不是先大面积重写细节。

换句话说，重构优先级往往不是“把代码写得更优雅”，而是“让未来的改动先有一个正确的落点”。

2.3.3 小步重构的常用路径

对线上系统来说，最有价值的不是理想化重构，而是能在真实交付节奏里落地的重构路径。下面几种方式最常见，也最实用：

这些动作看起来不“宏大”，但恰恰因为它们足够小，才更容易进入日常交付节奏，而不是永远停留在重构计划里。

Martin Fowler 将重构定义为保持外部行为不变、逐步调整内部结构的过程；重构的价值不在于一次性写出理想代码，而在于让每一步都足够小、足够可验证。[1]

2.3.4 安全重构的落地方案：适配、切换与流量验证

系统重构和架构重构有一个共同点：真正成熟的做法，往往不是停机重建，而是在线迁移。代码层面同样如此。很多时候，旧实现不能立刻删除，但可以先被包进一个更干净的抽象中，让新逻辑逐渐迁移到新边界。以下三种模式解决的是不同层次的问题，不能只因为都支持“渐进式迁移”就混为一谈：

按抽象分支适合先在代码库内部建立稳定的端口。调用方依赖接口，旧实现和新实现分别挂在接口后面，再通过配置或 Feature Flag 切换。它比长期维护一个大 Git 分支更容易持续合并，也能让新需求优先落到新边界。切换完成后必须删除旧适配器和临时开关，否则抽象层会从迁移工具变成永久复杂度。

绞杀者模式适合边界已经足够清晰、可以按接口或流量逐步迁移的场景。它的核心不是“把旧服务复制一遍”，而是让新实现逐渐接管一个可验证的业务切片。每次迁移都应记录流量比例、错误率、延迟、数据差异和回滚条件；涉及写入时，还要先明确谁拥有权威事实，避免新旧系统长期双写却没有对账机制。Martin Fowler 将它与一次性切换重写进行对比时，强调的正是风险分散，而不是迁移本身更“时髦”。[2]

并行双跑适合验证新旧实现的结果差异，但不等于让两条路径都执行真实副作用。计价、规则计算、搜索召回等相对容易做结果比较；库存扣减、余额变更、消息发送则必须使用只读查询、沙箱适配器或副作用抑制器。比较结果时不能只比较字符串，还要定义字段归一化、允许误差和差异处置，否则“有差异”无法转化为可行动的结论。

一个常见步骤是：

识别腐化模块
  -> 用特征测试锁住既有行为
  -> 定义新接口与失败语义
  -> 用适配层包装旧实现
  -> 新需求优先走新接口
  -> 小流量切换或并行比较
  -> 用指标、测试和 Review 验证
  -> 删除旧路径与临时开关

这种做法的意义在于，它允许团队在保持业务连续交付的同时，逐步让代码库重新变得可演进，而不是在“继续忍受”和“推倒重写”之间二选一。

2.4 编码时真正应该守住的几个原则

2.4.1 可读性优先于炫技

业务系统不是算法竞赛，维护周期远长于编写周期。多数情况下，未来读代码的人并不是当前作者本人，因此代码首先要对团队友好，而不是对作者本人高效。

可读性通常来自四件事：

• 命名和业务语义一致；
• 控制流简单，避免多层嵌套；
• 副作用位置明确；
• 错误路径可见，不靠隐式约定。

2.4.2 把变化点隔离，而不是把一切都抽象

很多团队一遇到重复就急着抽象，最后得到的是“看起来可复用、实际没人敢改”的公共代码。真正应该抽象的不是相似代码本身，而是稳定的概念和可预期的变化点。

例如：

• 不同库存来源的预留逻辑，可以抽象成同一接口下的不同实现；
• 不同业务线都要发消息，不一定需要一个万能 SendEverythingService；
• 只出现两次的小差异，不一定值得立即抽象成复杂模式。

好的抽象会减少决策面，坏的抽象会制造更多决策面。John Ousterhout 在《A Philosophy of Software Design》中用“深层模块”（Deep Module）解释了类似问题：好的模块用相对简单的接口隐藏较多实现复杂度；如果拆分后每个模块只有很薄的逻辑，却增加了大量接口、跳转和命名，系统的整体认知负荷反而会上升。[7]

这也说明 SOLID 不能被机械地理解成“类越小越好”或“接口越多越好”。单一职责应理解为“因同一类变化而共同修改”，依赖倒置应落到稳定的业务边界上，接口隔离则要避免把调用方强迫绑定到无关能力。原则的价值在于帮助团队识别变化方向，而不是替代具体的业务判断。

2.4.3 失败路径要和成功路径一样认真

线上事故很少发生在“主流程最理想的那条路”，而更常见于：

• 超时后是否重试；
• 重试后是否重复扣减；
• 部分成功后如何补偿；
• 下游失败时状态是否半提交；
• 幂等键是否真的覆盖重放场景。

所以编码时必须把错误处理当成一等公民。下面的例子比“调用成功就返回”更接近生产代码：

var ErrOrderAlreadyExists = errors.New("order already exists")

func (r *OrderRepository) Save(ctx context.Context, order *Order) error {
	_, err := r.db.ExecContext(
		ctx,
		`INSERT INTO orders (id, user_id, amount_cents) VALUES (?, ?, ?)`,
		order.ID,
		order.UserID,
		order.AmountCents,
	)
	if err != nil {
		if isDuplicateKey(err) {
			return ErrOrderAlreadyExists
		}
		return fmt.Errorf("insert order: %w", err)
	}
	return nil
}

这种写法的价值在于：

• 业务性冲突可被上层识别；
• 基础设施故障仍能保留错误链；
• Review 时容易判断幂等行为是否符合预期。

失败路径至少要回答五个问题：

1. 失败发生在哪个阶段，已经产生了哪些副作用？
2. 调用方收到的是明确失败，还是“结果未知，需要查询”？
3. 重试由谁发起，重试使用什么幂等键，最多重试几次？
4. 如果无法自动恢复，系统会进入哪个可观测、可人工接管的状态？
5. 这次失败是否需要补偿、对账或告警，而不是只记录一行错误日志？

例如，库存服务超时不一定等于“库存没有扣减”。如果请求已经到达下游但响应丢失，直接重试可能造成重复预留；如果订单服务把它简单映射成 500，用户再次点击又可能创建第二笔订单。更稳妥的代码会把“明确失败”和“结果未知”区分开，给每种状态规定查询、重试或人工处理路径。这里的重点不是为每个函数塞进复杂状态机，而是不要让异常语义隐藏在一个泛化的 error 中。

2.4.4 让测试点自然存在

代码未必必须先写测试，但一定要写成“能被测试”的形状。最糟糕的情况不是没有测试，而是代码结构让你根本无法只测业务逻辑，只能起整套环境做脆弱的集成验证。

更易测的代码通常具备这些特征：

• 输入和输出明确；
• 外部依赖通过接口注入；
• 核心逻辑不依赖全局状态；
• 纯计算与副作用分离。

可测试性不是测试工程师的额外要求，而是架构是否清晰的副产品。

2.4.5 小步提交，优于大爆炸提交

许多 Review 效率低，不是 Reviewer 不负责，而是提交本身已经不可评审。一个同时包含“重命名、重构、修 bug、加新功能、顺手格式化全目录”的 PR，几乎不可能被认真看完。

高质量提交通常有三个特征：

• 主题单一：一个 PR 只解决一类问题；
• 变更可解释：作者能说明改动前后行为差异；
• 回滚可控：出问题时能相对独立地撤回。

从工程协作角度看，小步提交本身就是对 Review 质量的投资。

2.4.6 将架构规则代码化：Fitness Functions 与 CI 门禁

仅靠工程师记忆和 Reviewer 的眼睛，无法长期守住大型代码库的边界。Neal Ford、Rebecca Parsons 和 Patrick Kua 在演进式架构方法中提出“架构适应度函数”（Architecture Fitness Functions）：把能够反复验证的架构特征写成自动化检查，让系统在持续变化中仍然受到约束。[3]

适应度函数不应停留在“代码质量要好”这种口号，而应写成可以失败的断言，例如：

• domain 包不能直接依赖 infrastructure；
• Handler 不能直接导入数据库驱动或执行 SQL；
• application 层只能依赖由自己定义的端口接口；
• 核心写操作必须具备幂等键或明确的重复请求策略；
• 关键状态迁移必须有行为测试；
• 新增外部调用必须声明超时、错误映射和观测字段。

其中，依赖方向和禁止导入适合用静态检查完成；幂等、补偿和状态迁移则通常需要测试夹具或集成测试，不能幻想用一个 Lint 规则解决所有架构问题。

在 CI 中可以分三档处理：

Go 项目可以组合 golangci-lint、staticcheck、errcheck、依赖图脚本和自定义测试；Java 项目可以用 ArchUnit 对包依赖和分层规则做断言。工具不是目的，关键是把团队反复争论的边界转化成可重复执行的证据。Uber Go Style Guide 也把错误处理、包命名、并发和 Lint 配置放在同一套工程约束中，而不是将“风格”局限为格式问题。[4]

2.5 Code Review 到底在审什么

2.5.1 Review 的目标不是挑错字

Code Review 的核心目标有四个：

• 在合并前发现正确性和稳定性问题；
• 检查实现是否偏离架构和设计约束；
• 传播团队编码标准和隐性知识；
• 通过讨论提升系统长期可维护性。

所以真正有价值的 Review，应该优先关注：

• 这段代码会不会做错；
• 这段代码以后会不会很难改；
• 这段代码是不是把风险藏起来了。

而格式、换行、 import 排序这些内容，应该尽量交给格式化工具和静态检查器，而不是浪费人工评审注意力。

2.5.2 Reviewer 的检查顺序

一份高质量 Review，最好按由大到小的顺序看，而不是一上来盯局部实现。

建议顺序如下：

1. 需求与行为：这次改动到底解决什么问题，是否改变了用户可见行为。
2. 边界与设计：代码是否放在正确层次，是否引入了不必要耦合。
3. 正确性：状态迁移、并发、异常、幂等、空值、边界条件是否安全。
4. 可维护性：命名、结构、复用方式、注释是否帮助未来修改。
5. 验证覆盖：测试、日志、指标、灰度与回滚手段是否足够。

这个顺序很重要，因为很多真正致命的问题，根本不是“某行写错”，而是整段代码从一开始就放错了位置。

2.5.3 Reviewer 最容易漏掉的风险

在业务系统里，下面几类问题尤其值得重点关注：

如果 Review 长期只盯代码风格，这些风险就会直接穿透到线上。

2.5.4 Author 应该怎样配合 Review

Review 质量不只是 Reviewer 的责任，Author 同样负有很大责任。作者在发起 PR 时，至少应该主动提供这些信息：

• 这次改动解决什么问题；
• 改动范围和非目标范围是什么；
• 有没有行为变化或数据兼容风险；
• 如何验证；
• 有没有需要 Reviewer 特别关注的点。

一个好的 PR 描述，能显著降低 Reviewer 的理解成本，也更容易把注意力放到真正重要的问题上。

2.5.5 一份可执行的 Code Review 清单

下面给出一份更适合业务系统的 Review Checklist。它不是要求每次逐条机械打勾，而是帮助团队形成稳定视角。

业务与正确性

• 这次实现是否真的满足需求，而不是只满足 happy path。
• 是否覆盖了空输入、重复请求、无权限、数据不存在等边界情况。
• 是否存在状态半提交、重复执行、顺序错误的问题。
• 失败后是否有明确返回、重试策略或补偿语义。

架构与边界

• 代码是否放在正确层次，是否出现跨层泄漏。
• 领域规则是否仍由领域对象或用例层表达，而不是散落在外层。
• 是否引入了新的隐式耦合，例如直接依赖具体实现、共享可变状态、万能工具类。
• 新抽象是否真有稳定价值，还是为了“看起来高级”。
• 目录结构与分层是否符合团队约定的映射（可对照第 1 章目录映射与 examples/product-service 样例）。

可读性与可维护性

• 命名是否表达业务语义，而不是技术细节。
• 函数是否过长、职责是否过多。
• 控制流是否过深，是否需要提前返回或拆分步骤。
• 注释是否解释“为什么”，而不是重复“代码在做什么”。

可靠性与可运维性

• 是否设置了合理的超时、重试、限流或幂等控制。
• 是否补充了必要的日志、指标、Tracing 标签。
• 故障发生时，能否快速定位模块、输入和阶段。
• 发布后是否具备灰度、监控和回滚抓手。

测试与验证

• 是否新增或调整了足够说明行为的测试。
• 测试是否覆盖关键分支，而不是只覆盖表面行数。
• 是否区分了单元测试、集成测试和端到端验证责任。
• 是否给出手工验证步骤或构造数据方式。

如果团队能长期围绕这五个维度讨论，Review 很快就会从“凭感觉”升级为“有共同标准”。

2.5.5.1 让 Review 意见具备可执行性

高质量意见应该描述风险，而不是表达个人偏好。一个有效的 Review 意见至少包含四部分：观察到的事实、可能造成的后果、建议的处理方向，以及是否必须在当前 PR 解决。例如：

[必须修复] 这里使用请求 ID 生成订单，但没有数据库唯一约束。
并发重试时可能创建两条订单，导致库存预留无法对应唯一订单。
建议把 idempotency_key 纳入订单唯一索引，并增加重复提交测试。

这种写法把讨论从“我不喜欢这个实现”转成“哪项业务不变量可能被破坏”。如果意见只是风格偏好，可以标记为非阻塞建议；如果涉及数据丢失、重复扣减、权限绕过或不可回滚发布，则应明确为阻塞问题。Google 的 Code Review 规范强调，Reviewer 既要保护代码库健康，也要避免用个人偏好制造不必要的交付阻力。[6]

Author 也可以主动把 PR 分成三类信息：必须理解的业务变化、可以机械验证的代码变化、希望 Reviewer 重点挑战的风险假设。这样 Reviewer 不必先猜测作者意图，再把时间花在真正需要经验判断的地方。

Review 结束后还应记录无法在当前 PR 解决的问题，例如“暂时保留旧适配器，下一阶段迁移”“先允许一处架构例外，月底前删除”。没有责任人和到期时间的 Review 结论，往往会变成无人追踪的技术债。

2.6 静态标杆：优秀代码应该长什么样

前面几节讲的是原则，这一节看实例。本书配套示例仓库的 examples/ 目录下有三个可编译运行的 Go 工程，它们不是玩具 Demo，而是刻意用来展示「代码结构如何承载架构意图」的对照样本。这里的聚合根、值对象、领域事件和应用服务，分别对应 Eric Evans 的领域驱动设计与 Vaughn Vernon 的实现方法；它们不是必须照搬的目录模板，而是帮助团队把业务规则放到正确位置的分析工具。[8][9]

示例代码已从书籍仓库移出，避免书稿构建项目和可运行工程相互耦合：

这三个工程不应被理解成“所有项目都必须长成同一个目录”。目录只是依赖方向和职责边界的可视化结果。小型模块可能只需要一个清晰的应用服务和一个存储适配器；只有当业务规则、入口类型或基础设施变化足够复杂时，才值得引入更完整的领域层和事件机制。好的标杆不是增加层数，而是让团队能够解释每一层为什么存在、由谁拥有、如何测试，以及什么时候可以被替换。

这一节从这三个工程里挑出五段代码，分别对应 2.2-2.4 的原则。读的时候建议对照源码完整看一遍——真实工程里的取舍细节（日志、注释、错误处理）比书上任何摘录都更有信息量。

2.6.1 目录结构本身就是第一份「好代码」

product-service 的顶层结构，几乎可以直接拿来当团队模板（完整树见本节后续的分层示例）：

product-service/
├── cmd/main.go                    # 入口：只做组装，不写业务
└── internal/
    ├── domain/                    # 领域层：聚合根、值对象、领域事件、Repository 接口
    ├── application/               # 应用层：用例编排、DTO
    ├── infrastructure/            # 基础设施：Repository 实现、缓存、Kafka
    └── interfaces/                # 接口层：HTTP、gRPC、Event 三种触发方式

这个结构好在哪里，用 2.2 的视角看非常清楚：

• 职责归属没有歧义。一个新需求来了，「这段代码该放哪」有明确答案，这是 2.2.1 的落地。
• 依赖方向物理可见。domain 不 import 任何其他 internal 包，interfaces 和 infrastructure 都依赖内层——Review 时一条 import 就能发现跨层泄漏。
• 三种入口（HTTP/gRPC/Event）平级，都只做协议转换后调用同一个 application service，不存在「Kafka 消费者里藏着一版业务逻辑」的隐式编排问题（2.2.2）。

相比之下，order-service 代表了大多数项目的现状：application/service 直接依赖 infrastructure/persistence 的具体实现，model.Order 是贫血对象。它的 README 自己也写明「这些正是后面引入 Clean Architecture、DDD 和 CQRS 的原因」。两个工程对照读，能直观看到 2.3 说的「腐化信号」长什么样、演进的终点长什么样。这里的“终点”不是永远不变的最终架构，而是当前约束下足够清晰、可替换和可测试的目标形态。

2.6.2 领域模型：业务规则内聚，而不是散落在 setter 之外

internal/domain/product.go 中的 Product 聚合根，是 2.2.3「写业务语言」的完整范例。看它的上架方法：

// OnShelf 上架
func (p *Product) OnShelf() error {
	if p.status == ProductStatusOnShelf {
		return errors.New("商品已上架")
	}
	if p.basePrice.Amount() <= 0 {
		return errors.New("商品价格必须大于0")
	}
	if len(p.images) == 0 {
		return errors.New("商品必须有至少一张图片")
	}

	p.status = ProductStatusOnShelf
	p.updatedAt = time.Now()

	p.addDomainEvent(ProductOnShelfEvent{
		SKUID:     p.skuID.Value(),
		OnShelfAt: p.updatedAt,
	})

	return nil
}

这段代码值得走读的四个点：

1. 不变量由聚合根自己保护。调用方不可能绕过「价格必须大于 0」这个规则——规则内聚在模型里，而不是靠每个调用方「记得检查」。这正是第 1 章「贫血 vs 充血」对比的完整版。
2. 状态迁移表达为业务动词。OnShelf()、OffShelf(reason)、UpdateBasePrice(price)，读代码就是在读业务流程，没有任何技术噪音。
3. 每次状态变更留下领域事件。事件在聚合内部积累，由应用层统一发布——「业务事实已经发生」这件事被显式建模，而不是散落在各处 kafka.Send()。
4. 字段私有 + 只读 Getter。外部无法直接把商品改成上架状态，只能走 OnShelf()，非法状态在类型层面就不存在。

2.6.3 值对象：让非法输入在构造时就失败

internal/domain/value_objects.go 里金额的处理方式，是业务系统最值得抄的一个习惯：

// Price 值对象（使用分为单位，避免浮点精度问题）
type Price struct {
	amount   int64  // 金额（分）
	currency string // 货币（CNY）
}

func NewPrice(amount int64, currency string) (Price, error) {
	if amount < 0 {
		return Price{}, errors.New("价格不能为负数")
	}
	if currency == "" {
		currency = "CNY"
	}
	return Price{amount: amount, currency: currency}, nil
}

两个设计决策都值得在 Review 中坚持：

• 金额用「分」存 int64，不用 float64。浮点精度问题在计价、退款分摊场景是真金白银的事故源（第 13 章营销与计价系统会再次遇到这个约束）。
• 校验收敛在构造函数。NewPrice 是唯一能造出 Price 的地方，负数价格在系统中根本不可能存在——这比在每个使用处写 if price < 0 高一个量级，也正是 2.4.2「把变化点隔离」的实例。

2.6.4 应用服务：编排显式、依赖抽象、失败语义清楚

internal/application/service/product_service.go 展示了一个符合 2.2.2 的用例编排层：

// EventPublisher is owned by the application layer.
// Infrastructure adapters such as KafkaProducer implement it.
type EventPublisher interface {
	Publish(ctx context.Context, event domain.DomainEvent) error
	PublishBatch(ctx context.Context, events []domain.DomainEvent) error
}

type ProductService struct {
	repo           domain.ProductRepository
	eventPublisher EventPublisher
}

func (s *ProductService) CreateProduct(ctx context.Context, req *dto.CreateProductRequest) (*dto.CreateProductResponse, error) {
	// Step 1: 创建领域对象（校验和不变量在领域层完成）
	product := domain.NewProduct(skuID, spu, req.SupplierSKU, price, specs)

	// Step 2: 保存聚合根
	if err := s.repo.Save(ctx, product); err != nil {
		return nil, fmt.Errorf("保存商品失败: %w", err)
	}

	// Step 3: 发布聚合中积累的领域事件
	if err := s.publishDomainEvents(ctx, product); err != nil {
		...
	}
}

对应 2.4.3 和 2.4.4，这段代码的三个好习惯：

• 接口在使用方定义。EventPublisher 接口声明在 application 层、由 infrastructure 的 KafkaProducer 实现——依赖方向向内，单元测试时可以注入内存假实现，不需要起 Kafka。
• 错误用 %w 包装并带业务语义。保存商品失败: %w 既保留了错误链可供日志追溯，又给上层提供了可判断的上下文。
• 流程步骤一眼可读。建领域对象 → 保存 → 发事件，顺序显式。编排层的职责是「编排」，不是「什么都干」。

这里还必须补充一个事务边界：如果 Save 只保存聚合，而 publishDomainEvents 直接调用 Kafka，那么数据库提交成功、消息发布失败时仍然会产生丢消息风险。生产实现应当在保存聚合的本地事务中同时写入 Outbox，再由 Worker 异步投递并更新发送状态。应用服务负责表达“保存事实并留下待发布事件”，基础设施负责可靠投递，不应把两者简化成一次普通函数调用。

2.6.5 测试：好结构让测试自然存在

2.4.4 说「可测试性是架构清晰的副产品」，这个工程给出了证据。product_center_service_test.go 不需要任何外部依赖就能验证核心业务行为：

func TestProductCenterPublishesSnapshotAndOutbox(t *testing.T) {
	repo := persistence.NewProductCenterRepository()   // 内存实现
	svc := NewProductCenterService(repo)

	result, err := svc.PublishCommand(ctx, domain.PublishProductVersionCommand{...})

	// 断言发布版本递增、快照内容正确、Outbox 事件已写入
	snapshot, _ := repo.GetSnapshot(ctx, result.ItemID, result.PublishVersion)
	events, _ := repo.ListOutbox(ctx, domain.OutboxPending)
	...
}

能写出这种测试，前提是前面所有的结构决策都做对了：依赖接口注入、核心逻辑不碰全局状态、Repository 有内存实现。反过来，2.7.1 节（下单反例）里那个把一切都揉在 Handler 里的写法，你想给它补一个「库存不足」的单元测试都无从下手——只能起数据库做脆弱的集成测试。测试写不出来，往往就是结构腐化最早的报警器。

2.6.6 把示例工程用起来

建议团队这样使用这些示例，而不是读完就忘：

• 新人 Onboarding：先跑通 examples/product-service（go run ./cmd），再回答「我要加一个新的商品字段，应该改哪几层」。
• Review 参照系：当 PR 里出现「这段逻辑该放哪层」的争论时，用示例工程的同类代码做参照，比抽象讨论快得多。
• 重构对照目标：迁移老代码时，把 examples/order-service（现状）和 examples/product-service（目标）摆在一起，演进路径就是 2.3.4 的安全重构模式。

2.7 动态演进：电商下单场景里的编码、重构与 Review

为了把原则落到具体场景，下面用一个简化的下单流程说明“代码怎么写”和“Review 怎么看”。

2.7.1 一个不健康的实现

func (h *OrderHandler) Create(c *gin.Context) {
	var req CreateOrderRequest
	if err := c.ShouldBindJSON(&req); err != nil {
		c.JSON(400, gin.H{"error": err.Error()})
		return
	}

	user, _ := h.userRepo.FindByID(c, req.UserID)
	if user == nil {
		c.JSON(400, gin.H{"error": "user not found"})
		return
	}

	total := int64(0)
	for _, item := range req.Items {
		sku, _ := h.skuRepo.Find(c, item.SKU)
		total += sku.Price * int64(item.Qty)
		_ = h.inventoryRepo.Decrease(c, item.SKU, item.Qty)
	}

	orderID := uuid.NewString()
	_ = h.db.ExecContext(c, "insert into orders(id,user_id,total_amount) values(?,?,?)", orderID, req.UserID, total)
	c.JSON(200, gin.H{"order_id": orderID})
}

这段代码的问题非常典型：

• Handler 同时承担协议层、编排层、领域校验和持久化职责；
• 错误基本被吞掉；
• 库存扣减和订单写入之间没有一致性语义；
• 没有超时、幂等、日志和观测点；
• 几乎无法只针对业务规则编写单元测试。

2.7.2 如果这是线上老代码，应该怎么重构

真实团队里更常见的情况不是“从零开始写一个更好的版本”，而是坏代码已经在线上跑了很久，周围还挂着依赖、监控、补偿脚本和历史调用。这个时候，最危险的做法往往不是不动，而是上来就想一口气彻底重写。

更现实的重构路径通常是：

1. 先记录旧接口的输入、输出、错误码、日志字段和关键副作用，形成一组特征测试。
2. 在不改变路由的前提下，把 Handler 中的流程编排提出来，形成单独的 Use Case。
3. 再把库存、计价、订单持久化等依赖抽成清晰接口，并用适配器包住旧实现。
4. 明确错误语义和幂等语义，让旧逻辑至少先变得可判断。
5. 补上关键路径测试和最小观测点，再用按抽象分支、灰度或双跑继续替换内部实现。

特征测试不一定一开始就漂亮。它的任务是记录系统当前对外表现，例如重复请求是否返回同一个订单号、库存不足时返回什么错误、计价超时时订单是否会落库。对一个没有测试的遗留模块来说，先把这些行为固定下来，通常比一开始就追求理想的单元测试更现实。Michael Feathers 将这种能够插入测试、替换依赖和打破耦合的位置称为“接缝”（Seam），它是遗留代码安全演进的重要入口。[5]

每一步重构都应有停止条件：测试结果没有扩大差异，关键指标没有恶化，旧路径仍然可以回滚，且新边界已经能够承接下一次需求。没有停止条件的重构，很容易从“降低风险”变成“借重构之名扩大变更范围”。

这一阶段的目标不是“一次性得到完美代码”，而是让这段链路重新进入可控状态：可以测、可以审、可以继续演进。

2.7.3 更合理的拆分

重构前后最重要的变化不是文件数量增加，而是依赖方向和副作用位置变得可见：

graph TD
    subgraph Before[重构前：Handler 承包一切]
        A[HTTP Request] --> B[OrderHandler]
        B --> C[(Database)]
        B --> D[Inventory RPC]
        B --> E[Pricing RPC]
    end

    subgraph After[重构后：边界与编排显式]
        F[HTTP Request] --> G[OrderHandler]
        G --> H[PlaceOrderUseCase]
        H --> I[Order Domain]
        H --> J[Inventory Port]
        H --> K[Pricing Port]
        J --> L[Inventory Adapter]
        K --> M[Pricing Adapter]
        H --> N[Order Repository]
    end

type OrderHandler struct {
	uc *PlaceOrderUseCase
}

func (h *OrderHandler) Create(c *gin.Context) {
	var req CreateOrderRequest
	if err := c.ShouldBindJSON(&req); err != nil {
		c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
		return
	}

	orderID, err := h.uc.Execute(c.Request.Context(), req.ToCommand())
	if err != nil {
		writeOrderError(c, err)
		return
	}

	c.JSON(http.StatusOK, gin.H{"order_id": orderID})
}

这时 Reviewer 能更容易聚焦真正重要的问题：

• Execute 是否定义了清晰的事务边界或补偿策略；
• ToCommand() 是否丢失关键字段；
• writeOrderError 是否正确映射业务错误与系统错误；
• 下层依赖是否具备幂等和超时语义。

好的结构不是为了“看起来分层”，而是为了让 Review 变得可行。

如果继续向下展开，Use Case 应该只保留流程和失败语义，领域对象负责保护不变量，Port 负责表达外部能力，Adapter 负责处理具体协议：

type PlaceOrderUseCase struct {
	inventory InventoryPort
	pricing   PricingPort
	orders    OrderRepository
}

func (uc *PlaceOrderUseCase) Execute(ctx context.Context, cmd PlaceOrderCommand) (string, error) {
	if err := cmd.Validate(); err != nil {
		return "", err
	}

	quote, err := uc.pricing.Quote(ctx, cmd.Items)
	if err != nil {
		return "", fmt.Errorf("quote order: %w", err)
	}

	reservation, err := uc.inventory.Reserve(ctx, cmd.IdempotencyKey, cmd.Items)
	if err != nil {
		return "", fmt.Errorf("reserve inventory: %w", err)
	}

	order, err := NewOrder(cmd.UserID, cmd.Items, quote.PayableAmount, reservation.ID)
	if err != nil {
		return "", fmt.Errorf("create order: %w", err)
	}
	if err := uc.orders.Save(ctx, order); err != nil {
		return "", fmt.Errorf("save order: %w", err)
	}
	return order.ID(), nil
}

这段代码仍然没有替代完整的 Saga 或本地事务设计，但它已经把几个必须讨论的问题显式化了：请求有幂等键，库存预留有业务编号，订单构造会校验不变量，外部依赖通过端口进入。若保存订单失败，系统还需要调用释放预留、进入补偿队列，或者由订单状态机记录“待确认”状态。真正的设计结论应由业务事实和失败恢复要求决定，而不是由代码层次名称决定。

经过上述拆分，下单链路已经与第 2.6 节 examples/product-service 所展示的应用层、领域层和基础设施边界保持一致。第 2.6 节回答“目标形态是什么”，本节回答“团队如何从现状安全地走到目标形态”。

2.7.4 Reviewer 在这个场景里应该怎么提问

看到类似下单链路时，Reviewer 至少应该追问这些问题：

• 如果前端重复提交，请求是否会创建重复订单。
• 如果库存扣减成功、订单写库失败，后续怎么恢复。
• 如果计价服务超时，是否会重试，重试是否安全。
• 是否需要在日志或指标里区分哪一个阶段失败。
• 是否有测试覆盖“库存不足”“重复请求”“下游超时”这些关键场景。

这些问题的价值远高于“变量名是不是更短一点”。

2.7.5 重构完成的判断与复盘

重构完成不等于“所有旧代码都已经删除”，而是新边界已经成为默认落点，旧路径已经不再承接新增业务，并且团队拥有删除它的条件。可以用下面的结果判断是否达到阶段目标：

• 外部行为和关键业务不变量由特征测试或契约测试覆盖；
• 新实现的错误、超时、重试和幂等语义能够在代码中被定位；
• 新旧路径的延迟、错误率、数据差异和资源成本可以比较；
• 灰度失败时能够回到旧实现，且回滚不会制造重复副作用；
• 临时适配器、Feature Flag 和架构例外都有明确删除人和到期时间。

上线后还要复盘“哪些假设被验证、哪些假设被推翻”。如果新实现只是把复杂度从 Handler 移到了一个巨大的 Use Case，说明这次重构只改变了目录，没有改变职责；如果测试数量增加但关键失败路径仍然没有保护，说明覆盖率没有转化为安全性。重构的产出应当是更低的下一次变更成本，而不是一次漂亮的代码截图。

2.8 常见误区与团队实践建议

2.8.1 误区一：把 Review 当审批，不当协作

有些团队把 Review 理解成“有人点了 Approve 就行”，于是流程是有了，质量却没有提升。真正有效的 Review 应该是共同发现风险、澄清设计和统一标准，而不是机械签字。

2.8.2 误区二：用 Review 替代设计

如果一个 PR 到了 Review 阶段才第一次暴露“模块边界错了”“方案方向不对”，说明前面的设计沟通已经缺位。Review 可以发现架构偏移，但不应该承担完整设计工作的全部责任。

更稳妥的做法是：

• 大改动先有 TD 或 RFC；
• 中等改动先在 Issue、文档或评论里对齐边界；
• PR Review 重点核对“实现是否符合设计”，而不是从零开始发明设计。

2.8.3 误区三：提交太大，导致没人真看

如果团队长期接受超大 PR，最终结果通常是：

• Reviewer 只看自己熟悉的几处；
• 边界性问题被“以后再说”跳过；
• 真正复杂的改动在匆忙中直接进入主干。

团队应该把“小步可审查”当成明确要求，而不是个人习惯。

2.8.4 误区四：把风格争议交给人肉争论

缩进、换行、 import 排序、基础 lint 规则，尽量交给自动化工具。人工注意力很贵，应该用来识别架构偏移、错误语义和未来维护成本，而不是反复争论空格。

2.8.5 建议建立团队级样例、重构预算与评审文化

单靠口头要求，很难稳定提升团队编码、重构和 Review 水平。更有效的做法通常包括：

• 为核心链路维护“代表团队标准”的样例实现（配套示例仓库中的三个 Go 工程就是这种样例的最小形态，见第 2.6 节）；
• 为高风险场景维护 Review Checklist；
• 为历史包袱最重的模块预留明确的重构预算，而不是永远让它排在需求之后；
• 在复盘中把真实事故沉淀成新的评审规则；
• 鼓励 Reviewer 提出基于风险的意见，而不是只给抽象评价。

最好的 Review 文化，不是“大家都很严格”，而是“大家知道为什么严格、严格在什么地方”。

2.8.6 推荐的自动化守护工具与规范

人肉 Checklist 适合建立共同语言，但不适合承担所有重复检查。团队可以把工具和人工 Review 按照“机器查确定性问题，人查语义和取舍”的原则分工：

Google 的 Code Review 指南把“持续提升代码库整体健康度”作为评审标准，同时也提醒团队不能为了追求局部完美而阻止所有交付。[6] 这意味着 CI 门禁需要有边界：编译失败、禁止依赖和核心测试失败可以直接阻止合并；复杂度趋势、技术债例外和非关键覆盖率则更适合作为可见的治理指标。

PR 模板也不应只要求 Author 勾选“已测试”。对涉及核心链路的改动，至少应要求作者回答：

- 这次改动保护了哪些业务不变量？
- 是否改变了接口、数据格式或状态迁移？
- 重试、重复请求和部分失败如何处理？
- 如何验证日志、指标和 Trace 能定位故障？
- 灰度、回滚和遗留路径删除条件是什么？
- 如果使用 AI 辅助，哪些代码由工具生成，哪些行为由测试或人工验证？

最后一项不是为了追踪工具使用，而是要求 Author 对验证证据负责。AI 可以帮助生成代码，却不能替 Author 对业务行为签字。

2.8.7 团队如何把 AI 纳入工程流程

团队不必把 AI 编程单独变成一套神秘流程，可以把它纳入既有的软件交付环：

1. 先给边界，再让工具生成：在 Prompt、仓库规则或任务描述中写清楚允许修改的包、禁止依赖、错误语义和测试要求。
2. 先生成局部变化，再扩大范围：优先让工具处理一个函数、一个适配器或一组测试，不要让它在没有行为基线的情况下重写整个模块。
3. 先验证行为，再接受重构：运行特征测试、单元测试、Lint 和依赖检查，确认工具没有改变状态迁移和失败语义。
4. 让人审查不可自动化的部分：Reviewer 重点挑战业务不变量、并发安全、兼容性、观测、灰度和回滚，而不是重复检查格式。
5. 把有效约束沉淀回仓库：如果 AI 反复生成相同的错误结构，就把问题转化成模板、示例、静态规则或测试，而不是每次重新提醒。

这里的关键不是限制工具，而是限制未经验证的变化范围。AI 越擅长生成大批代码，团队越应该要求每次提交都能说明“改变了什么、没有改变什么、如何证明”。

2.8.8 用预算和指标保护重构时间

重构预算不能只写成“有空再做”。团队可以为高风险模块设置季度预算，并把预算和可观察指标联系起来：一次需求从开始到合并需要多少时间，Reviewer 需要多少轮才能理解，关键模块的缺陷逃逸率如何变化，架构例外是否按期删除，发布后回滚和人工补偿是否减少。指标的作用是帮助团队判断“是否值得继续投入”，而不是把工程师变成追逐数字的人。

同样，测试覆盖率不能独立证明代码安全。一个没有覆盖异常分支的整洁测试套件，可能比覆盖率较低但覆盖关键业务不变量的测试更危险；一个 PR 平均很小，也不代表它没有把数据迁移、接口兼容和回滚问题藏在脚本之外。因此，指标必须和案例、故障复盘及 Review 证据一起解释。

当模块的变更耗时、线上风险和认知负担持续上升时，团队应把它视为架构信号，重新评估边界和所有权，而不是要求个人“写得更仔细”。这会把重构从临时的个人偏好，转化为可以被管理、被复盘和被持续改进的工程能力。

2.9 本章小结

编码、重构与 Code Review 不是架构之后的附属环节，而是架构能否真正落地的主战场。一个团队如果只会写设计文档，却不能持续写出边界清晰、错误可控、便于重构和审查的代码，系统质量最终仍会滑向混乱。

你可以把本章压缩成四句行动原则：

• 编码时先守边界，再谈技巧。
• 重构时先收口边界，再替换内部实现。
• Review 时先看正确性与设计，再看局部实现。
• 让提交可审查，让风险可讨论，让结论可复用。
• 把可重复的架构判断交给自动化，把不可替代的业务取舍留给团队。

从下一章开始，我们会进一步进入生产级系统保障，讨论当代码进入真实流量、真实故障和真实资金风险环境后，还需要哪些可靠性、恢复与防资损能力。

把这些原则放回日常工作，可以形成一条足够小的行动路径。接到新需求时，先写出业务事实、变化边界和失败后的状态，再决定代码放在哪个层次；发现旧代码难以修改时，先补一条能够描述现状的测试或观测，再寻找接缝，而不是直接打开一个长期存在的重写分支；准备提交时，主动拆出机械重命名、结构调整和行为变化，让每个 PR 都能被完整理解；进入 Review 时，先检查正确性、边界和恢复能力，再讨论命名与风格；当同一条意见反复出现时，把它升级为模板、测试、Lint 或 CI 规则。

这条路径的最终目标不是制造更多流程，而是降低团队对个人记忆和英雄式谨慎的依赖。代码边界清楚，重构就能小步发生；测试和观测充分，Review 才能围绕风险讨论；架构规则可以自动检查，人工注意力才能留给业务判断；团队还要通过复盘把一次事故或一次成功迁移沉淀成下一次可以复用的证据。AI 工具会继续提高代码生成速度，但真正决定系统能否演进的，仍然是团队能否把约束、证据和责任放进工程机制。

否则每次新需求都要重新依赖少数熟悉系统的人，组织规模越大，质量越难稳定。

工程机制的价值，就是让正确做法更容易发生，让错误做法更早暴露。

2.10 延伸阅读与经典方法论索引

代码质量与演进能力不是一组可以一次性背完的规则，而是软件工程长期积累的判断框架。本章只提取与当前论点直接相关的部分，读者可以按问题继续深入。书籍中的原则存在差异，尤其是“方法应该多长”“应该先拆分还是先集中复杂度”等问题，不宜脱离上下文机械执行；阅读时应比较它们各自解决的复杂度来源，再回到业务边界和变更成本做选择。

2.10.1 设计、抽象与领域模型

2.10.2 重构、遗留系统与演进式架构

2.10.3 Code Review、Go 工程与在线指南

2.10.4 本章方法论的使用顺序

遇到一段难以修改的代码时，可以按下面的顺序阅读和行动：

1. 先用 Ousterhout、Evans 和 Vernon 的观点判断边界、职责和业务模型是否清楚。
2. 再用 Fowler 和 Feathers 的方法寻找坏味道、接缝和可插入测试的位置。
3. 如果改动跨越模块或服务，使用 Branch by Abstraction、Strangler Fig 或 Shadow Run 设计迁移路径。
4. 用 Google Code Review Guide 和本章 Checklist 组织人类评审。
5. 用 Fitness Functions、Lint、依赖检查和测试把已经达成的共识固定下来。

这套顺序的目的不是增加流程，而是避免把所有问题都推给最后一次 PR Review：设计问题应尽量在设计阶段暴露，结构问题应在重构阶段收口，确定性的规则应由 CI 执行，剩下的业务取舍才值得消耗专家的人工注意力。

2.10.5 参考资料

[1] Martin Fowler, Refactoring, 2nd ed., Addison-Wesley, 2018, https://www.martinfowler.com/books/refactoring.html。

[2] Martin Fowler, “Strangler Fig Application”, https://martinfowler.com/bliki/StranglerFigApplication.html。

[3] Neal Ford, Rebecca Parsons, Patrick Kua, Building Evolutionary Architectures, O’Reilly Media, 2017, https://www.oreilly.com/library/view/building-evolutionary-architectures/9781491986356/。

[4] Uber, “Uber Go Style Guide”, https://github.com/uber-go/guide/blob/master/style.md。

[5] Michael Feathers, Working Effectively with Legacy Code, Prentice Hall, 2004, https://www.pearson.com/en-us/subject-catalog/p/working-effectively-with-legacy-code/P200000000297。

[6] Google, “The Standard of Code Review”, https://google.github.io/eng-practices/review/reviewer/standard.html。

[7] John Ousterhout, A Philosophy of Software Design, 2nd ed., Yaknyam Press, 2021, https://web.stanford.edu/~ouster/cgi-bin/book.php。

[8] Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003, https://www.domainlanguage.com/ddd/。

[9] Vaughn Vernon, Implementing Domain-Driven Design, Addison-Wesley, 2013, https://www.pearson.com/en-us/subject-catalog/p/implementing-domain-driven-design/P200000009616。

第 3 章 生产系统治理、保障与技术债务：韧性架构的动态平衡

生产系统不会因为上线成功就自动可靠。需求、流量、依赖、数据和组织都会变化，系统若没有持续的约束与反馈，就会逐渐变得难以解释、难以变更、难以恢复。本章把生产可靠性定义为四个结果：关键业务可完成、结果正确、失败可恢复、过程可审计。

本章不讨论“永不出错”的理想系统，也不把某个中间件当作可靠性方案。可靠性是一个控制回路：先定义业务结果和可接受的风险，再用保护机制限制故障，用遥测发现偏差，用对账和补偿收敛状态，最后把事故经验固化为治理规则。Google SRE 将 SLO 与错误预算用于平衡可靠性和变更速度，正是这种控制回路的经典表达。[1]

3.1 引言与全景框架

3.1.1 问题边界与共同模型

本章覆盖面向用户的在线服务、异步任务和带有支付、库存、优惠、供应商等外部依赖的交易系统。它关注的是生产中的失效和恢复，不展开容量规划、业务领域建模或安全纵深防御；这些主题只在与本章的故障边界相交处出现。

可靠性至少有四层：

生产治理可以抽象为以下反馈环：

业务目标与风险
      │ 定义 SLI/SLO、错误预算、数据不变量
      ▼
设计约束 ──► 保护机制 ──► 运行遥测 ──► 应急止血
   ▲             │             │            │
   │             └──────► 失败记录、对账、补偿 ◄────┘
   │                                      │
   └──────────── 复盘、还债、规则固化 ◄────┘

技术债务会提高故障概率和恢复成本；保障机制可以降低爆炸半径，却可能掩盖债务；治理要把事故、演练和数据转化为长期约束。因此，判断一项工作时应同时问：它减少了哪种风险？它增加了什么复杂度？失败后谁负责收敛？

设计时可以先画一张“约束画布”，把抽象的稳定性目标翻译成可评审的工程问题：

容量数字如果只是方案假设，就必须标明“假设”；上线后要用实际 QPS、P99、队列长度和失败率替换它。稳定性不是把每个指标都做到最大，而是在业务约束下给资源、延迟和恢复能力分配预算。这样才能解释为什么结算链路获得独立连接池、为什么通知链路可以被降级，也能解释为什么一个看似无害的批处理会被暂停。

3.1.2 90 天治理路线图

数字是规划示例，不是通用标准。真正的目标应由业务损失、用户旅程和团队能力校准。

DORA 的交付频率、变更前置时间、变更失败率和恢复时间适合观察交付系统的速度与稳定性，但它们是组织级反馈指标，不能直接替代某个业务 SLO。[2]

3.2 技术债务治理：管理摩擦而不是追求零负债

3.2.1 债务分类与利息

技术债务不是所有“不漂亮的代码”，而是为了当前收益接受了未来摩擦的设计或实现选择。Fowler 用“有意/无意 × 明智/鲁莽”描述债务的性质；该模型的价值不在贴标签，而在于帮助团队讨论偿还成本、收益和时机。[3] Kruchten、Nord 和 Ozkaya 则强调要识别债务项、评估影响、决定消除/降低/缓解，并把管理动作纳入发布计划。[4]

债务的“本金”是重构或迁移工作量，“利息”是每次变更增加的耗时、事故概率、值班负担和恢复损失。优先级不应由代码观感决定，而应由下面的近似模型决定：

债务优先级 ≈ 影响范围 × 发生概率 × 利息增长率 × 恢复成本
             ÷ 处理成本

模型只用于排序，不是精确财务计算。一个可操作的债务登记项至少包含：影响旅程、触发条件、当前绕行、owner、利息信号、偿还方案、停止新增债务的门槛和复核日期。没有 owner 和日期的“技术债列表”只是愿望清单。

债务登记还要记录“暂不偿还”的理由。可以暂缓的债务通常满足三个条件：影响范围小、利息没有明显增长、存在可验证的运行护栏；一旦其中一个条件失效，就必须重新评审。例如，一个只读报表仍使用旧查询层，若访问量稳定且有查询超时，可以暂缓；如果它开始被在线结算复用，边界已经变化，就不能继续用原来的绿灯结论。

偿还方式也不只有重写。常见选择包括：

每个债务项应有一个可观察的“利息指标”，比如构建耗时、变更回滚率、人工补偿量、慢查询比例、告警噪声或新成员上手时间。指标下降不等于债务消失，但能证明偿还动作确实改善了系统，而不是只改变了代码形状。

3.2.2 债务准入与偿还 ADR

允许借债，但必须让它可见、可限额、可回收。准入表可以把“现在能否上线”从口头争论变成证据判断：

关键重构应写成 ADR，而不是只写“推荐方案”。例如把供应商同步从“业务库直接改写搜索表”迁移为“权威库 + Outbox/CDC + 可重放投影”：

线上重构优先采用可逆步骤：先建立抽象边界和双读比对，再影子写入或灰度投影；差异可解释后切流，保留回滚窗口，最后删除旧路径。直接停机重写通常把技术风险变成业务不可用风险。

3.3 韧性架构与保护机制

3.3.1 SLI、SLO 与错误预算

SLI 是观测，SLO 是内部目标，SLA 是对外契约。SLO 应围绕用户旅程定义，并同时覆盖速度、正确性、新鲜度和完整性；不要用组件健康替代业务结果。[1]

错误预算是 1 - SLO，但必须先定义排除项、统计窗口和错误分类。预算充足时可以发布和实验；消耗过快时收紧灰度、优先修复高利息债务；预算耗尽时暂停高风险变更，只允许修复和安全变更。[1]

错误预算要落到决策而不是仪表盘。团队可以把预算状态分为绿、黄、红三档，并为每档预先约定动作：

燃烧率应同时看短窗口和长窗口。短窗口能在突发事故中快速触发止血，长窗口能识别低强度但持续的退化；只看平均值会把尖峰和局部租户的损失稀释掉。SLO 的统计口径也要写清楚：是按请求数、用户旅程、金额、订单还是时间计算；超时、客户端取消、依赖不可用和已知维护是否分别计入；一条请求跨多个服务时，不能把各服务的百分比简单相加。

错误预算不是让团队故意消耗故障额度。它把可靠性投资和交付节奏放在同一张决策表中：预算足够不代表可以跳过幂等和回滚，预算不足也不代表只能停工。若业务正确性受到威胁，即使可用性预算尚未耗尽，也应立即冻结相关动作；若某个 SLO 长期稳定且成本过高，则可以通过 ADR 重新评估目标、采集方式和投入，但要保留历史基线，避免用改变口径制造“改善”。

3.3.2 故障模型与隔离边界

先定义系统会怎样坏，再决定保护措施。常见故障与第一防线如下：

故障域不能只按服务名划分，还要按流量、资源、地域和数据分片划分。一个推荐接口变慢，如果和订单接口共享线程池、连接池及缓存实例，推荐故障就会变成交易故障；一个热点商品如果和普通商品共享库存锁，也会把局部竞争扩大成全局排队。故障域的目标不是让每个模块都独立，而是让影响边界可以预测、监控和切断。

依赖也要分级，否则所有错误都会被当成“服务不可用”：

例如结算时库存预占和价格快照是强依赖，推荐凑单和营销标签是弱依赖，积分发放和通知是后置依赖，埋点上传是观测依赖。依赖分级必须写入接口契约和 runbook，不能只存在于熟悉系统的工程师脑中。

高可用也不等于“多部署几个实例”。应用层需要无状态和快速替换，数据层需要复制、备份与恢复演练，消息层需要副本、积压水位和重平衡预案；每一种冗余都必须配合切换动作。没有演练过的备用链路，只能称为潜在容量，不能称为已验证的恢复能力。

3.3.3 韧性保护机制矩阵

Nygard 将稳定性模式集中在超时、熔断、舱壁、降级和可恢复变更等防御边界；AWS Reliability Pillar 也强调超时、限流、有限重试、快速失败和紧急开关。[5][6] 机制必须组合使用，单独增加重试往往只会放大故障。

重试必须有全链路预算。Full Jitter 的一个最小实现如下；attempt、最大次数和总 deadline 需要由调用链共同决定，而不是每个 SDK 各自决定：

import random

def backoff_seconds(attempt, base=0.1, cap=3.0):
    limit = min(cap, base * (2 ** attempt))
    return random.uniform(0, limit)

AWS 对退避、抖动和最大重试次数的说明指出：仅有指数退避仍可能让大量客户端同时重试，因此要加入随机抖动并设置上限。[7] 对非幂等写操作，正确策略通常是返回可查询的处理中状态，由状态查询、Outbox 或人工队列收敛，而不是再次盲写。

超时必须按端到端预算分配。假设结算初始化总预算为 2 秒，不能让每个下游都使用 2 秒：商品校验可以占 150 毫秒，库存预检查 300 毫秒，计价 500 毫秒，营销试算 300 毫秒，地址运费 300 毫秒，聚合与序列化保留 200 毫秒。预算只是示例，实际值要由 P99、依赖等级和用户体验测量得到；入口 deadline 应向下游传递，子调用只能消耗剩余预算。

超时之后的语义也要区分：读请求可以返回旧快照，弱依赖可以异步补齐，强依赖写请求必须进入可查询的处理中状态。尤其要警惕“客户端超时但服务端已经提交”的不确定结果，此时直接重试可能重复扣款或重复创建订单，正确动作是查询业务状态、等待回调或进入对账。

幂等不是一个缓存键，而是一组持久化约束：

中间件参数也属于保护机制。MySQL 连接池的 MaxOpenConns、ConnMaxLifetime、建连/读/写超时要和服务端 max_connections、空闲连接回收时间协调；Redis 的活跃连接上限、获取连接等待时间、读写超时和重试次数要与 maxclients、慢命令和热点键共同评估。评审至少检查三组关系：应用连接池总量小于服务端上限并留有恢复余量；应用连接生命周期不长于代理和服务端的断连时间；获取连接、建连、读、写各阶段都有上限。

参数优化不能只盯吞吐。把连接池放大、重试次数提高、队列上限调高，短期可能让成功率变好，长期却可能把压力转移到数据库、消息代理或外部供应商。每个参数变更都要记录目标、影响边界、回滚方式和验证指标。

3.3.4 变更与演练

一次发布就是一次故障注入机会。生产准入至少检查：依赖是否有超时、核心写是否幂等、配置是否可审计、数据库变更是否向后兼容、灰度是否能自动停止、回滚是否不会覆盖新数据。混沌演练不追求制造戏剧性事故，而是验证“发现—止血—恢复—复盘”链路和 owner 是否真实存在。

变更风险应按影响范围而不是按代码行数分级。只改文案的变更可能是低风险，只改一行限流配置也可能让全站不可用。评审可以使用以下护栏：

每次发布至少保留四条证据：变更前基线、变更时间线、灰度期间的业务对账结果、变更后的验证结论。回滚也不是无条件安全的：如果新版本已经写入新格式数据，直接回滚旧代码可能无法读取；如果新版本已经发送新事件，回滚消费者可能重复或丢弃事件。因此数据库迁移和事件协议要优先采用向后兼容，无法兼容时设计一次性的前向修复。

混沌实验可以从低危、可恢复的故障开始。实验单应写明假设、爆炸半径、注入方式、停止开关、预期信号、恢复动作和验收证据。例如“支付查询延迟升高时，订单服务应在总预算耗尽后进入处理中，不得重复发起扣款；五分钟内限流开关生效，恢复后差异项全部进入对账状态机”。实验失败不等于系统失败，真正失败的是无法观测、无法停止或没有 owner。阿里云的混沌工程实践同样把故障注入与稳定性验证、应急预案和持续改进结合起来。[19]

3.4 可观测性与 1-5-10 应急响应

3.4.1 从图表到可回答的问题

可观测性不是把所有日志搬进平台，而是能从输出推断内部状态，并回答“谁受影响、哪条路径变慢、是否发生错误副作用、恢复是否收敛”。OpenTelemetry 将 traces、metrics、logs 和上下文传播定义为可组合的遥测信号；Dapper 论文则说明了分布式追踪在跨服务定位因果链上的价值。[8][9]

基础监控可用 RED 和 USE 组织，但交易系统必须再加业务正确性：

高基数维度要有边界。trace_id 适合放在日志和 Trace，不适合直接作为长期指标标签；租户、商品、错误码、版本等维度应按查询需要分层采样、聚合或保留短期明细。统一字段至少包括 request_id、trace_id、业务单号、版本、水位、错误分类和脱敏后的操作者；禁止把支付凭证、密钥或完整个人信息写入日志。

观测体系应按“入口—服务—资源—数据—事件”分层，而不是按工具分组。入口层回答用户旅程是否成功；服务层回答哪一个接口、版本或依赖变慢；资源层回答线程、连接、队列和磁盘是否饱和；数据层回答状态、金额、库存和水位是否收敛；事件层把发布、配置、扩容、熔断、补偿和人工操作串到同一条时间线上。这样发生事故时，值班人可以从业务影响下钻到技术原因，再反向验证恢复结果。

指标命名和标签必须服务于查询。稳定维度如服务名、接口、区域、状态码和版本可以长期保留；订单号、用户号和追踪号应进入日志或短期明细索引。对高基数数据至少设置三道控制：采集端采样，存储端保留期限，查询端限制扫描范围。采样不能覆盖所有信号：错误、慢请求、状态迁移拒绝和资损差异应保留更多样本，成功请求则可以按比例采样。OpenTelemetry 的信号模型强调上下文传播和统一语义，这使得日志、指标与 Trace 能够围绕同一请求关联，但采集标准本身并不替团队决定保留多久、哪些字段可以公开。[14][20]

告警应满足四个条件：有明确影响、有责任人、有动作、有去重。CPU 高并不一定是事故，创单成功率下降、支付差异增长或队列预计超过数据新鲜度预算才是更接近用户结果的信号。每条告警都要注明当前值、基线、窗口、影响对象和建议动作；重复告警合并成事件，恢复通知必须带上验证结果。对长期无动作的告警要降级、改造或删除，告警数量本身不能作为可观测性成熟度指标。

容量与恢复验证也属于可观测性。容量估算至少区分稳定流量、峰值流量和故障转移后的流量，并把请求数、请求体大小、下游放大倍数、并发连接和数据增长一起计算。压测不能只看吞吐，还要观察 P99、错误分类、队列积压、锁等待、GC、连接池和恢复速度；压测数据必须标注是实验结果还是容量假设。备份则要按 RPO 和 RTO 设计：有备份不代表能恢复，必须定期恢复到隔离环境，校验表数量、关键账本、索引、权限和应用可读性。恢复演练中还要验证 DNS、密钥、配置、消息位点和外部依赖，避免只恢复数据库却无法启动完整业务。

3.4.2 1-5-10 应急时钟

“1-5-10”是团队约定的响应节奏，不是行业标准：1 分钟确认信号，5 分钟完成止血，10 分钟建立可协作的恢复计划。它的目的不是要求十分钟修复所有事故，而是防止团队在争论根因时继续扩大损失。

燃烧率告警要同时配置短窗口和长窗口：短窗口用于快速止血，长窗口用于发现慢性退化。告警输出必须能直接连接到动作，例如“创单 SLO 燃烧、库存补偿 backlog 增长、最近版本为 X、建议暂停发布”，而不是只发送一个红色仪表盘。

3.5 数据一致性、对账与资损防控

3.5.1 权威事实与异步传播

跨服务系统不应追求所有表同时更新，而应先回答：谁拥有业务不变量，哪条记录是权威事实，哪些是可重建投影，多久的延迟可接受。DDIA 将可靠性、可扩展性、可维护性以及数据系统的权衡放在同一框架中；中文《凤凰架构》也把分布式事务的核心问题归结为跨边界状态如何达成可接受的一致性与可恢复性。本章据此采用“权威事实 + 可重放派生状态 + 对账收敛”的模型。[10][16]

当一次本地事务既更新业务实体又发布事件时，Transactional Outbox 将事件写入同一数据库事务，再由 Relay 投递；它避免了数据库提交和消息发送之间的双写窗口，但 Relay 仍可能重复发布，因此消费者必须幂等。[11][17]

命令
  │ 本地事务：业务表 + outbox_event
  ▼
权威库 ──► Outbox/CDC ──► Broker ──► 幂等消费者 ──► 读模型/补偿队列
  │             │              │              │
  └─────────────┴──────────────┴──────► 对账与水位

Outbox 至少记录 event_id、聚合 ID、聚合版本、事件类型、payload 引用、创建时间、投递状态和最近错误。大 payload 放对象存储并保存哈希，不要把不可查询的大对象塞进主表。消费者用 event_id 或业务幂等键建立唯一约束，同时校验版本，拒绝旧事件覆盖新状态。

3.5.2 三层对账与统一状态机

对账不是简单地比较两张表，而是按时间、粒度和权威口径分层：

差异项统一进入状态机，而不是由不同业务各写一套脚本：

DETECTED → CLASSIFIED → RETRYING → VERIFIED
    │           │            │          │
    │           │            └─失败────┘
    │           └─需人工──► MANUAL_REVIEW → COMPENSATED
    └──────────────────────────────► IGNORED（必须有理由）

不变量是：任何差异都有来源引用、分类、影响范围、owner、下一动作和审计记录；COMPENSATED 必须有验证证据，IGNORED 必须有业务豁免和过期时间。补偿任务要保存 attempt、next_run_at、错误分类、payload 引用和 idempotency_key。超过次数不代表成功或失败，而是转入人工复核。

DLQ 不是垃圾桶。可以进入 DLQ 的是暂时无法自动处理、但仍有明确业务语义和原始凭证的记录；格式损坏、敏感信息泄露或无法识别权威对象的记录应进入隔离区。重新投递必须支持按租户、批次、错误类型和时间范围选择，设置速率上限，禁止无限自动重放。

对账表本身也要设计成可运营的数据产品。差异记录至少包含权威来源、对端来源、比较批次、业务主键、双方状态、金额或数量、首次发现时间、最近重试时间、错误分类、影响等级和处理人。比较逻辑要区分“未到水位”“暂时不可见”“确定缺失”“重复副作用”“金额不一致”和“已人工豁免”，否则不同性质的问题会被混成一个数量。水位要有明确语义，例如事件时间、提交时间、消费位点或外部账单日切时间，不能把查询时刻随意当成业务截止时间。

自动补偿必须遵循小步、可停、可验证。先根据幂等键查询当前事实，再执行最小必要动作，动作完成后重新读取权威状态，最后将证据写回差异项。重试按错误分类处理：网络超时可以延迟重试，版本冲突需要重新读取，金额不一致只能冻结并人工审批，权限或数据格式错误应立即隔离。补偿 worker 要限制并发、租户和总金额，设置熔断与暂停开关；当补偿量突然超过基线时，优先暂停而不是扩大自动化范围。

人工接管也必须工程化。工单不能只写“请处理”，应绑定业务主键、当前状态、推荐动作、禁止动作、审批角色和验证查询。高风险动作采用双人复核，执行者不能同时批准自己的调账；每次操作记录前值、后值、原因、规则版本和关联事故。人工不是自动化失败后的黑洞，而是状态机中的一个可审计节点，处理结果仍需回到实时或日切对账中验证。

3.5.3 端到端案例：支付成功但订单未更新

假设支付渠道已返回成功，订单服务因网络超时没有完成状态推进。正确目标不是“再次扣款”，而是让订单、支付账本和用户可见状态最终收敛。

1. 正常链路：订单服务创建 PENDING_PAYMENT，支付服务记录支付单；支付成功与 payment_succeeded 事件在本地事务中写入支付账本和 Outbox；Relay 投递事件，订单消费者以 payment_id 幂等推进到 PAID。
2. 故障发生：消费者处理后返回前崩溃，Broker 重投；唯一键拒绝重复副作用，状态机把重复事件视为已处理。若支付服务提交成功但 Relay 未发出，Outbox 扫描发现未投递记录。
3. 实时收敛：订单查询支付服务或接收渠道回调；若支付账本为成功而订单仍为待支付，创建差异项，重放事件或执行只推进状态的补偿命令。
4. 准实时对账：按 payment_id、订单号和渠道流水号联查，校验金额、币种、商户和版本；金额不一致时禁止自动补偿，转人工冻结。
5. 最终验证：订单状态、支付账本、库存动作和通知记录均有证据；用户看到“已支付/处理中”的状态，客服可查询时间线，财务可在日切对账中复核。

这里的关键不变量是：支付成功只允许订单从 PENDING_PAYMENT 向前推进，不允许回退覆盖；同一支付单只能产生一次订单支付事实；任何未知状态都必须可查询，不能用超时直接展示失败。Saga 可以协调跨服务步骤，但补偿是业务动作，不是数据库回滚；库存释放、退款和订单关闭各自需要明确前提、权限和审计。[12]

这个案例说明，最终一致性不是“过一会儿就会好”，而是有状态、有水位、有证据和有停止条件的恢复过程。对外展示也应区分“失败”“处理中”“成功”三种语义：在支付结果未知时展示处理中，既避免用户重复操作，也避免系统把未知事实伪装成失败。美团的对账体系实践把实时、准实时和离线核对结合起来，目的正是将单笔异常、批次偏差和长期账务问题放进不同处理节奏中。[18]

3.5.4 资损三道防线

资损包括错误计价、重复扣款、重复退款、超卖、少卖、优惠预算穿透、结算错账和人工调账失控。最小治理模型是“三道防线”：

任何金额和库存操作都应能解释“前值、动作、后值、来源、规则版本、操作者”。规则服务可以拦截风险，但不能成为新的无审计黑箱；硬编码阈值必须有配置版本、生效时间和回滚路径。

不同业务的高风险不变量不同，不能只用一个“成功率”覆盖：

资损事件的处理顺序应是“止血—定界—保全—收敛—复盘”。止血可以暂停优惠、冻结退款、关闭异常库存动作或限制某个租户，但要记录开关生效范围；定界要按时间、版本、规则和业务主键计算影响，而不是只统计报错数；保全要保留原始请求、事件、账单和配置版本；收敛要使用幂等补偿或人工调账；复盘则把缺失的不变量转成校验、告警和发布门禁。若先调账后定界，可能把问题掩盖并制造第二次差异。

3.6 组织文化与生产红线

3.6.1 无指责复盘模板

无指责不是免除责任，而是让参与者能如实描述当时看到的信号、采用的假设和采取的动作。Etsy 的实践强调从系统条件、决策过程和失败机制学习，而不是寻找一个“坏人”作为根因。[13]

复盘文档控制在一页也可以有效，但必须包含：

行动项不能只写“加强监控”。应写成“为 payment_id 建立唯一约束和重复率告警，灰度验证重复事件不产生第二次订单推进，owner 为 X，截止日期为 Y”。复盘结束不等于治理完成，只有护栏上线并验证，经验才算进入系统。

事故协作应把角色和决策分开。事故指挥者负责优先级、风险和对外节奏，不亲自执行所有命令；执行负责人负责回滚、限流、切流或补偿；通信负责人负责影响范围、用户公告和内部时间线；记录负责人保存证据、命令和假设；领域 owner 负责判断业务不变量是否恢复。小事故可以一人兼任多个角色，但必须显式记录。任何高风险动作都要先说清“预期改变什么、如果没有改变怎么办、如何撤销”，避免多人凭直觉同时改动生产。

行动项按风险排序，而不是按会议上谁发言最积极排序。立即项修复正在扩大损失的护栏缺口；短期项补齐幂等、告警、回滚和对账；长期项减少架构耦合或替换高风险流程。每一项都要有验收查询或演练证据，连续两个周期没有进展就重新升级。DORA 的变更失败率和恢复时间可以作为组织层趋势指标，但它们不能替代订单、金额、库存等领域正确性指标；指标改善若伴随人工调账增加，不能判定治理成功。[3]

3.6.2 生产环境五条红线

1. 不允许没有超时、幂等语义和回滚/查询路径的远程写调用进入核心链路。
2. 不允许直接改权威账本、订单状态或库存余额；紧急操作也必须经过受控命令、审批和审计。
3. 不允许用“接口返回成功”替代业务正确性验证；支付、库存、价格必须有独立不变量和对账。
4. 不允许无限重试、无限堆积和无限自动重放；每条路径都要有预算、上限和人工接管点。
5. 不允许发布、配置和补偿绕过灰度、观测和可逆性；无法回滚时必须先设计前向修复。

3.7 本章小结与延伸思考

生产可靠性可以压缩成五个判断句：

• 先定义业务结果，再定义服务指标；正确性和可恢复性不能被可用性掩盖。
• 先划定故障域，再组合超时、限流、重试、熔断、降级和舱壁；保护机制必须说明副作用。
• 先确认权威事实，再设计事件、读模型、对账和补偿；最终一致不等于无边界等待。
• 先建立 1-5-10 的止血节奏，再定位根因；指标恢复后仍要验证数据收敛。
• 先把债务、事故和行动项变成可验证的约束，再谈组织成熟度。

上线前可用以下清单做快速评审：关键旅程是否有 SLO 和错误预算？每个远程调用是否有 deadline？写操作是否有幂等键和状态机？异步事件是否可重放？权威数据是否可对账？告警是否连接到动作？发布、配置和补偿是否可审计、可暂停、可回滚？

延伸思考：当业务规模扩大十倍时，最先失效的是哪个假设？如果不能使用消息队列，如何用本地事务、扫描和对账保持收敛？如果错误预算持续耗尽，应该降低目标、增加容量，还是停止某类功能？

参考资料

[1] Beyer B, Jones C, Petoff J, Murphy N R, eds. Site Reliability Engineering：Service Level Objectives；Service Best Practices. O’Reilly Media, 2016.

[2] Google Cloud. Use Four Keys metrics like change failure rate to measure your DevOps performance. 2020. DORA 指标的工程化说明；不将行业分层阈值直接当作团队目标。

[3] Fowler M. Technical Debt Quadrant. 2009.

[4] Kruchten P, Nord R, Ozkaya I. Managing Technical Debt: Reducing Friction in Software Development. Addison-Wesley Professional, 2019.

[5] Nygard M T. Release It! Second Edition: Design and Deploy Production-Ready Software. Pragmatic Bookshelf, 2018.

[6] Amazon Web Services. Reliability Pillar: Design interactions in a distributed system. AWS Well-Architected Framework.

[7] Amazon Web Services. REL05-BP03 Control and limit retry calls. AWS Well-Architected Framework.

[8] Sigelman B H, Barroso L A, Burrows M, et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Research, 2010.

[9] OpenTelemetry. Signals；Observability primer. CNCF OpenTelemetry documentation.

[10] Kleppmann M. Designing Data-Intensive Applications. O’Reilly Media, 2017.

[11] Richardson C. Pattern: Transactional outbox. Microservices Patterns companion site.

[12] Richardson C. Pattern: Saga. Microservices Patterns companion site.

[13] Etsy Engineering. Blameless PostMortems and a Just Culture；Allspaw J. Debriefing Facilitation Guide.

[14] Majors C, Fong-Jones L, Miranda G. Observability Engineering, 2nd ed.. O’Reilly Media, 2026.

[15] Amazon Web Services. Incident lifecycle in Incident Manager. AWS Systems Manager documentation.

[16] 周志明. 《凤凰架构：构建可靠的大型分布式系统》：分布式事务. 凤凰架构，2022。

[17] Amazon Web Services. 事务性发件箱模式. AWS Prescriptive Guidance 中文文档。

[18] 美团技术团队. 美团配送资金安全治理之对账体系建设. 美团技术团队，2018。

[19] 阿里云开发者社区. 云上混沌工程：从故障注入到稳定性治理. 阿里云开发者社区，2022。

[20] OpenTelemetry 社区. 可观测性入门. OpenTelemetry 中文文档。

第 4 章 大事务处理方法论：Saga、补偿与最终一致性

大事务不是把多个数据库强行变成一个数据库，而是把一个跨系统的关键业务动作拆成可提交、可重试、可补偿、可审计、可最终收敛的状态机。本章从电商创单出发，讨论大事务的难点、决策点、异常处理和治理方法。

很多工程师第一次听到“大事务”时，会自然联想到数据库事务、分布式事务，甚至 2PC / XA。这些概念当然重要，但如果把它们直接套到互联网业务里，往往会把问题理解偏。

互联网系统里的大事务，真正要解决的不是“如何让多个数据库像一个数据库那样一起提交”，而是：

当一个关键业务动作必须跨库存、营销、订单、支付、账务等多个系统共同完成时，系统如何在失败必然发生的现实里，仍然把结果收敛到可解释、可恢复、可补偿的状态。

这里有一个必须先划清的边界：

• 数据库事务解决一个数据库内部的原子性、隔离性和持久性。
• 分布式事务协议试图在多个资源之间提供更强的提交语义。
• 业务大事务管理一个业务目标跨多个本地事务和外部副作用后的最终结果。
• 长生命周期业务流程管理业务对象跨支付、履约、审核、售后等多个阶段的持续推进。

例如，订单从创单到支付、履约、售后，是一个长生命周期业务流程；而“创单”这个关键节点内部的锁库存、占优惠、落订单，则是一个典型的大事务。本章只聚焦“创单这一刻如何做对”，第 5 章再讨论订单或商品如何跨阶段持续运行。

4.1 问题定义：大事务到底在解决什么问题

先把三个经常混在一起的概念拆开：

数据库事务关心的是“同一个数据库里的几条 SQL 要不要一起成功或失败”。分布式事务关心的是“多个资源管理器能不能形成统一提交语义”。业务大事务关心的则是“一个业务流程跨多个系统推进时，如何保证结果最终正确，且过程可解释、可恢复、可审计”。

这三者不是相互替代的关系，而是不同层次的问题。大事务内部仍然需要本地事务；Saga 的每一个步骤通常都应该在参与方内部原子提交；Outbox 也必须依赖本地事务把业务事实和待发送事件一起写入。只是，跨系统的整体目标不能再假设由一次本地 commit 自动完成。

4.1.1 为什么不能把所有事情都塞进 2PC / XA

传统两阶段提交的价值在于提供较强的统一提交语义，但它要求参与者支持协议、在准备阶段保持资源状态，并共同实现故障恢复。它并非“错误方案”，而是有严格的适用边界。

真实互联网业务经常不满足这些前提：支付网关、短信平台和物流供应商不会加入你的数据库事务；用户支付和人工审批不能长期持有数据库锁；短信、支付受理和供应商订单也不一定存在真正的回滚。业务上更常见的动作是取消占用、冲正流水、标记失败和等待对账。

Helland 在讨论大规模系统时，把这类现实概括为：应用程序往往不能假设存在覆盖所有业务对象和外部系统的全局分布式事务。[2] 它提醒设计者：一致性语义必须和参与者能力、业务时限以及恢复路径一起定义。

《凤凰架构》把它归纳为多服务、多数据源的事务问题，强调按业务一致性与隔离性需求选型。[7]

因此，本章的核心问题不是“有没有一种更强的事务框架”，而是：业务动作的最小边界是什么，哪些步骤会留下副作用，每种结果和补偿分别意味着什么，请求中断后能否从持久化事实恢复，以及谁有权判断最终应为成功、已补偿、待对账还是待人工处理。

这把“大事务”从接口编排转成状态收敛。

4.2 约束与指标：为什么创单节点天然是大事务

电商创单看起来只是用户点击一次“提交订单”，但在服务端通常至少包含以下动作：

1. 校验购物车、商品、价格、税费和运费快照。
2. 判断库存是否仍然可售，并预占目标数量。
3. 校验优惠券、满减、积分或会员权益，并占用额度。
4. 创建订单主记录与订单行，保存价格和优惠快照。
5. 创建支付单或支付上下文，为后续支付做准备。
6. 生成后续履约、通知、搜索和统计所需的事件。

真正的难点不在步骤数量，而在于每一步都可能拥有独立的本地事务和失败语义：

• 库存预占成功，但订单服务写库失败。
• 订单已写入，但营销服务超时，无法确定优惠是否已经占用。
• 订单和库存都成功，但支付上下文创建结果未知。
• 用户重复点击提交，两个请求同时通过库存检查。
• 第一次调用已经在下游提交，响应却在返回前丢失，客户端于是再次发起请求。
• 订单超时取消后，库存释放和优惠释放只完成了一部分。

所以创单节点天然具有四个特征：跨系统、多副作用、可失败、需收敛。可以用下面的约束表把它从“接口链路”转换成“系统设计问题”。

4.2.1 先定义成功，不要只定义返回码

“HTTP 200”不是业务成功的充分条件。一个创单动作至少要区分五种结果：

• 明确成功：订单已经创建，关键资源已确认，后续动作可以继续。
• 明确拒绝：库存不足、优惠失效、风控拒绝等业务条件不满足，不应该盲目重试。
• 技术失败且确认未执行：例如参数校验失败，或下游在受理前返回明确错误。
• 结果未知：请求超时、连接断开、进程在提交后崩溃，无法从响应判断下游是否已经执行。
• 进入收敛流程：在线请求无法继续，但系统已经记录事务单，后续由重试、补偿、对账或人工操作推进。

如果把最后三类全部压成“失败”，系统就会在结果未知时重复执行副作用；如果把它们全部压成“成功”，系统又会把未确认的业务事实暴露给用户。成功判据必须由业务状态和下游权威事实共同决定。

4.2.2 指标应该围绕收敛，而不是只看 RPC 成功率

大事务的关键指标不应只有平均延迟和接口错误率，还应包括：

• 事务单从创建到终态的停留时长。
• UNKNOWN 步骤数量及其最大存留时间。
• 补偿任务成功率、重试次数和补偿失败积压。
• 对账差异数量、差异金额或资源量、差异存留时间。
• 人工处理队列长度、逾期任务数量和人工收敛耗时。
• 重复请求被正确吸收的比例，以及重复副作用数量。

这些指标表达的是系统能否把“不确定”变成“确定”；只看在线接口成功率是不够的。

4.3 核心模型：状态机、事务单与步骤账本

大事务设计的起点不是“先选 Saga 框架”，而是先定义一个可以被持久化、查询、重试和审计的业务动作模型。

4.3.1 业务动作、事务单和步骤账本

以创单为例，可以把模型拆成三层：

业务动作回答“我们要完成什么”；事务单回答“这一次动作整体走到哪里”；步骤账本回答“每一个可能产生副作用的动作究竟发生过什么”。

如果只保存一个订单状态，就无法区分“订单没有创建”和“库存已经预占但订单写入失败”。如果只保存日志，又无法让恢复程序安全判断下一步。事务单与步骤账本不是为了增加表数量，而是把恢复所需要的事实从日志文本中提取成可查询数据。

4.3.2 权威事实源与不变量

每一种资源都必须有明确的权威事实源：库存是否被占用由库存系统确认，优惠是否占用由营销系统确认，订单是否存在由订单系统确认，支付是否受理由支付渠道或支付系统确认。事务协调者可以保存副本和执行记录，但不应在没有查询依据时凭自己的状态替代参与方事实。

至少需要建立以下不变量：

1. 一个可能产生副作用的步骤必须拥有稳定、可重放的幂等键。
2. 同一幂等键最多产生一份业务副作用，并且重复请求返回第一次执行的语义结果。
3. 事务单状态只能通过受控状态迁移变化，不能由多个服务直接覆盖同一个字段。
4. 补偿动作必须检查当前权威状态，不能把已经确认的资源再次释放或把已冲正的流水重复冲正。
5. 结果未知不能直接跳过，也不能直接重做，必须先查询、重放或进入可运营的待处理状态。
6. 每条事件都应带有业务主键、事件 ID、版本或序列信息，使消费者能够识别重复和过期消息。

4.3.3 状态不是“成功 / 失败”二选一

事务单可以使用下面的最小状态集合：

PENDING
  -> RUNNING
  -> SUCCEEDED

RUNNING
  -> UNKNOWN
  -> COMPENSATING
  -> SUCCEEDED

UNKNOWN
  -> RUNNING
  -> COMPENSATING
  -> MANUAL_REVIEW

COMPENSATING
  -> COMPENSATED
  -> MANUAL_REVIEW

这里的 UNKNOWN 不是错误日志里的临时标记，而是一个需要持久化的业务状态。COMPENSATED 表示已确认的副作用已经被业务等价地回收，不代表系统回到了完全没有发生过的历史；MANUAL_REVIEW 表示自动机制无法在安全边界内继续推进，需要带着完整上下文交给有权限的人处理。

步骤状态还应区分“未开始、执行中、已成功、结果未知、补偿中、已补偿”。只有把这些状态保存下来，进程重启后协调者才知道应该查询、继续、补偿还是停止。

4.3.4 最小数据模型

编排式 Saga 不是在一个 Service 中写一串接口调用。进入生产后，最重要的是持久化执行事实：进程重启、网络超时、消息重复和人工介入发生后，系统仍然知道这次动作走到了哪里。

可以从四类记录开始：

事务单和步骤账本必须有明确的所有者。协调器可以负责事务单和步骤推进，库存服务负责库存事实，营销服务负责权益事实，订单服务负责订单事实。不要让协调器为了“方便查询”直接修改库存服务的状态字段。

4.3.5 幂等键的作用域

幂等键不能只写成一个全局字符串，而要回答“谁在什么语义下去重”。推荐把它拆成：

业务意图键 = client_request_id + user_id + action_type
步骤执行键 = transaction_id + step_name + resource_id
补偿执行键 = transaction_id + compensate_step_name + resource_id
外部请求号 = service_name + transaction_id + step_attempt_scope

同一交易单对两个不同 SKU 的库存预占不能共享一个会误吞请求的键；同一 SKU 的同一业务意图也不能因为重试生成新键。幂等记录应保存第一次结果或可查询的结果引用，避免重复请求只能得到“已处理”却拿不到订单号、reservation ID 或支付单号。

4.3.6 乐观并发控制

协调器可能被 HTTP 重试、消息重投和定时器同时唤醒。事务单状态更新应带版本或状态条件：

UPDATE transaction
SET status = 'COMPENSATING', version = version + 1
WHERE transaction_id = :transaction_id
  AND status = 'RUNNING'
  AND version = :expected_version;

受影响行数为零时，不要简单报错或再次写入；应重新读取权威事务状态，判断是重复唤醒、正常竞态还是版本冲突。版本控制保护的是协调记录，不能替代库存或余额系统自己的并发控制。

4.4 参考架构：同步边界、Saga/TCC、Outbox 与消息语义

围绕创单这类关键节点，常见实现路线可以分为同步短流程、协同式 Saga、编排式 Saga 和 TCC。Outbox 通常不是独立的终局方案，而是其中某些路线的可靠事件基座。

Saga 最初就是为长时间事务提出的分解思路：把一个长事务拆成多个本地事务，并为已经完成的步骤定义补偿路径。[1]

4.4.1 同步 RPC + 本地事务

做法是由一个入口服务串行调用库存、营销和订单服务，尽量在一次请求中完成全部步骤；每个服务用本地事务保护自己的数据。

它适合以下前提：步骤有限、没有长等待、参与方响应稳定、失败后可以直接向调用方返回拒绝、补偿动作很少且容易查询。它的优点是链路直观、用户反馈快、排障入口集中。

但同步并不等于原子。假设入口服务先调用库存预占，再调用订单写入：库存成功后，入口进程在第二次调用前崩溃，数据库事务不会替你释放库存。同步只降低了流程延迟，并没有消除跨系统副作用。

因此，使用同步 RPC 时仍然需要：

• 为每个可重试请求定义幂等键。
• 把已完成的步骤持久化，而不是只放在调用栈里。
• 为中间失败提供释放或补偿入口。
• 在超时后查询下游，而不是直接假设“没有执行”。

4.4.2 协同式 Saga

协同式 Saga 由参与方通过事件彼此驱动：订单服务发出 OrderCreated，库存服务消费后预占库存并发出 InventoryReserved，营销服务再处理优惠；失败时由参与方发布补偿事件。

它的优点是领域自治强，服务之间不依赖中央协调者；当事件本来就是领域边界时，协同式设计可以自然扩展。代价是全局路径分散，补偿逻辑散落在多个服务中，参与方增加后依赖关系容易变成隐形拓扑，排障者必须从事件链拼出完整历史。AWS 的 Saga 指南也提示，编舞式方案的参与方增加后依赖追踪会变难。[3]

Seata 中文文档将 Saga 定义为先提交本地事务，失败后补偿前序参与者，并支持状态机编排正向与补偿节点。[8]

它适合多系统自治、主控方不强且事件边界存在的场景；若主链路需要判断成功或补偿，需建设事务视图或审计投影。

4.4.3 编排式 Saga

编排式 Saga 引入一个协调者，由它持久化流程状态并显式推进步骤：先预占库存，再占用优惠，再创建订单，失败时根据已完成步骤触发补偿。协调者不应把自己设计成一个持有全局锁的“超级事务管理器”，而应是一个可重入、可恢复的状态推进器。

它适合：

• 业务动作有明确主控方。
• 步骤顺序和补偿顺序需要集中解释。
• 需要统一审计、重试、超时和人工接管。
• 参与方可以提供幂等执行和结果查询接口。

它的代价是协调者本身会成为复杂系统：需要高可用、状态持久化、调度、并发控制、版本升级、补偿队列和可观测性。只有内存状态会丢失“哪些步骤已经成功”的事实，盲目重试又会把不确定性变成重复副作用。

4.4.4 TCC / 预留、确认、取消

TCC 把资源操作拆成 Try / Confirm / Cancel：Try 检查并预留资源，Confirm 确认业务操作，Cancel 释放预留资源。Oracle 的 MicroTx 文档把 TCC 描述为让资源处于预留状态，随后对全部参与者确认或取消；这种模型尤其适合库存、座位、额度和余额等可以被明确预留的资源。[6]

TCC 的能力边界比普通补偿更严格：参与方必须理解预留状态，能够处理重复的 Confirm / Cancel，还要处理空回滚、悬挂和超时。它不是把普通接口改名为三个接口：

• Try 需要在本地事务中记录预留事实，不能只在内存中扣减。
• Confirm 必须在 Try 成功后可重入，重复确认不能重复扣减。
• Cancel 必须能安全释放预留，重复取消应该返回同一语义结果。
• Try 迟到时，必须识别此前已经发生的取消，避免出现“全局已经取消、迟到的 Try 又把资源冻结”的悬挂。

因此，TCC 适合资源预留语义稳定、失败代价高且参与方能共同改造的系统，不适合把普通 CRUD 都包装成三阶段接口。

4.4.5 Outbox：可靠事件基座，不是全局事务

当服务需要在一次本地事务中同时更新业务数据并发布事件时，直接“先写库、再发消息”会产生双写断裂：数据库提交成功但进程在发消息前崩溃，或者消息已经发出但数据库最终回滚。Transactional Outbox 的做法是把业务记录和待发送事件写进同一个本地事务，再由独立投递器发送事件。[4]

Outbox 解决的是“本地事实如何可靠产生事件”，没有解决：

• 下游如何避免重复副作用、查询未知结果并补偿资源变化。
• 外部系统已经受理后，如何得到最终回执。

所以 Outbox 通常和状态机、Saga 或对账体系组合使用。投递器也可能在“消息已经发出、发送记录还没标记”时崩溃，导致重复投递；消费者必须幂等，不能把“可靠投递”误读成“端到端恰好一次”。

4.4.6 一张能力对比表

4.4.7 同步边界

有消息队列不等于应该把所有步骤都异步化；一次 HTTP 请求也不等于应该把所有步骤都同步阻塞。更务实的划分方式是：这个结果是否改变当前对用户的承诺？

同步边界的目标不是让所有结果立即完成，而是让调用方明确知道“现在可以依赖什么”。例如，订单主记录和库存预占已确认，可以返回一个可支付订单；支付渠道的最终扣款则可以作为后续生命周期事件，不应该被隐藏在创单请求中。

4.4.8 Outbox 的本地原子性

典型的本地事务可以是：

BEGIN
  update order status
  insert transaction_step
  insert outbox_event
COMMIT

dispatcher reads committed outbox_event
  -> publish event
  -> record delivery attempt

如果本地事务回滚，事件不应发送；如果本地事务提交，投递器最终应能读到事件。Outbox 解决的是双写断裂，不保证消息只发送一次。投递器在消息已发出、投递记录尚未更新时崩溃，下一次仍可能再次发送；消费者必须以事件 ID、业务版本和幂等键吸收重复。

4.4.9 消息顺序和版本

消息队列的分区顺序只在有限范围内成立，不能替代业务版本。事件中至少应带有：

• 事件 ID 和事件类型。
• 业务主键与事务 ID。
• 聚合版本或序列号。
• 发生时间与生产者服务。
• 必要的价格、数量或状态快照。

消费者处理前要判断事件是否重复、是否早于当前版本、是否与当前状态允许的迁移匹配。对于不能按任意顺序处理的事件，应使用版本条件更新、重排队列或进入异常事件表，而不是让最后到达的消息覆盖当前事实。

4.5 方案选型：先写 ADR，再决定机制重量

选型不应从“团队熟悉哪个框架”开始，而应从约束和失败语义开始。下面用几个 ADR 说明常见决策。

ADR-001：不把创单设计成跨系统 2PC / XA

**背景与问题：**创单需要同时影响库存、优惠、订单和支付上下文，参与方跨多个服务，且支付或外部系统不能统一加入本地事务。

**候选方案：**跨服务 2PC / XA、同步 RPC + 补偿、编排式 Saga、TCC。

**决策：**以本地事务 + 持久化事务单 + 编排式 Saga 为主，库存和优惠等可预留资源在必要时提供 TCC 风格接口；Outbox 用于可靠传播本地事实。

**获得的能力：**可在参与方自治的前提下推进业务；每一步可以独立扩容和恢复；能够把超时、结果未知、补偿失败和人工接管建模成正式状态；对外部不可加入事务的系统保留适配空间。

**主动牺牲的能力：**不再承诺所有参与方在同一瞬间拥有全局 ACID 隔离；用户可能短暂看到“创建中”或“待确认”；补偿可能产生业务等价结果，而不是物理回到原始状态。

**已接受风险：**协调器故障、消息重复、补偿失败和并发 Saga 可能造成中间状态，需要依赖状态账本、幂等、语义锁、对账和人工收敛治理。

验证指标：UNKNOWN 步骤存留时间、补偿成功率、孤儿库存数量、订单与库存对账差异、协调器恢复时间。

**重新评估条件：**如果新增的参与方普遍支持同一事务协议，且业务要求强隔离的时间窗口很短，可以重新评估更强的提交协议；否则不能仅因为“看起来更一致”就引入全局锁和更复杂的恢复协议。

ADR-002：交易主链路选择编排式 Saga，而不是纯协同式 Saga

**背景与问题：**创单需要在一个用户请求中给出可解释结果，且库存、优惠和订单有明确顺序；失败后必须按照已执行步骤补偿。

**决策驱动因素：**主控方清晰、失败代价高、需要统一审计、参与方数量可能增长、运维人员需要从一个入口查看完整事务。

**决策：**由订单域或交易域维护协调状态，参与方只负责本地执行、幂等和结果查询；事件用于异步推进和通知，不把全局成功判断分散给任意消费者。

**获得 / 牺牲：**获得全局可见性、集中补偿和清晰的人工入口；牺牲部分领域自治，并承担协调器的高可用、版本演进和容量治理成本。

**验证指标：**单个事务从创建到终态的最大停留时间、步骤重试次数、协调器重启后的恢复成功率、人工介入率。

ADR-003：Outbox 只承担可靠事件桥接

**背景与问题：**订单状态更新后必须发布 OrderCreated 或 OrderCancelled，直接双写会有丢消息和脏消息风险。

**决策：**订单本地事务同时写订单事实、步骤账本和 Outbox；投递器至少一次发送；消费者以事件 ID、业务版本和幂等键去重。

**获得 / 牺牲：**获得本地事实与事件的原子关联；牺牲投递延迟、额外存储和清理成本，接受消息重复和消费者需要幂等。

**验证指标：**Outbox 积压、投递延迟、重复投递比例、消费者去重命中率、事件与业务事实不一致数量。

**重新评估条件：**如果事件量、顺序约束或多数据源写入方式改变，需要重新评估轮询投递、CDC 或事件存储；不能把 Outbox 表永久当作没有生命周期的垃圾桶。

4.5.1 一条实用的决策顺序

可以按下面的顺序缩小方案空间：

1. 先确认是否真的存在跨系统副作用；如果只是查询聚合，不要过度引入事务协调。
2. 再确认失败后是否需要释放资源、冲正流水或更新多个系统；如果没有，普通同步流程可能足够。
3. 明确每个参与方是否提供幂等执行和结果查询；没有查询能力时，结果未知无法安全重试。
4. 判断主控方是否明确；明确则优先考虑编排，自治则考虑事件协作，但要补全全局可见性。
5. 判断资源是否能够预留；能够稳定实现 Try / Confirm / Cancel 时才考虑 TCC。
6. 最后才选择框架、消息系统或 Workflow 产品，且先定义业务状态，再让技术平台承载这些状态。

4.6 完整案例：创单动作如何从请求走向收敛

下面用一个简化的创单案例贯穿正常链路和异常分支。假设参与方包括：交易服务、库存服务、营销服务、订单服务和支付上下文服务。支付本身属于后续生命周期，创单只负责建立支付入口，不等待用户完成支付。

4.6.1 先创建事务单，而不是先调用库存

客户端提交请求时携带 request_id。交易服务先以用户、购物车版本、请求 ID 和业务动作类型组成幂等作用域，检查是否已经存在同一请求的事务单：

• 如果已经成功，返回第一次成功结果。
• 如果仍在执行，返回处理中状态和 transaction_id。
• 如果已明确失败，返回原失败原因。
• 如果处于 UNKNOWN 或 MANUAL_REVIEW，返回可查询的待处理状态，不能自动创建另一笔订单。

随后，交易服务在本地事务中写入事务单、输入快照和初始步骤账本。输入快照至少包括商品、数量、价格版本、优惠版本和配送约束；它不是为了替代权威服务，而是为了让后续补偿和审计知道当时系统试图完成的目标。

4.6.2 正常链路

正常链路可以表示为：

客户端提交 request_id
  -> 创建或恢复 transaction
  -> 校验价格、库存快照和业务资格
  -> ReserveInventory(transaction_id, idempotency_key)
  -> ReservePromotion(transaction_id, idempotency_key)
  -> CreateOrder(transaction_id, idempotency_key)
  -> CreatePaymentContext(transaction_id, idempotency_key)
  -> 事务单 SUCCEEDED，发布 OrderCreated

每一步都有本地成功判据，而不是仅凭 HTTP 响应码。例如库存步骤的成功判据应包含库存服务返回的预占记录 ID、数量、过期时间和版本；营销步骤应包含优惠占用流水号；订单步骤应包含订单号和订单状态；支付上下文步骤应包含支付单号和允许支付的截止时间。

同步请求是否等待所有步骤完成，要由用户承诺决定。如果产品要求点击后立即看到可支付订单，交易服务至少要同步确认库存、优惠和订单主记录；通知、搜索索引和画像可以异步。支付渠道最终受理则属于后续流程，不应为了“返回一个完整结果”而让创单请求等待用户支付。

4.6.3 步骤账本示例

步骤账本应保存“最后一次尝试”和“下游可查询的外部请求号”，而不是只存一个布尔值。这样，恢复程序才可以判断：某步骤从未发出、已经发出但未知、已经成功，还是已经执行补偿。

4.6.4 五类异常分支

创单案例可以用下面的矩阵统一表达：

库存成功、订单失败时，事务单转为 COMPENSATING，先按 tx:order 查询订单；确认未创建后，以补偿派生键释放库存，释放未知则进入补偿队列。若订单其实已创建，协调者必须恢复订单事实，不能释放库存后再把订单标成失败。

优惠或支付结果未知时，都遵循“记录未知—查询—同键重试—对账 / 人工”的顺序。是否允许订单继续，取决于价格承诺和资损风险，而不是技术框架。支付上下文若只有创建接口、没有按幂等键查询接口，就不满足关键参与方的最低能力。

重复请求需要事务单唯一约束、订单接口幂等和资源服务自己的幂等记录三层保护。两个不同业务意图争抢最后一件库存，则是并发控制问题，仍需原子扣减、版本校验、语义锁或预占记录，不能误以为幂等已经解决竞争。

迟到回调不能按接收时间覆盖状态。已取消订单收到支付成功时，应查询渠道权威状态并生成退款或待退款任务，保留回调、取消和退款之间的审计关系。

4.7 故障处理与收敛治理

最危险的工程错误，是把所有失败都理解成“再试一次”。不同失败对应完全不同的动作。

4.7.1 明确拒绝与技术失败必须分开

库存不足是业务拒绝，重试不会让库存凭空增加；数据库连接短暂失败是技术失败，可能重试成功。错误码、异常类型和下游契约必须能让协调器区分这两类结果。

重试还要受到截止时间和预算约束。创单有自己的 deadline，各步骤只能消耗部分预算；不能让库存已经过期后，协调器仍然无限重试营销。指数退避和抖动能缓解拥塞，但不能替代幂等。AWS 对幂等 API 的说明强调，安全重试的关键是让服务识别重复请求并返回与第一次处理一致的结果。[5]

4.7.2 结果未知必须先查询

“请求超时”只说明调用方没有在截止时间内得到响应，不说明下游没有执行。一个正确的未知结果处理过程是：

1. 将步骤持久化为 UNKNOWN，记录请求发送时间、超时点和外部请求号。
2. 调用下游的幂等查询接口，查询同一个执行键。
3. 查询到成功则补写执行事实并继续；查询到未执行才允许使用同一键重试。
4. 查询接口也不可用时，进入延迟查询、对账或人工队列。

如果下游没有查询接口，系统只能降低承诺：例如把该步骤设计成可补偿的预留，或要求外部系统提供对账文件。没有查询能力时，不能靠“再发一次通常没问题”来冒险。

4.7.3 补偿不是机械地反向调用

补偿动作至少分为四类：

• 资源释放：释放库存、座位、额度或优惠占用；要求校验占用归属和当前状态。
• 反向流水：账务、积分和权益使用冲正或反向流水，保留原始事实，不删除历史。
• 不可逆通知：短信、邮件、推送无法撤回，只能发送更正或记录通知结果。
• 外部受理动作：支付退款、供应商取消可能异步完成，需要查询和等待最终回执。

补偿顺序也必须服从业务依赖。订单取消通常应先关闭支付入口或进入取消中，再释放库存和优惠；如果先释放资源，迟到的支付回调可能把一笔已经失去资源的订单推进到错误状态。补偿顺序应成为状态机的一部分，而不是开发者凭直觉在 catch 块里倒序调用。

4.7.4 并发 Saga 与语义锁

两个创单动作可能同时读取到“还有一件库存”，或者一个取消动作与支付确认同时推进。Saga 没有自动提供跨服务隔离，因此需要使用资源版本、语义锁、预占状态或可串行化的本地更新来保护关键竞争。

所谓语义锁，不一定是数据库长锁，而是把“正在被某个事务单处理”写入资源状态或独立占用记录，让其他业务动作知道应该等待、拒绝或重新读取。这样既能避免长时间持有数据库锁，也能让并发冲突成为可解释的业务状态。

4.7.5 对账、可观测与人工收敛

在线重试和自动补偿仍可能失败，因此关键链路必须有独立于在线流程的对账能力。对账不是上线后的补丁，而是大事务设计的一部分：在线链路负责尽快推进，对账链路负责发现遗漏、识别歧义并提供受控修复入口。

4.7.5.1 对账的四组事实

每组对账都要先定义口径：按订单号、交易单号、外部请求号还是资源流水号关联；时间窗口多长；差异是否允许短暂存在；哪些动作可以自动修复；哪些动作必须双人复核。没有口径的“对账脚本”往往只是另一种不可审计的人工改库。

4.7.5.2 可观测性要关联业务事实

日志、指标和链路追踪至少贯穿以下关联键：

transaction_id
business_id / order_id
idempotency_key
external_request_id
event_id

指标应能回答哪些事务卡住、卡在哪个参与方、是否产生副作用、补偿是否成功、谁需要处理。重点关注各步骤未知和补偿比例、UNKNOWN 存留时间、事务终态延迟、补偿队列年龄、对账差异及人工队列逾期量；单看某个 RPC 成功率无法判断大事务是否收敛。

4.7.5.3 人工接管必须是受控状态迁移

人工操作台至少应显示：事务单、业务主键、已执行步骤、外部请求号、最近错误、当前权威状态、建议动作、风险提示和截止时间。操作者应选择“重新查询”“重试补偿”“确认外部成功”“终止并冻结”等有限动作，并填写原因；系统记录操作者、时间、前后状态和审批依据。

对资金、库存和高价值权益动作，应增加权限隔离、双人复核或风险阈值。人工不能直接把订单字段改成“已支付”，而应执行一个被授权的业务命令，让系统校验渠道事实并产生相应流水。直接改库可能临时解决一笔订单，却会破坏状态机、审计链和后续对账。

4.8 演进与迁移：从简单方案到其他关键业务

大事务能力应渐进建设：

4.8.1 阶段一：同步短流程

适用于步骤少、依赖稳定、失败可以立即返回的动作；仍要建立请求幂等键和本地状态记录。

4.8.2 阶段二：状态机 + 补偿任务

出现“库存成功、订单失败”时，先建立事务单和步骤账本；补偿可以由定时任务或队列驱动，但必须使用同一幂等键并记录尝试。

4.8.3 阶段三：编排式 Saga

当步骤顺序、补偿关系、超时和审计已经跨多个模块时，把协调逻辑集中成可恢复的编排器，为复杂度提供可观察、可治理的边界。

4.8.4 阶段四：关键资源引入 TCC

当库存、余额、座位或授信额度的失败代价高，且参与方能按预留模型改造时，引入 TCC；上线前先覆盖空回滚、幂等、悬挂、超时和重复确认。

4.8.5 阶段五：平台化能力

只有多个领域反复出现状态账本、补偿队列、人工操作台、对账和审计需求时，才值得抽象共享平台。平台提供持久化、幂等、调度、观测和审计，不把所有业务补偿规则硬编码成不可扩展的通用引擎。

4.8.6 从创单迁移到其他关键业务动作

创单只是最典型的样本。其他场景仍然要先划定关键动作、权威事实和副作用，再决定补偿方式：

• 注册与认证：账号是权威事实，权益可以补发，短信和邮件不可逆。账号已创建但权益失败时进入“权益待发放”；实名结果未知时按身份证或外部请求号查询，不能创建第二个账号。
• 退款与售后：退款单、可退金额、支付渠道、优惠回补和库存恢复可能分属不同系统。渠道“受理成功”不等于资金到账，补偿通常是查询、重试、冲正或人工核验，而不是撤销一条退款记录。
• 商品审核与发布：商品主数据是权威事实，索引和缓存是可重建投影。发布失败时可以保持“发布中 / 待同步”，通过事件重放收敛，不必强行回滚所有投影。

这三个场景的共同判断是：关键动作完成的标准不是所有通知都已发送，而是权威事实已经确定，必要资源已经确认或释放，不可逆副作用已经被记录，剩余投影有可追踪的异步收敛路径。

4.9 方法论总结、评审清单与常见反模式

4.9.1 方法论总结

大事务设计可以归纳为一条推理链：先定义关键业务动作和参与方约束，再明确权威事实源、事务单、步骤账本、状态和不变量；随后按同步确认、异步推进和异步收敛划分边界，依据参与方能力组合选择同步流程、Saga、TCC 和 Outbox；最后用完整案例验证明确拒绝、结果未知、部分成功、补偿失败和迟到回调，并以幂等、查询、对账、观测和人工接管把失败变成可治理状态。

最关键的判断始终不变：不要把“接口调用成功”误当成“业务已经完成”。只有所有必要副作用被确认、被补偿，或进入明确的待处理状态时，这次业务动作才真正收敛。

系统的价值不是承诺不会失败，而是让失败后的事实、责任和修复路径可见：发生了什么、哪些动作已生效、哪些结果未知、谁拥有权威事实、下一步由谁推进，以及何时回到成功、已补偿、待对账或待人工处理。

4.9.2 评审清单

在方案评审时，至少逐项回答：

1. 这个关键业务动作的最小边界是什么？哪些动作属于后续长流程？
2. 哪些参与方会产生真实副作用？每个副作用的权威事实源是什么？
3. 每个步骤的幂等键如何构造？重复请求返回什么结果？
4. 超时后如何区分“未执行”和“结果未知”？是否存在真实查询接口？
5. 哪些结果必须同步确认，哪些可以异步推进，哪些只能异步收敛？
6. 事务单、步骤账本、Outbox 和消费者处理记录分别由谁维护？
7. 补偿是释放资源、反向流水、状态更正还是外部异步取消？
8. 补偿失败会停在哪里？告警阈值是什么？谁可以人工接管？
9. 并发下单、取消、支付回调和重复消息如何避免旧状态覆盖新事实？
10. 方案选择牺牲了什么能力？验证指标是什么？什么条件下重新评估？

4.9.3 常见反模式

• 把异常处理当补偿设计：只写 try/catch，没有持久化步骤状态和可重入补偿。
• 把重试当幂等：同一请求重放时重复扣减资源，事后再靠人工修复。
• 把超时当未执行：响应丢失后直接重做，导致重复订单、重复扣款或重复占用。
• 把 Outbox 当全局事务：可靠发消息不能替代下游幂等、补偿、查询和对账。
• 把 Saga 当回滚：补偿得到的是业务等价结果，不一定能恢复所有外部世界的历史状态。
• 把人工改库当恢复机制：短期绕过流程，长期破坏权威状态、审计和版本控制。
• 为了“绝对一致”持有长锁：把等待支付、供应商回调或人工审批塞进数据库事务，最终牺牲可用性且仍无法覆盖外部副作用。
• 先选框架再定义状态：让框架的任务模型反过来决定业务语义，导致状态不可解释、升级难以迁移。

参考文献与延伸阅读

本节汇总正文引用源，供延伸阅读；正文编号用于就近说明，链接优先指向原始论文或官方页面。

[1] Hector Garcia-Molina, Kenneth Salem, “Sagas”, ACM SIGMOD, 1987。

[2] Pat Helland, “Life beyond Distributed Transactions: an Apostate’s Opinion”, CIDR 2007, 2007。

[3] AWS Prescriptive Guidance, “Saga patterns”。

[4] AWS Prescriptive Guidance, “Transactional outbox pattern”。

[5] Malcolm Featonby, “Making retries safe with idempotent APIs”, Amazon Builders’ Library, 2021。

[6] Apache Seata，“Seata TCC 模式”。

[7] 周志明，《凤凰架构》“分布式事务”章节，在线阅读。

[8] Apache Seata，“Seata Saga 模式”。

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

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

上一章讲的是大事务。大事务解决的是一个关键时刻的一致性问题，例如创单时锁库存、占优惠、落订单，或者发布时更新主数据、推送索引、发送事件。它关心的是一个动作在有限时间内如何完成、失败后如何补偿，以及怎样让一次局部成功最终收敛。

这一章讨论的是另一个层次的问题：当一个业务对象要跨创单、支付、履约、售后，或者跨 Draft、审核、发布、下线等多个阶段持续存在时，系统如何管理它的完整生命周期。一个订单可能在几秒内创建，却在几天后完成履约；一个商家入驻可能经历数周的资料补充、人工复核和合同确认；一个商品发布后还可能因为合规规则变化而重新审核。它们都不是一次接口调用可以完整表达的事情。

这里要先建立三个边界：

• 大事务关注某个关键业务动作怎样最终收敛，例如一次创单、一次退款执行或一次商品发布。
• 长生命周期业务流程关注业务对象跨阶段的状态、等待、角色、规则和恢复，它回答“现在处于什么阶段、谁可以推动、失败后如何继续”。
• Workflow是承载长流程的一种运行时手段，不是业务概念本身。可以没有 Workflow 引擎，但不能没有清晰的生命周期模型。

例如，订单从创单到支付、履约、售后，是长生命周期业务流程；其中创单时锁库存、占优惠、落订单，是一个可能使用 Saga 的大事务。商品从 Draft -> QC Approval -> Publish -> Unpublish，也是长生命周期业务流程；其中 Publish 节点内部更新主数据、发送事件、刷新索引，则可能需要本地事务、Outbox 和补偿组合。[1][6]

5.1 问题定义与边界：从大事务到长生命周期流程

5.1.1 先确定流程对象，而不是先确定框架

长生命周期业务流程，指的是一个业务对象不会在一次请求内闭环完成，而是要跨多个阶段、多个系统、多个角色和多个时间窗口持续推进。这里的业务对象可以是订单、商品、退款单、商家申请、账单、理赔单，也可以是一次批量导入或一次发布审批。对象的共同特征不是“使用了消息队列”，而是它需要在未来一段时间内继续被系统识别、唤醒、解释和治理。

因此，流程设计的第一个问题不是“选 Temporal、Camunda 还是自研状态机”，而是：

1. 什么东西正在经历生命周期？
2. 哪个标识可以贯穿所有阶段和外部交互？
3. 哪一个领域拥有它的权威事实？
4. 哪些动作改变业务事实，哪些动作只是发送通知或刷新投影？
5. 流程结束的条件是什么，结束后还允许哪些售后或纠错动作？

如果这些问题没有答案，引擎只能把混乱的业务规则持久化下来。BPMN 2.0.2 这样的流程标准可以表达事件、任务、网关、消息和边界事件，但它解决的是流程表示与交换问题，并不会替系统决定订单的权威状态、退款金额或权限边界。[3] 图形化流程可以帮助团队对齐，但不能替代领域建模。

一个实用的流程对象通常至少包含四类信息：

这些字段可以落在一张流程实例表、业务聚合表和事件/审计表中，也可以由 Workflow 平台分别持久化。存储形态可以变化，但语义不能消失。流程对象必须能够从持久化数据中解释出：它已经完成的动作、尚未完成的动作、正在等待的条件、最近一次失败，以及下一次允许执行的动作。

5.1.2 大事务和长流程不是同一条时间轴

大事务通常围绕一个关键节点展开。它在较短时间内协调多个参与方，并通过本地事务、Saga、TCC、Outbox、查询、补偿和对账让结果收敛。长流程则把这些关键节点串在业务对象的生命周期上，中间允许出现等待、人工审批、外部回调和跨版本运行。长流程不应该为了“看起来一致”而长时间持有数据库锁或远程事务。

如果把长流程只当成一个加长版大事务，通常会出现三种错误。第一，把所有状态塞进一个“超大 Saga”，却没有清楚区分订单主生命周期和单次创单动作。第二，为了等支付、等审核或等供应商，长期保持“事务进行中”的语义，既占用资源，又让其他业务动作不知道应该等待还是拒绝。第三，审批、驳回、重提、超时取消、人工补单等动作没有正式的状态迁移，只能通过脚本和人工改库兜底。

Hector Garcia-Molina 和 Kenneth Salem 在 Sagas 论文中讨论长生命周期事务时，核心思路就是把长期持有资源的事务拆成可交错的局部事务，并为已完成步骤设计补偿动作。[1] 这不是说每一个业务生命周期都必须实现成 Saga，而是提醒我们：跨时间的业务连续性不能依赖一次数据库事务。Pat Helland 进一步强调，面向大规模系统时，应用需要围绕业务实体和消息来组织状态，而不是假设所有跨服务变化都能被一个全局事务包住。[2] 周志明对分布式事务的整理也把本地事务、补偿、可靠消息和业务约束放在同一条推理链上，而不是把某一个协议当成通用答案。[19]

所以本章的边界是：关键节点内部的原子性和补偿继续交给第 4 章讨论；本章负责把这些节点放进一个可解释的生命周期，并处理等待、人工任务、规则变化、流程恢复和运营治理。这个边界可以避免“每章都重新发明一套分布式事务”，也能让评审者清楚知道一个问题究竟属于节点一致性，还是属于生命周期治理。

5.2 约束、指标与判断框架

5.2.1 长流程首先是约束问题

长流程的复杂度不是由节点数量单独决定的。三个节点的退款流程，如果涉及外部支付渠道、不可逆资金动作和人工复核，可能比十个内部节点的商品编辑流程更难治理。设计前应把以下约束显式写出来：

• 时间约束：每个阶段的正常时长、最大等待时长、业务截止时间和是否允许跨日运行。
• 角色约束：用户、系统、供应商、运营、客服、风控、财务和审核员各自能发起或完成什么动作。
• 依赖约束：哪些系统是强依赖，哪些系统只提供后置通知；依赖是否支持查询、幂等和版本校验。
• 可逆性约束：哪些步骤可以取消，哪些只能冲正或补发，哪些产生法律、资金或物流上的不可逆效果。
• 并发约束：同一对象上可能同时出现用户命令、回调、定时器、人工操作和重放任务。
• 数据约束：权威事实存在哪里，投影允许延迟多久，历史事件需要保存多久，哪些数据需要脱敏或留痕。
• 治理约束：是否需要双人复核、租户隔离、操作审计、人工接管、数据导出和合规保留。

这些约束应该转成可验证指标，而不是只写成“高可用”“可恢复”。一个合理的指标表如下：

中国信通院《分布式系统稳定性建设指南》把稳定性建设拆成目标、架构、容量、运维和安全等维度，强调稳定性不能只靠某一个组件提供。[20] 对长生命周期流程而言，这个结论可以转化为：流程引擎的可用性不是流程正确性的全部，流程还要有状态不变量、恢复入口、指标、告警、对账和人工责任人。换言之，平台在线不等于业务流程已经收敛。

5.2.2 用五个问题判断是否进入长流程

可以先用下面五个问题做范围判断：

1. 业务对象是否会跨多个阶段长期存在，而不是在一次请求内结束？
2. 是否存在用户、人工或外部系统造成的真实等待？
3. 是否需要回退、驳回、重提、暂停、恢复或超时关闭？
4. 是否需要向用户、客服或审计人员解释“现在卡在哪里、下一步是谁处理”？
5. 是否存在跨服务副作用，使得重试、补偿、查单或对账成为正常路径？

如果五个问题大部分答案是“是”，就应把它当成长生命周期流程设计。如果只有一个本地事务和一次短 RPC，先使用业务表状态和本地事务，避免因为“未来可能复杂”而过早引入流程平台。工具的重量应该由等待、治理、恢复和演进需求触发，而不是由技术潮流触发。

长流程也不等于必须微服务化。一个单体应用内的订单审核，只要有跨天等待、人工任务和规则版本，同样需要生命周期模型。反过来，一个拆成多个微服务的同步请求，如果能在一个短事务窗口内完成，也不一定需要 Workflow。服务数量是架构背景，不是流程分类标准。

5.2.3 先定义成功，再定义中间态

长流程最容易被忽略的问题是“什么算完成”。例如，商品发布的主数据已经提交，但搜索索引还没有更新；退款渠道已经受理，但资金到账仍在异步处理中；订单已经支付，但仓库尚未生成履约单。把这些都简单写成 SUCCESS 会隐藏真实风险。

建议为每一个流程定义至少四种结果：

1. 业务完成：权威事实已经满足业务目标，后置投影可以继续异步收敛。
2. 业务拒绝：规则明确拒绝，且不需要继续重试，例如库存不足、资质不符或支付失败。
3. 处理中：事实尚未确定，系统必须等待回调、查询或人工判断。
4. 待治理：自动路径无法安全决定，实例进入人工或对账队列，并有明确 owner 和下一动作。

在结果未知时，不能把技术超时当成业务失败，也不能把接口返回成功当成所有下游都完成。AWS 的幂等 API 指南把“响应丢失但请求可能已生效”作为需要优先解决的场景，并建议使用客户端请求标识和语义等价的重试响应。[7] 对长流程而言，这意味着流程实例需要保留外部请求号，并把“查明结果”建模成正式步骤，而不是让调用方盲目重新发起写操作。

5.3 核心模型：状态、命令、事件与版本

5.3.1 三层状态模型

状态不是一串展示给前端的枚举，而是一份业务契约。以订单为例，可以把状态拆成三层：

不要把所有细节压进一个 status 字段。“订单已关闭”不能说明它是用户主动取消、支付超时、风控拒绝还是履约失败；这些原因会决定后续能否重开、是否释放资源、是否允许退款以及谁有操作权限。主状态应保持稳定而有限，原因、版本、期限和外部引用应以独立字段、事件记录或不可变审计记录保存。

同样，不要为了减少字段而把所有并行子流程压成一个全局状态。订单可能同时处于“已支付、履约单创建中、发票待开具”的状态；商品可能已经发布，但合规复核和搜索索引分别有自己的进度。主状态负责表达业务对象对外的主要阶段，子流程负责表达局部执行，聚合状态由明确规则计算或由领域服务推进。这样既能避免状态爆炸，也能防止一个字段遮住多个事实。

5.3.2 命令、状态、事件不是同一件事

状态变化应该由命令触发，由事件记录，而不是让任意服务直接更新状态。

• 命令表达意图，例如“提交支付”“申请取消”“审核通过”“要求补件”。命令有发起者、权限、幂等键和校验条件。
• 状态表示当前已经确认的业务事实，例如“等待支付”“履约中”“待人工复核”。状态由权威领域根据规则迁移。
• 事件描述已经发生的变化，例如 PaymentSucceeded、OrderCancelled、ProductPublished。事件用于通知、统计、投影和下游协作。

支付服务可以发布“支付成功”的事实，但不应直接把订单表更新成“已完成”；订单域需要根据订单状态、支付单状态、金额、币种、订单版本和履约条件决定是否接受该事件。物流服务可以发布“已签收”，但售后域仍需依据签收时间、商品类型和售后规则判断是否进入可申请退款窗口。

这种区分还有一个重要作用：让外部事件成为输入，而不是拥有无限权限的写入口。事件到达时，系统必须验证业务主键、来源身份、事件版本、金额或数量、时间窗口、当前状态以及是否已处理。不能因为事件名字看起来正确，就跳过状态机和权限检查。

5.3.3 状态迁移必须有守卫条件和不变量

一张状态图只有箭头还不够，每一条箭头都要明确触发动作、守卫条件、副作用和失败去向。以“待支付订单取消”为例，规则不应只是 PENDING_PAYMENT -> CLOSED，而应写清：

1. 触发者可以是用户取消请求，也可以是支付截止时间到期的定时器。
2. 守卫条件是订单仍处于可取消状态、没有确认的支付成功事实、当前状态版本未冲突。
3. 副作用包括关闭支付入口、释放库存预占、返还优惠占用和发送订单关闭事件。
4. 如果释放资源结果未知，订单进入 CLOSING 或“资源待确认”子状态，而不是立即宣称关闭完成。
5. 如果此时已经收到支付成功事实，系统根据业务规则选择支付优先、取消优先或进入人工复核，不能由消息到达顺序偶然决定结果。

核心不变量应该写成可以检查的句子，例如：已完成订单不能直接回到待支付；已退款金额不能超过可退金额；同一个支付单只能确认一次；已关闭订单不能再创建新的履约任务；任何人工放行都必须有操作者、理由和审计记录。状态机的价值不在于画出所有可能箭头，而在于把禁止路径和必要条件变成程序可执行的约束。

5.3.4 幂等键、版本和流程定义版本

长流程里至少有三种版本需要区分：

• 对象状态版本：防止旧命令覆盖新状态，通常以 version 或聚合序号实现。
• 事件版本：描述同一业务对象的事件顺序或事件格式，帮助消费者拒绝迟到事件或做兼容转换。
• 流程定义版本：表示这一条流程按照哪套规则运行，保证在途实例不会因为代码发布而突然失去解释能力。

同一个幂等键还要明确作用域。cancel-123 是全局唯一，还是只在订单 order-123 下唯一？同一个键携带不同参数时，系统应该返回原结果还是拒绝参数冲突？AWS 的实践强调，幂等请求标识需要和请求参数绑定；同一标识代表不同意图时应报校验错误，而不是默默复用旧结果。[7]

状态更新应使用条件写入。一个简化的实现如下：

UPDATE orders
SET status = 'CLOSED',
    close_reason = :reason,
    version = version + 1,
    updated_at = CURRENT_TIMESTAMP
WHERE order_id = :order_id
  AND status = 'PENDING_PAYMENT'
  AND version = :expected_version;

受影响行数为零时，不应直接返回“系统错误”。调用方应重新读取权威状态，判断是重复请求、正常竞态、状态已被其他命令推进，还是确实发生业务冲突。版本号保护迁移顺序，状态条件保护合法路径，幂等键保护同一命令的重复执行；三者解决的问题不同，不能互相替代。

5.3.5 事件日志不自动等于事件溯源

流程通常需要保存事件、审计和执行记录，但这不等于必须把所有业务状态都实现成 Event Sourcing。事件溯源强调把应用状态的全部变化作为事件序列保存，并可以从事件重建过去状态。[10] 普通状态机也可以保存迁移日志，只把当前状态作为权威读模型。两者的选择取决于审计、重建、查询、存储和团队能力。

在大多数订单和审批场景中，推荐先采用“当前状态 + 不可变迁移记录 + 必要事件”的组合：当前状态用于快速判断，迁移记录用于审计与排障，事件用于跨边界传播。只有当历史重建、时间点查询、复杂回放已经成为核心需求时，再认真评估完整事件溯源。否则，事件流会增加版本兼容、隐私清理、重放副作用和查询模型的长期成本。

5.4 完整案例：订单、商品与退款流程

5.4.1 订单：支付回调和超时取消的竞态

订单生命周期可以简化为：

CREATED
  → PENDING_PAYMENT
  → PAYMENT_CONFIRMED
  → FULFILLMENT_PENDING
  → FULFILLING
  → DELIVERED
  → COMPLETED

另外存在取消和售后分支：

PENDING_PAYMENT ──用户取消/支付超时──► CLOSING ──资源释放确认──► CLOSED
PAYMENT_CONFIRMED ──申请售后──► AFTER_SALE_PROCESSING ──退款/换货──► COMPLETED 或 CLOSED

正常链路中，订单服务先在本地事务里创建订单和支付单，写入 PENDING_PAYMENT，并记录支付截止时间。订单服务不应该在 HTTP 请求里等待支付成功。支付服务受理请求后，以支付单号和客户端幂等键保证重复提交不会产生第二笔扣款；成功后写入支付权威事实，并通过 Outbox 或可靠消息传播 PaymentSucceeded。Outbox 解决本地订单事实与事件通知之间的双写窗口，但消息 relay 仍可能重复发送，消费者仍需要幂等。[6][8][9]

订单消费者收到 PaymentSucceeded 时，先检查支付单号、金额、币种、支付状态和订单当前版本，再执行订单状态迁移。迁移成功后，订单服务可以发起履约单创建；履约单创建本身又可能是一个由第 4 章讨论的局部大事务。订单完成支付，并不意味着履约、开票、通知和推荐投影都同步完成，它只表示订单域的支付事实已经确认。

最有代表性的异常是支付成功回调与超时取消同时到达。两条命令可能来自不同消费者，也可能一个来自用户请求、一个来自调度器。处理流程可以按下面的步骤设计：

1. 两个请求都带有订单 ID、命令 ID 和期望版本。
2. 状态机以条件更新竞争 PENDING_PAYMENT 的版本。
3. 先成功的命令获得状态迁移权，另一个命令读取新的权威状态。
4. 如果支付成功先落库，取消命令不能直接关闭订单，而要进入“支付后取消”的业务规则；如果取消先落库，支付回调需要查询渠道或根据支付事实决定是否触发退款。
5. 任何外部结果未知，都进入 PAYMENT_UNKNOWN、CLOSING 或人工复核，而不是用超时猜测结果。

这里没有一个脱离业务的“绝对正确顺序”。电商订单可能规定“支付成功优先，取消需要退款”；票务系统可能规定“座位过期优先，迟到支付自动退款”；金融业务则可能要求进入人工复核。技术实现只能确保竞态被显式记录、只允许合法迁移，并把每种选择绑定到业务规则版本。

如果库存预占已经成功，而支付失败或订单取消，取消流程不应直接删除订单。订单进入 CLOSING，编排器向库存服务发送带 reservation_id 的释放命令；库存服务以预占记录和释放动作幂等，释放完成后产生 InventoryReleased，订单再推进到 CLOSED。如果释放结果未知，流程先查库存预占状态，查询不到可靠事实时进入对账或人工队列。Saga 的补偿不是数据库回滚，而是一个有业务语义的释放、退款、冲正或状态更正动作。[5][11][13][16]

5.4.2 商品：审核、驳回、重提和发布投影

商品生命周期更适合说明人工任务和流程定义版本：

DRAFT
  → SUBMITTED
  → UNDER_REVIEW
  → APPROVED
  → PUBLISHING
  → PUBLISHED

拒绝和下线分支如下：

UNDER_REVIEW ──资料不足/规则不符──► REJECTED ──补件重提──► UNDER_REVIEW
PUBLISHED ──违规/商家下架──► UNPUBLISHED ──重新审核──► UNDER_REVIEW

商家编辑草稿可以持续几天，系统不需要为它创建一个长期占用线程的执行任务。提交时生成一次流程实例和版本快照；审核员看到的是该版本对应的资料、规则命中原因和证据链接。审核通过后，商品主数据在本地事务中变成 APPROVED 或 PUBLISHING，搜索、推荐、详情和运营活动通过事件更新投影。主数据是权威事实，索引和缓存是可重建投影；投影延迟需要被监控，但不应该让流程引擎把所有下游都当成同一个原子事务。

审核驳回必须携带结构化原因，而不是只写“审核不通过”。原因决定商家需要补什么资料、是否允许重提、是否需要更换审核人以及是否影响历史版本。一个人工任务至少包括流程 ID、商品 ID、规则版本、候选角色、允许动作、截止时间、处理结果、理由和证据引用。人工“通过”不能直接修改数据库状态，而应提交一个受权限控制的命令，经过状态机守卫后产生 ProductApproved 事件。

流程规则会变化。例如，旧版本只要求一次质量审核，新版本增加合规双审。新建实例使用 process_definition_version = 2，旧实例可以按版本 1 完成，或者按照明确的迁移规则补建合规任务。不能把所有在途实例直接套上新代码，否则昨天提交的商品可能突然从“待发布”变成没有定义的状态。流程版本不是发布系统的内部细节，而是业务记录的一部分。

5.4.3 退款：不可逆副作用和最终收敛

退款流程一般包括申请、资格校验、金额计算、风控/人工审核、渠道受理、到账确认、权益回补和账务记账。它和订单取消的区别在于：资金渠道的受理和到账可能是两个事实，优惠回补和库存恢复也不一定与资金动作同时完成。

退款单应拥有独立的生命周期，例如 REQUESTED、UNDER_REVIEW、SUBMITTED_TO_CHANNEL、CHANNEL_UNKNOWN、REFUNDED、FAILED_NEEDS_REVIEW。SUBMITTED_TO_CHANNEL 不是 REFUNDED，因为渠道受理成功并不代表资金已入账。超时后应先查渠道，以退款单号、外部请求号和金额确认结果；只有在确认失败时才允许重新提交，重新提交仍必须使用同一业务幂等键或渠道幂等标识。

当退款成功而优惠回补失败，流程不能回滚资金，也不能把退款单标成失败。更合理的做法是保持资金事实为已退款，单独创建权益回补任务，并在对账表中记录“资金已完成、权益待收敛”。这正是长流程和大事务组合的典型边界：不可逆节点完成后，后续动作必须围绕已发生事实向前恢复或人工治理，而不是假装可以恢复世界原状。[11][12]

三个案例的共同模型是：对象有稳定 ID，状态迁移有守卫，等待有截止时间，外部副作用有请求号，人工动作有权限和审计，失败后有查询、补偿、对账或人工出口。不同之处只是权威事实、不可逆节点和允许的终态不同。方法论应抽取共同结构，不应把“订单状态”“商品状态”“退款状态”硬塞进一套没有领域含义的通用枚举。

5.5 参考架构与实现路线

5.5.1 共同架构：事实、执行和投影分离

无论使用何种工具，长流程都可以拆成四个职责：

1. 事实层：拥有业务对象和状态迁移的权威服务，负责不变量、权限和本地事务。
2. 执行层：保存待执行步骤、重试、等待、定时器、人工任务和流程实例进度。
3. 传播层：通过 Outbox、消息或事件日志，把已提交事实可靠地传给下游。
4. 治理层：提供查询、审计、告警、对账、人工接管、版本迁移和操作保护。

四层可以部署在一个应用里，也可以由多个平台承载。关键是不要把职责混在一起：消息总线只负责传输，不拥有业务状态；Workflow 引擎可以持久化等待和执行历史，但不应在没有领域校验的情况下成为订单金额、库存数量或退款结果的唯一事实源；读模型可以为了查询方便折叠多个事件，但不能反向覆盖权威事实。

5.5.2 四种实现路线

路线一：数据库状态机。 把生命周期状态、版本、原因和下一次动作放在业务表或流程表中，由应用服务按照允许迁移表推进。它简单、贴近业务、查询直接，适合阶段有限、等待少、主控方明确的流程。缺点是超时、人工任务、重放、版本迁移和全局观察需要自己建设，状态逻辑容易散落到多个服务。

路线二：应用层编排器。 引入一个专门的 Orchestrator 保存主流程和步骤账本，业务服务只负责完成节点动作并返回结果。它适合订单履约、退款执行、发布编排等主控方明确的场景，可以集中处理超时、通知、重试、补偿和查询。代价是编排器本身成为关键系统，必须解决持久化、高可用、幂等、并发、版本和人工接管，否则只是把散落的条件分支搬到一个更大的服务里。Seata 的中文文档把 Saga 描述为长事务解决方案，把 TCC 描述为需要业务方显式实现 Try、Confirm、Cancel 的侵入式方案，这正好说明“分布式事务模式”和“长生命周期流程运行时”仍是两个层次的问题。[14][15][16]

路线三：Workflow 引擎。 把流程状态持久化、长时间等待、定时器、任务队列、重试、历史和人工任务交给专门平台。Temporal 把长时间运行的 Workflow 作为 Durable Execution，强调进程、网络或基础设施故障后可以从持久化历史继续执行。[4] BPMN 类平台则更偏向流程定义、任务和组织协作。Workflow 能减少自研运行时的重复工作，但不能自动解决领域事实、权限、不变量、补偿语义和流程版本迁移。引入它意味着团队要学习新的编程模型、部署模型、可观测模型和升级纪律。

路线四：事件驱动协作。 各领域服务发布事件，由订阅者继续推进自己的局部流程。它适合多团队自治、边界清晰、中心主控方弱的系统。优点是解耦和扩展自然，缺点是全局进度、跨领域审计、人工介入和异常排查更难。事件驱动不等于没有编排，只是把编排责任分散了；当流程需要回答“整体现在是什么状态”时，仍然要建立流程视图或显式协调边界。

5.5.3 ADR：一个订单履约流程的选择

可以用下面的 ADR 方式记录选择，而不是只写“推荐上 Workflow”。

背景与问题：订单支付、库存预占、履约单创建、物流和售后分属不同服务；订单需要跨天运行，支付回调可能重复或迟到，客服需要查询和人工接管。

决策驱动因素：订单域必须保有主状态权威；支付和库存动作需要幂等；支付等待不能占用线程；超时、补偿、人工任务和审计要统一可见；历史订单不能因为流程代码发布而失去解释能力。

候选方案：继续由订单服务中的定时任务和条件分支推进；使用独立应用编排器；使用通用 Workflow 引擎；完全采用事件驱动，各服务自行推进。

最终决策：订单域保留业务状态和迁移规则，先使用持久化编排器承载支付等待、履约创建、超时和补偿；节点内仍使用本地事务、Outbox 和幂等消费者。待人工任务、流程版本、重放和跨租户治理反复出现后，再评估是否迁移到 Workflow 平台。

获得的能力：主流程可查询、等待不占线程、步骤可重试、补偿有账本、人工有入口、指标可以按流程 ID 关联。

主动牺牲的能力：不追求跨所有参与方的全局原子提交；允许投影短暂延迟；在外部结果未知时允许处理中状态；编排器需要额外的高可用和运维成本。

已接受的风险：编排器可能成为主流程瓶颈；事件和命令可能重复；补偿不一定恢复历史原状；旧流程定义需要长期保留。

验证指标：在途实例 P99 停留时长、超时比例、未知结果存留时间、补偿成功率、人工任务逾期量、重复命令正确吸收率、对账差异数量和恢复平均时长。

重新评估条件：流程定义超过团队可维护范围；多个业务都需要相同的定时器、待办、重放和审计能力；编排器发布已经成为跨团队协调瓶颈；历史实例迁移成为主要事故来源。

5.6 等待、定时器、外部事件与人工任务

5.6.1 持久化等待不是阻塞线程

长流程的本质不是让线程一直等待，而是把等待条件持久化，在条件满足时重新唤醒。每个等待点都应回答：等的是什么、由谁唤醒、最长等多久、超时后怎么办、重复唤醒是否安全。

等待记录至少保存 wait_id、流程 ID、等待类型、关联键、截止时间、唤醒版本、最近一次尝试和超时策略。调度器投递的是“到期意图”，不是直接改业务状态。例如，调度器只发送 ExpirePaymentWindow(order_id, timer_id)；订单状态机收到后仍需检查订单是否还处于 PENDING_PAYMENT、定时器是否属于当前流程版本、是否已经收到支付事实。这样即使调度器重复投递、延迟投递或执行多个实例，也不会绕过状态规则。

仅靠每天扫描数据库的 Cron 容易出现扫描延迟、重复触发和范围不可控。更稳妥的做法是按截止时间建立可查询的任务索引，允许提前唤醒、批量领取和租约续期，同时保留一个低频全量扫描用于修复调度遗漏。定时器系统本身也需要幂等键、租约、重试上限和死信入口，不能因为“只是定时任务”就没有审计。

5.6.2 外部事件必须经过验证和去重

重复支付回调、迟到物流事件、供应商重发通知和顺序颠倒的状态消息都是正常输入。处理外部事件时至少验证：

1. 事件是否关联到正确的业务主键和流程实例。
2. 来源是否可信，签名、租户和权限是否通过验证。
3. 外部事件 ID 是否已经处理，事件版本是否早于当前版本。
4. 金额、数量、币种、状态和时间窗口是否符合业务约束。
5. 当前状态是否允许接受该事实，还是应查询权威系统或进入人工队列。

消息系统常见的是至少一次投递，消费者必须让重复处理的结果与处理一次相同。Idempotent Consumer 模式建议在数据库事务中记录已处理消息 ID，利用唯一约束吸收重复消息。[9] RocketMQ 中文文档也明确提醒，消息系统不能代替业务层去重；业务对重复消费敏感时必须建立业务幂等处理。[18]

对于可能乱序的事件，不能按“最后收到的消息覆盖当前状态”。可以使用聚合版本、外部单据版本、单调序列、事件发生时间和领域规则组合判断。无法判断时，宁可保持处理中并查询权威来源，也不要用猜测把流程推进到不可逆状态。事件消费成功只表示当前消费者完成了自己的处理，不表示整个长流程完成。

5.6.3 人工任务是正式节点，不是黑箱兜底

审批、驳回、人工补单和客服裁决经常被当成“自动化失败后的兜底”。实际上，很多业务本来就需要人工判断。把人工节点正式建模，才能解决权限越权、任务丢失、责任不清和人工操作后流程停滞。

一个可治理的人工任务至少包含：所属流程实例、当前阶段、候选角色或人员、对象范围、可执行动作、截止时间、升级规则、处理结果、理由、证据链接和关联规则版本。动作必须受状态机约束。审核员可以“通过、驳回、要求补件”，但不能直接把商品从草稿改成已发布；客服可以申请人工关闭订单，但高金额订单可能还需要风控或财务二次批准。

权限不能只看角色，还要看对象范围和风险阈值：谁能处理哪个商家、哪个地区、哪种商品；金额超过阈值是否必须双人复核；发起人是否不能审批自己的申请；紧急操作是否需要事后复核。每次人工动作都记录操作者、时间、前后状态、理由、规则版本和附件哈希。审计记录不是为了事故后追责才保留，它还是后续恢复自动化的输入：系统必须知道人工做了什么例外决定，才能继续执行或避免重复执行。

人工任务完成后，流程不应依赖运营人员再去“点一下继续”。系统应把处理结果转换成正式命令或事件，按既定规则进入下一阶段。如果人工选择“确认外部已成功”，这个动作也应该触发受控的事实确认和审计，而不是直接写入“成功”字段。高风险动作可以把人工任务分成申请、审批、执行、验证四个步骤，使执行者不能同时批准自己的操作。

5.6.4 Outbox 和局部大事务放在节点内部

长流程的一个节点内部，往往还会嵌套大事务。例如订单的“支付确认后创建履约单”，商品的“发布主数据并发送索引事件”，退款的“写入退款单并通知账务”。节点内部要保证业务事实和待发送事件的本地原子性，跨服务部分由编排、消息、补偿和对账负责。

Transactional Outbox 的基本做法是把业务更新和待发送事件写在同一个本地事务中，再由 relay 投递消息；它避免数据库提交和消息发送之间的双写窗口，但 relay 可能在发送成功后、记录已发送前崩溃，因而消费者仍必须幂等。[6][8] 这也是为什么 Outbox 不是全局事务，也不是流程引擎；它只解决一个本地事实与事件传播边界。

如果业务使用 RocketMQ 事务消息，也要区分本地事务提交与下游消费完成。官方中文文档把事务消息定义为最终一致性，并说明下游消费结果不由生产端事务自动保证。[17] 因此，上游流程仍需要消费幂等、失败重试、死信、查询和对账。不同实现路线都不能把“消息发送成功”误写成“所有参与方已经完成”。

5.7 故障、恢复、重放与流程演进

5.7.1 先分类故障，再决定动作

长流程不能把所有错误都交给同一个重试器。至少应区分以下故障：

AWS 的 Saga 指南把失败路径分成向前恢复和向后补偿：基础设施暂时失败时可以重试并继续，业务拒绝时才根据业务语义执行补偿。[5] Microsoft 的补偿事务模式也强调，补偿动作不一定按原步骤的严格逆序执行，且不一定能把系统恢复到原始状态；补偿顺序和动作要由业务规则决定。[11][12] 因此，“失败就回滚”不是长流程的通用答案。

5.7.2 结果未知必须先查，不要盲目重做

结果未知是长流程最危险的中间态。调用支付、退款、库存预占或供应商下单时，客户端可能在请求到达后丢失响应。此时“没有响应”只说明调用方没有证据，不说明服务端没有执行。

处理结果未知时，恢复顺序应尽量是：

1. 使用原始业务幂等键、外部请求号或资源 ID查询权威系统。
2. 如果查询接口暂时不可用，记录下一次查询时间，不改变业务事实。
3. 多次查询仍不能确定时，进入对账或人工复核，冻结会造成重复副作用的后续动作。
4. 只有确认原动作未生效或业务规则允许安全重试时，才发起同一幂等意图的重试。
5. 查询结果确认后，再推进状态机，并把证据写入流程历史。

这样，流程的重试目标不是“重新执行一遍代码”，而是“让原有业务意图获得一个可解释结果”。AWS Builders’ Library 对此给出的工程经验是：客户端提供唯一请求标识，服务端把标识与请求参数和资源创建结果绑定，重试时返回语义等价结果。[7] 这比只在客户端加一个重试循环可靠得多。

5.7.3 恢复、补偿和对账要形成闭环

在线流程负责尽快推进，但它不能承担所有修复工作。独立的对账任务应周期性比较多组事实：订单与支付、订单与库存、退款单与渠道、商品主数据与搜索投影、流程实例与步骤账本。每个差异都进入统一的差异状态机，例如 DETECTED -> CLASSIFIED -> AUTO_REPAIRING -> VERIFIED -> CLOSED，或转入 MANUAL_REVIEW。

对账记录应至少包含业务主键、差异类型、权威来源、发现时间、影响范围、当前 owner、建议动作、尝试次数、下一次处理时间、验证证据和规则版本。自动补偿必须先查询事实，再执行最小必要动作，动作完成后重新查询并写回证据。金额不一致、身份不明或不可逆副作用不应由无限自动化处理，而应暂停并要求人工审批。

可观测性应从流程 ID贯穿到命令、事件、外部请求和人工任务。日志和指标至少关联：

process_id
business_id / order_id
command_id / idempotency_key
event_id / event_version
external_request_id
process_definition_version

重点关注在途实例数量、各状态年龄、最老等待时间、重试次数、未知结果时长、补偿队列年龄、人工任务逾期量、版本冲突和对账差异，而不是只看某个 RPC 的成功率。中国信通院的稳定性建设指南强调要把稳定性目标落到评价指标和治理路径上；在长流程里，最有价值的告警应能直接回答“哪一类业务对象、卡在哪个步骤、影响什么、谁负责下一步”。[20]

5.7.4 事件重放不等于命令重做

事件重放常用于重建读模型、补发通知、修复审计视图或验证迁移结果。它要求事件有稳定 ID、顺序/版本和明确语义，消费者必须幂等。重放事件只应重新计算安全的投影，不应默认再次扣款、发货、退款或发送不可撤回通知。

如果确实需要重新执行会产生外部副作用的命令，必须建立独立的重放策略：指定批次、审批人、作用域、幂等键、速率上限、暂停开关和验证步骤。重放命令不能复用普通在线入口，否则一次修复操作可能扩大事故。对含有隐私、敏感信息或已撤回权限的数据，还要考虑历史事件的访问控制和脱敏边界。

事件溯源系统可以从事件重建状态，但仍需要处理事件版本和外部副作用；普通状态机也可以通过迁移日志提供审计。不要把“保留事件”直接等同于“可以安全重放全部业务”。重放能力的核心是可区分事实重建、投影修复、通知补发和副作用重做四种不同目标。

5.7.5 流程定义演进与存量实例迁移

流程运行数天、数月甚至更久时，代码一定会变化。流程定义应显式保存版本，新实例使用新版本，存量实例可以继续按旧版本完成，也可以在明确迁移规则和审计记录下转入新版本。迁移至少回答：

1. 哪些状态在两个版本之间一一对应？
2. 新版本新增的审批或校验，对存量实例是补做、豁免还是人工确认？
3. 已经完成的不可逆动作是否还能被新版本重新解释？
4. 迁移失败时是回到旧版本、冻结实例，还是进入人工队列？
5. 新旧版本的指标和告警如何区分，何时可以停止旧版本 worker？

例如商品发布流程从“一次人工审核”升级为“质检 + 合规双审核”，最安全的做法通常是：新提交实例使用版本 2；已完成质检但尚未发布的旧实例继续按版本 1 完成，或者为它们创建一个明确的合规补审迁移任务；已发布商品不因流程定义升级而重新执行发布副作用。流程迁移是业务变更，不是普通代码重构，必须有灰度、暂停、回滚边界和审计记录。

5.8 方案选型与实施路径

5.8.1 选型顺序：先模型，再运行时

可以用下面的顺序避免“先买平台、再找场景”：

1. 定义流程对象、权威事实和主状态。
2. 列出命令、事件、守卫条件和不变量。
3. 标记等待点、人工节点、不可逆节点和超时策略。
4. 识别每个关键节点内部的大事务、Outbox、补偿和查询接口。
5. 根据流程复杂度选择数据库状态机、编排器、Workflow 或事件协作。
6. 设计查询、审计、告警、对账、人工接管和流程版本策略。
7. 用一个正常案例、两个失败案例和一个版本升级案例验证方案。

选择工具之前先画“事实图”和“状态图”，再画“执行图”。事实图说明谁拥有订单、库存、支付和退款的权威；状态图说明允许哪些迁移；执行图说明命令如何投递、等待如何唤醒、失败如何恢复。很多 Workflow 项目失败，不是因为引擎不能调度任务，而是因为团队把执行图误当成事实图，让任务完成状态替代了业务完成状态。

5.8.2 渐进式实施路线

阶段一：本地事务 + 持久化状态。 适用于阶段少、等待少、主控方明确的流程。先建立稳定业务 ID、状态迁移表、版本号、幂等键和迁移日志；不要直接允许任意 SQL 修改状态。

阶段二：状态机 + 调度和补偿任务。 出现支付超时、外部回调、异步通知或资源释放时，增加 next_action_at、任务表、重试分类和对账入口。调度器只投递幂等命令，业务状态机负责最终判断。

阶段三：应用层编排器。 当步骤顺序、超时、补偿、人工接管和跨服务查询已经超过单个领域服务的可维护范围时，抽出独立编排器。编排器保存实例和步骤账本，参与方服务保持自己的事实和本地事务。

阶段四：Workflow 平台。 当多个业务反复需要长等待、人工任务、历史、重放、版本和统一治理时，评估引入 Workflow 引擎。迁移时先选一个低风险但真实的流程，验证持久化等待、故障恢复、worker 升级、观测和历史实例迁移，不要一开始就把所有核心流程搬过去。

阶段五：共享治理平台。 只有多个领域已经形成稳定共性，才抽象共享的任务、审计、调度、重试、人工操作台和差异队列。平台提供运行时能力，不把所有业务补偿规则硬编码成一个不可扩展的“万能流程引擎”。业务状态和权限仍由领域 owner 负责。

5.8.3 方案能力与代价对比

四种路线都不能自动提供业务正确性。数据库状态机可能写出非法跳转，编排器可能重复调用，Workflow 可能执行了错误的流程定义，事件驱动系统可能接受乱序消息。真正的生产能力来自“权威事实 + 可验证状态迁移 + 幂等执行 + 可恢复等待 + 受控人工 + 对账”，而不是组件名称。

5.9 评审清单与方法论总结

5.9.1 流程设计评审清单

在进入实现前，至少逐项回答：

1. 流程对象是什么？业务主键、流程 ID、主状态、子状态和原因字段分别是什么？
2. 哪个服务拥有权威事实？Workflow、消息总线和读模型分别不拥有哪类事实？
3. 每一条状态迁移由什么命令或事件触发？谁有权限发起？守卫条件和不变量是什么？
4. 同一对象上的支付、取消、超时、人工操作和重放如何并发？版本冲突如何处理？
5. 哪些节点需要等待？等待条件、截止时间、唤醒方式、重复唤醒和超时策略是什么？
6. 外部事件如何验证来源、金额、版本、时间窗口和重复处理？乱序消息如何收敛？
7. 哪些节点内部存在第 4 章的大事务？失败、结果未知和补偿失败如何反馈给主流程？
8. 哪些动作不可逆？不可逆节点之前有哪些校验，之后如何向前恢复或人工治理？
9. 人工任务的角色、对象范围、可执行动作、升级规则、双人复核和证据要求是什么？
10. 对账比较哪些事实？差异如何分类、修复、验证和关闭？谁是 owner？
11. 事件重放与命令重做如何区分？哪些副作用禁止自动重放？
12. 流程定义如何版本化？存量实例如何完成、迁移、冻结和回滚？
13. 指标能否发现超时、停滞、未知结果、重复命令、人工积压和版本冲突？告警是否直接连接到责任人和下一动作？

5.9.2 常见反模式

• 先选框架再定义状态：让引擎的任务模型反过来决定业务语义，最终状态不可解释、升级难迁移。
• 把长流程写成超大事务：为了等待外部系统而持有长锁或长 RPC，既牺牲可用性，也无法覆盖外部副作用。
• 把重试当幂等：重复请求会重复扣款、重复创建资源或重复发放权益，事后再靠人工修复。
• 把超时当未执行：响应丢失后直接重做，没有查单、幂等键和结果未知状态。
• 把消息发送成功当业务完成：消息只代表传播动作完成，下游消费、状态迁移和最终业务结果仍需验证。
• 把 Outbox 当全局事务：Outbox 只解决本地数据库和事件发送之间的双写窗口，不能替代消费者幂等、补偿和对账。
• 把人工改库当恢复机制：短期绕过一个问题，长期破坏状态机、审计链、版本控制和后续对账。
• 把事件重放当命令重做：修复读模型时意外重复退款、发货、通知或调用不可逆外部接口。
• 所有领域共用一个万能状态机：表面统一，实际上把订单、商品、退款的权威事实和不变量混在一起。

5.9.3 方法论总结

长生命周期业务流程可以沿八个问题展开：先定义流程对象和生命周期边界；明确时间、角色、依赖、可逆性、数据新鲜度和审计约束；建立状态、命令、事件、版本、守卫条件和不变量；把关键节点内部的大事务与流程级等待分开；选择状态机、编排器、Workflow 或事件协作时写清获得、牺牲、风险和验证指标；通过订单、商品、退款等完整案例走通正常、异常、人工和最终收敛；最后用幂等、查询、补偿、对账、重放隔离和版本迁移治理变化。

最关键的判断始终不变：不要把“接口调用成功”误当成“业务对象已经完成”。业务完成应该意味着权威事实已经满足目标，必要的副作用已经确认、补偿或进入明确的待治理状态；所有尚未完成的部分都有 owner、下一动作和截止时间。流程状态不是 UI 标签，而是可以被系统、人员和审计共同理解的业务事实。

第 4 章的大事务保证关键节点内部副作用正确，第 5 章的生命周期模型保证对象跨阶段可治理，第 6 章的任务处理方法论保证可执行工作可以暂停、分片和恢复，第 7 章则进一步讨论高准确性和强一致性场景的边界。四者组合起来，系统才不只是“主路径能跑通”，而是能在等待、重试、乱序、规则变化和人员接管之后继续工作。

如果一个团队只能记住一句话，可以记住：

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

参考资料

正文中的编号用于就近说明来源支撑的事实或方法；带有“本章推导”的内容，是结合订单、商品和退款场景作出的工程判断。

[1] Hector Garcia-Molina, Kenneth Salem, “Sagas”, Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data, 1987. ACM Digital Library.

[2] Pat Helland, “Life beyond Distributed Transactions: an Apostate’s Opinion”, CIDR 2007, 2007. CIDR paper.

[3] Object Management Group, Business Process Model and Notation (BPMN), Version 2.0.2, 2014. OMG specification.

[4] Temporal, “Temporal Platform Documentation”, Temporal Documentation，访问日期：2026-09-21。

[5] AWS Prescriptive Guidance, “Saga patterns”, AWS Prescriptive Guidance，访问日期：2026-09-21。

[6] AWS Prescriptive Guidance, “Transactional outbox pattern”, AWS Prescriptive Guidance，访问日期：2026-09-21。

[7] Malcolm Featonby, “Making retries safe with idempotent APIs”, Amazon Builders’ Library, 2021. Amazon Builders’ Library。

[8] Chris Richardson, “Pattern: Transactional outbox”, Microservices Patterns, microservices.io，访问日期：2026-09-21。

[9] Chris Richardson, “Pattern: Idempotent Consumer”, Microservices Patterns, microservices.io，访问日期：2026-09-21。

[10] Martin Fowler, “Event Sourcing”, 2005. martinfowler.com.

[11] Microsoft, “Compensating Transaction Pattern”, Azure Architecture Center, Microsoft Learn，访问日期：2026-09-21。

[12] Microsoft，〈补偿事务模式〉，《Azure Architecture Center》，Microsoft Learn 中文，访问日期：2026-09-21。

[13] Microsoft，〈Saga 模式〉，《Azure Architecture Center》，Microsoft Learn 中文，访问日期：2026-09-21。

[14] Apache Seata，〈Seata 是什么？〉，Apache Seata v2.6，Apache Seata 中文文档，访问日期：2026-09-21。

[15] Apache Seata，〈Seata TCC 模式〉，Apache Seata 中文文档，访问日期：2026-09-21。

[16] Apache Seata，〈Seata Saga 模式〉，Apache Seata 中文文档，访问日期：2026-09-21。

[17] Apache RocketMQ，〈事务消息〉，Apache RocketMQ 中文文档，访问日期：2026-09-21。

[18] Apache RocketMQ，〈基本最佳实践〉，Apache RocketMQ 中文文档，访问日期：2026-09-21。

[19] 周志明，〈分布式事务〉，《凤凰架构：构建可靠的大型分布式系统》，2021。凤凰架构在线章节。

[20] 中国信息通信研究院云计算与大数据研究所，《分布式系统稳定性建设指南（2022年）》，2022。中国信通院官方 PDF。

第 6 章 任务处理方法论：从短任务、长任务到可恢复的 Workflow 与 Agent 协作

任务处理解决的不是某个业务对象如何流转，而是一段工作如何被拆分、调度、执行、暂停、恢复和治理。本章以供应商数据同步为主案例，结合离线计算、流处理和 Agent 协作，建立同步请求、异步消息、Batch / 分布式 Job、Workflow、Stateful Agent Runtime 与 Multi-Agent 的统一选型框架。

前面的章节分别讨论了关键业务动作的一致性，以及业务对象跨阶段的生命周期。本章处理第三类问题：一个可执行任务如何可靠跑完，或者如何在没有一次性“跑完”的情况下持续保持正确。扫描超时订单、生成日报、同步供应商库存、重建索引、执行历史数据修复、训练模型、运行 Spark 作业，以及让代码 Agent 修改多个文件，都需要明确执行边界、进度记录和恢复机制。

从表面看，这些任务的技术栈差异很大：有的使用 HTTP，有的使用消息队列，有的运行在 Kubernetes Job 或数据计算集群上，有的由 Workflow 引擎驱动，有的还需要大模型选择工具和调整路径。但它们共享一个事实：任务一旦跨越请求、进程、时间、步骤、系统或角色边界，就不能再把调用栈当作唯一状态，也不能把“进程退出”当作完成证明。

本章不把某个框架当成答案，而是先回答五个问题：任务的输入和成功判据是什么？中断后从哪里继续？重复执行会不会产生额外副作用？谁拥有最终事实？自动路径什么时候必须暂停并交给人或另一种执行单元？这些问题回答清楚后，方案才有可能从同步请求逐步演进为异步任务、Batch、Workflow 或 Agent Runtime，而不是在故障发生后被动堆叠重试队列和运维脚本。

6.1 问题定义：任务为什么会失控

6.1.1 短任务与长任务的区别不在耗时

许多团队用“几秒以内是短任务、超过几分钟是长任务”来划分任务。这种经验可以作为容量讨论的线索，却不是架构边界。真正重要的是任务是否需要跨边界持续推进。

这里的边界包括：

• 请求边界：调用方收到响应后，工作是否还要继续。
• 进程边界：执行进程重启后，是否能从外部状态恢复，而不是依赖内存。
• 时间边界：任务是否可能等待分钟、小时、天甚至更长时间。
• 步骤边界：任务是否包含多个有不同失败语义的阶段。
• 系统边界：任务是否调用外部 API、数据库、计算集群或人工服务。
• 角色边界：任务是否需要审批、复核、转派或人工确认。

一个耗时两秒但会产生不可逆外部副作用的付款请求，仍然需要幂等和结果未知处理；一个运行一小时但完全可重算、无副作用的离线计算，也许只需要 Batch 和分片。相反，一个只运行十秒的代码 Agent，如果需要修改文件、执行测试、等待用户确认后继续，就已经具有长任务的状态与治理特征。

因此，本章使用如下定义：短任务是可以在一次执行上下文中完成，并且失败后可以安全地整体重试的工作；长任务是必须跨越至少一个执行边界，且需要把进度、等待、恢复或人工决策持久化的工作。这个定义比固定时长更能解释为什么同一个接口在业务规模增长后会突然需要 Run、Checkpoint 和操作台。

6.1.2 典型错误：把执行问题误认为组件问题

任务最初往往只是一个函数、一个 Cron 或一条消息消费逻辑。数据量小、依赖稳定时，这种实现能够工作；一旦执行时间变长、对象数量变多或外部依赖开始抖动，问题会以相似的方式出现：

• 同步请求一直不返回，线程、连接和客户端重试被长期占用。
• 一个 Consumer 同时完成拉取、转换、发布、通知和补偿，失败后无法判断应从哪里恢复。
• 全量任务中途失败，只能从头执行，重复写入和重复调用不断累积。
• 任务状态散落在日志、队列和开发者记忆中，值班人员无法判断它是否仍在推进。
• 下游限流或主库繁忙时，重试反而放大流量，最后影响正常业务。Google SRE 将这种正反馈称为级联故障，并特别强调重试、队列和资源耗尽之间的相互放大关系。[2][3]

这些问题不能只靠“把消费者扩容”“换成更快的数据库”或“再加一个重试次数”解决。一个任务系统需要把意图、执行事实、执行结果、失败原因和下一步动作分开记录。消息队列可以负责把工作交给 Worker，却不能替代任务状态；日志可以解释发生了什么，却不能作为可靠的恢复点；模型输出可以帮助 Agent 做判断，却不能自动获得生产副作用的权限。

6.1.3 典型长任务场景

旧版本中被删减的场景仍然有助于建立方法的覆盖范围。它们可以归纳为五类：

供应商同步是本章的主案例。模型训练和 Spark 任务说明 Batch 的边界不只存在于业务中台；Flink 的有状态处理则说明“长”也可以意味着作业长期运行，而不是一次执行很久。Apache Spark 以可容错的 RDD 和血缘重算来处理节点故障，Flink 则通过状态快照和 Checkpoint 恢复有状态算子；两者都说明恢复能力必须建立在明确的中间事实之上，而不是依赖某个 Worker 恰好没有重启。[9][10]

Agent 场景又增加了一层复杂度。代码 Agent 可能要理解需求、扫描仓库、规划修改、调用编辑工具、运行测试、读取失败输出，再决定返工；调研 Agent 可能并行检索资料、去重、交叉验证并由 Reviewer 收敛结论；运维 Agent 可能需要查询日志、诊断指标、生成变更计划，等待人工批准后再执行。它们的共同点不是“用了大模型”，而是执行路径包含不确定性，同时仍然需要传统任务系统的状态、权限、审计和恢复骨架。

6.1.4 本章的范围与非目标

本章聚焦以下问题：

1. 如何识别任务的执行跨度、数据规模、流程确定性、认知复杂度和副作用风险。
2. 如何选择同步请求、异步消息、Batch、Workflow、单 Agent、Stateful Agent Runtime 或 Multi-Agent。
3. 如何设计 Task、Run、Step、Shard、Checkpoint、Lease、状态历史和结果账本。
4. 如何处理重复投递、结果未知、局部失败、限流、背压、乱序、发布异常和人工接管。

本章不展开某个具体 Workflow 或 Agent 框架的 API，也不把模型提示词写作当作任务治理。第 4 章深入 Saga、Outbox、补偿和最终一致性；第 5 章深入业务对象的长生命周期状态机；本章只在这些主题交界处保留任务执行所必需的契约，并把 Agent 当成一种可能的执行单元，而不是一种可以替代业务事实的万能架构。

6.2 约束与指标：先明确什么算“跑得对”

6.2.1 用复杂度画像代替技术名词

任务选型前，建议先为任务建立一张复杂度画像。至少记录以下九个维度：

这九个维度不需要一开始都量化成精确分数，但必须写出证据和假设。例如“每天同步五千万对象”是规模假设；“供应商每分钟最多 600 次调用”是外部约束；“价格波动超过上一版本 30% 必须人工确认”是业务门禁。容量数字如果只是方案假设，要明确标记，运行后的实际吞吐、P99、队列长度和最老任务年龄再用于校正。[1]

6.2.2 成功不能只有一个布尔值

长任务至少要区分四种成功：

• 受理成功：任务定义、输入范围和权限检查通过，Run 已创建。
• 执行成功：Worker 已完成某个 Step 或 Shard，并把结果与状态一起落地。
• 业务成功：输出满足业务质量门槛，正式版本已经发布或业务对象已收敛。
• 治理成功：所有失败、跳过、人工豁免和外部差异都有记录，后续责任边界清楚。

例如供应商同步接口返回 HTTP 202，只代表受理成功，不能让调用方把它展示为“库存已更新”；一个 Shard 的 Fetch 成功，也不意味着数据已经通过校验和发布；一次 Run 标记 SUCCEEDED，还应能解释隔离了多少坏数据、是否存在容忍范围内的差异，以及这些差异由谁负责处理。

指标应围绕这些层次建立：

6.2.3 Task、Run、Step、Shard 与 Checkpoint

无论最终使用脚本、消息队列、Kubernetes Job 还是 Workflow 引擎，都建议先持久化执行事实。一个通用模型包含五层：

Task 表达“要做什么”，Run 表达“这次究竟处理了什么”。Run 应保存输入范围、规则与配置版本、发起来源、开始时间、截止时间和最终摘要。不能用一个全局任务状态覆盖历史运行记录，否则无法区分今天正在执行的任务和昨天遗留的失败。

Step 的边界应按责任和失败语义划分，而不是按代码函数随意切分。供应商同步可以把 Fetch、Normalize、Validate、Publish 和 Reconcile 分开；Fetch 失败可以重试外部请求，Validate 失败可以隔离坏对象，Publish 失败则需要保护正式版本。阶段边界越清晰，恢复时越不需要重复已经验证过的工作。

Shard 是扩展性与故障隔离的核心。常见切法包括供应商 / 商家维度、ID 范围、时间窗口、分页游标和哈希桶。分片太大，失败恢复成本高；分片太小，调度开销、状态数量和数据库写入压力又会过大。一个好分片应能估算工作量、单独重试、追溯输入范围，并且不会因并行而破坏同一业务对象的顺序约束。

Checkpoint 必须在副作用与状态事实都落地后推进。正确顺序通常是：读取输入 → 执行幂等写入或生成暂存结果 → 保存输出摘要和版本 → 在同一事务或可验证协议中推进 Checkpoint。只把页码打印到日志，或在落库前更新游标，都不能安全恢复。

6.2.4 状态迁移与版本契约

Run 可以经历 PENDING、PLANNED、RUNNING、PAUSED、SUCCEEDED、FAILED、CANCELLED、MANUAL_REVIEW；Shard 可以经历 PENDING、RUNNING、RETRYABLE、UNKNOWN、SUCCEEDED、FAILED 和 CANCELLED。状态不是为了增加字段，而是为了避免把“已入队”误判成“已完成”，也避免把“一个分片失败”误判成“整次运行已经无价值”。

每次迁移都应携带原因、发生时间、操作者或执行器标识、关联错误、版本号和审计引用。状态历史最好追加保存，当前状态服务于调度，历史服务于审计、复盘和容量优化。任务定义、分片规则、质量阈值和发布策略发生变化时，新的 Run 必须固化配置版本；历史 Run 按创建时的版本解释，不能在重试时悄悄读取一份已经变化的全局配置。

6.3 参考架构：调度、执行、状态与观测如何协作

6.3.1 控制面与数据面分离

一个可演进的任务系统不必一开始就有独立平台，但职责需要清晰。可以把它分成控制面和数据面：

控制面：Trigger / Scheduler / Policy / Operator Console
  -> 创建 Run、生成分片、检查配额、暂停或取消
  -> 读取状态、批准发布、触发受控重试

数据面：Queue / Dispatcher / Worker Pool / External Systems
  -> 领取 Shard、调用依赖、生成结果、提交 Checkpoint
  -> 执行幂等写入、返回错误和心跳

事实层：State Store / Object Ledger / Input Snapshot / Audit Trail
  -> 保存 Run、Step、Shard、版本、错误、外部请求号和人工动作

观测层：Metrics / Logs / Traces / Alerts / Reconciliation
  -> 解释推进速度、积压、失败原因、版本差异和恢复时间

调度器只负责创建运行实例、规划分片和发出可执行意图，不应在内存里长时间循环处理全部数据。Worker 只负责领取可执行分片、在租约内完成工作、持久化结果并续租或释放，不应自行猜测全局进度。状态存储保存权威的运行事实；消息队列负责分发，不应成为唯一状态来源。Airflow 的 DAG 与 Task 模型也强调，DAG 负责依赖、重试和时间控制，Task 才是实际执行单元；这正是控制面与数据面分工的一个具体例子。[8] DolphinScheduler 的官方项目资料同样把 DAG 编排、Worker 隔离、暂停恢复和批量回填作为调度平台能力，说明调度平台负责执行治理，业务任务仍要自己定义输入、结果和幂等边界。[18]

6.3.2 可靠交接：意图、消息与状态同时可追踪

如果请求需要异步交接，建议先在本地事务中写入 Run 意图，再写入 Outbox 事件，由 Relay 投递到队列。这样可以避免“数据库已创建任务但消息没发出”或“消息先发出但任务记录不存在”的断裂。Transactional Outbox 只解决本地业务事实与事件之间的双写窗口，Relay 仍可能在发送成功、更新投递状态前崩溃，因此消费者必须按事件 ID 或业务幂等键吸收重复。[5][6] 如果一个 Step 还要协调多个业务服务，则应把每个服务的本地事实和补偿边界显式记录，不能把 Outbox 误当成跨服务全局事务；Saga 的价值正在于把长事务拆为本地事务，并为已完成步骤定义业务补偿。[4]

消息契约至少应有 event_id、task_id、run_id、step_id、shard_id、业务主键、幂等键、输入版本、发生时间和过期时间。对于大对象，消息只保存对象存储引用与校验和；不能把可能无限增长的输入和上下文直接塞进队列。消费者确认成功的条件也要写清楚：是完成一次外部调用，还是完成本地事务、写入结果和推进 Checkpoint？如果只是调用成功但状态未落地，重新投递仍是正常路径。

6.3.3 Lease、心跳与重新领取

Worker 领取 Shard 时写入 owner_id、lease_until、attempt 和 heartbeat_at。在租约内，Worker 可以续租；进程崩溃或网络隔离后，租约到期，调度器将 Shard 标记为可恢复并重新投递。租约不是锁住整个任务的长期数据库事务，而是一种“当前执行者暂时负责推进”的可过期声明。

重新领取意味着执行至少可能一次，所以必须配合幂等和版本校验。一个 Worker 可能已经完成外部副作用，却在写成功状态前失联；另一个 Worker 随后重新执行。如果下游有稳定幂等键，可以查询并吸收这次重复；如果没有查询能力，就必须把结果标为 UNKNOWN，进入对账或人工队列。把“租约过期”直接等价为“前一次一定没有执行”是危险的。

6.3.4 查询、管理和数据接口

任务系统通常需要三类接口：提交接口、查询接口和管理接口。提交接口返回 run_id、受理状态和查询地址；查询接口返回 Run、Step、Shard 的进度、最近错误、下一次动作和是否需要人工处理；管理接口支持暂停、取消、恢复、范围重试、跳过和回滚，但每个动作都要受权限、状态机和审计约束。

对外暴露的状态不能只返回 success / failed。至少要区分 ACCEPTED、RUNNING、PARTIAL_FAILURE、SUCCEEDED、FAILED、PAUSED、CANCELLED 和 MANUAL_REVIEW。调用方得到的是受理结果，还是业务完成结果，必须在接口命名、字段和文档中明确，否则任务系统会把后端的异步不确定性转化成前端的错误承诺。

6.4 方案谱系与选型框架

6.4.1 七种主流执行方案

从简单到复杂，可以把常见方案归纳为七类。它们不是互斥的产品，而是对应不同主导矛盾的执行形态。

选择顺序不应从“要不要用 Kafka、Airflow 或 Agent”开始，而应从复杂度来源开始：先看是否跨边界，再看是否要批量恢复，再看是否需要阶段治理，最后才看是否需要动态推理和角色协作。Anthropic 对 Workflow 与 Agent 的区分也采用了类似原则：预定义代码路径适合可预测流程，模型动态决定过程和工具使用时才进入 Agent 语境；即使使用 Agent，也应从最简单、可组合的结构开始。[14]

6.4.2 同步、异步与 Batch 的边界

同步请求适合校验、查询、单次规则计算和小范围写入。它的价值是及时给出确定结果，而不是把所有工作都放在请求线程里。一旦执行时长不可预测、需要大量 I/O 或调用方只需要“已受理”，就应建立异步交接边界。

异步消息适合一条消息可以独立完成的动作，例如发送通知、刷新单个商品索引或补写非关键投影。消息体需要携带事件 ID、幂等键、业务主键和输入版本，调用方得到的是 accepted，不是已完成。Consumer 如果开始拉取多个数据源、维护多个阶段、等待人工、发布正式版本，就已经超出单消息任务的边界。

Batch / 分布式 Job 适合全量同步、ETL、对账、索引重建、历史修复和训练任务。它的核心不是“后台慢慢跑”，而是把“处理全部对象”拆成可观察、可重试、可恢复的分片推进。Kubernetes Job 将一次性任务、并行完成计数和工作队列模式区分开，并允许挂起后恢复，这说明调度层的并行与业务层的对象状态仍然是两个需要分别建模的问题。[11]

6.4.3 Workflow、Agent Runtime 与 Multi-Agent 的边界

Workflow 适合阶段依赖、外部等待、审批门禁、发布保护和人工转派。它把执行路径显式写出来，让运行时负责持久化等待、超时、重试、回放和状态查询。Temporal 将 Workflow Execution 描述为可持久、可恢复的执行单位，并通过事件历史与重放恢复进度；这类能力正是长任务需要的执行骨架，但业务事实仍应由领域服务拥有。[7] 中文云工作流资料也把顺序、选择、并行、状态跟踪、错误重试和长时间执行列为工作流编排的核心能力；这些能力可以由平台提供，但不应替代业务状态和发布门禁。[17][19]

单 Agent 适合高认知密度、低到中等执行跨度的问题，例如一次性分析、轻量诊断、资料归纳和小范围代码解释。它不应直接获得无限工具权限，也不能因为输出了“完成”就被视为完成了副作用。Stateful Agent Runtime 则把 Goal、Plan、Step、Tool Call、Observation、Review、Budget 和 Checkpoint 变成正式事实，让 Agent 可以暂停、恢复、返工和等待人工。

Multi-Agent 不是“多几个模型一起聊天”，而是把规划、执行、审查、协调或领域专家角色拆开。只有当一个执行单元同时承担这些职责会产生明显冲突，并且角色分工可以用指标证明收益时，才值得引入它。AutoGen 的原始论文把多 Agent 对话描述为可组合的应用基础设施，同时也意味着需要显式定义角色、消息和交互行为，而不是把自然语言对话当作隐式协议。[15]

6.4.4 选型 ADR：记录获得与牺牲

以“供应商同步是否采用 Workflow + Batch”为例，ADR 不应只写“推荐使用某某框架”，而应记录：

ADR 的价值在于把“为什么现在选择它”与“未来什么条件下应重新选择”分开。它也迫使团队承认获得的能力与牺牲的能力必须用同一组维度比较，不能只说“可靠性更高”而不说明成本、延迟、复杂度和人工负担。[16]

6.4.5 一条渐进式升级路径

实践中可以沿着下面的路径渐进升级：

同步短任务
  -> 异步单元任务
  -> 分片并行 Batch
  -> 阶段化 Workflow
  -> 在局部步骤引入单 Agent
  -> Stateful Agent Runtime
  -> 有明确分工和终止条件的 Multi-Agent

这不是规定所有系统必须走完的路线。能用同步短任务解决，就不要先上 Workflow；能用 Batch 解决，就不要默认上 Agent Runtime；能用单 Agent 解决，就不要为了“更像 AI 系统”直接拆成 Multi-Agent。阿里云的工程实践也把单体函数、事件触发和 Workflow 编排区分为不同适用区间：流程长、需要状态持久化和自定义重试时，才有理由承担 Workflow 的编排成本。[20] 真正的升级信号应来自新出现的事实：请求被阻塞、局部失败无法恢复、阶段需要门禁、输入需要动态理解，或者一个执行单元已经不能兼顾规划、执行和审查。

6.5 完整案例：供应商数据同步如何设计

假设平台每天从供应商拉取酒店、房型、价格和库存。供应商接口按城市分页，存在限流、游标过期和字段缺失；同步结果必须经过质量校验后才能覆盖线上可售数据。这个案例同时包含大批量推进、外部不确定性、版本发布和人工治理，适合演示完整任务模型。

6.5.1 Plan：固化输入、规则和分片

调度器首先创建一条 Run，固化供应商、同步范围、输入快照时间、规则版本、发布目标、截止时间和操作者。随后根据城市、数据量和供应商配额生成 Shard。每个 Shard 记录起始游标、预计页数、优先级、最大重试次数和资源池。

Plan 阶段要验证三个不变量：分片不重叠，所有目标范围都被覆盖；规则版本和发布目标存在，不能中途从全局配置读取；输入快照和截止时间可解释，不能把不同时间采集的数据假装成同一批次。如果配置缺失、范围异常或上一次 Run 仍占用同一资源，应在真正拉取之前拒绝本次 Run。

6.5.2 Fetch：拉取与暂存分离

Worker 领取 Shard 后，以供应商配额为上限拉取分页数据。单次请求应有超时、请求号和稳定幂等键；如果游标失效，先判断供应商是否支持按对象版本或时间窗口重建游标，不能无条件从第一页开始制造重复流量。原始响应至少保留来源请求号、拉取时间、页码或游标、规则版本和快照引用，必要时保存压缩快照与校验和。

转换结果先写入暂存区，并用 run_id + shard_id + source_object_id 作为业务幂等键。暂存的目的不是多存一份数据，而是把“供应商返回了什么”“平台如何转换”“正式发布了什么”分开。重复拉取、分片重试和 Worker 重启都不能制造额外记录，也不能覆盖其他 Run 已确认的结果。

6.5.3 Normalize、Validate：对象级与批次级门禁

对象级校验检查必填字段、日期范围、币种、引用关系、数值上下限和来源版本。错误对象进入失败池，携带输入引用、错误分类、规则版本和推荐动作；对象级错误不一定阻塞全部城市。批次级校验则检查缺失比例、数据量突变、价格波动、库存变化、关键字段覆盖率和与上一有效版本的差异。

质量门禁应明确三种结果：通过，可以进入发布；可容忍，记录差异并在授权范围内继续；阻断，保留暂存版本并进入 MANUAL_REVIEW。门禁阈值不应被写成一个无法解释的常数。例如“价格下降 50%”可能对促销商品合理，对酒店库存则可能代表供应商接口异常；阈值必须带有业务范围、数据来源、版本和豁免理由。

6.5.4 Publish：版本切换而不是逐行污染线上数据

发布是数据任务最危险的一步。推荐将暂存结果写入候选版本，例如 supplier-A:v19，通过校验后再把城市或供应商的“当前有效版本”从 v18 原子切换到 v19。如果只能按城市发布，也要为每个城市保留上一有效版本、切换时间和回滚点。不要把暂存数据逐行更新到线上主表，否则中途失败会让用户同时看到一半新数据和一半旧数据。

发布前应执行权限和资源检查：本次 Run 是否有权影响可售数据，发布范围是否与 Plan 一致，是否有其他版本正在切换，是否超过单次影响半径。高风险发布可以按城市、租户或供应商分批灰度，并在每批之间检查错误率、查询延迟和业务指标。发布后再触发索引、缓存和通知等派生任务，避免尚未通过质量门禁的数据扩散到更多系统。

6.5.5 Reconcile：用对账结束 Run

Run 结束前需要比较输入对象数、成功转换数、隔离错误数、暂存数、发布数和下游可见数。数量相等也不代表正确，还要比较版本、业务键、缺失范围和关键字段摘要。某些差异可以在预先定义的容忍范围内结束，某些差异必须把 Run 标为 MANUAL_REVIEW；只有所有必需阶段收敛，并且差异已被解释或转入明确的后续任务，Run 才能进入 SUCCEEDED。

对账发现问题时，应创建新的、可审计的修复 Run，而不是让运营人员直接修改结果表。修复 Run 需要引用原始 Run、差异报告、修复策略和审批记录。这样可以区分“原始供应商数据有问题”“转换规则有问题”“发布过程有问题”和“下游索引没有追上”，也能避免一次人工修改破坏后续重放。

6.6 Agent 任务的状态化与协作

6.6.1 Agent 增加的是不确定性，不是免除治理

Workflow 的执行路径通常由代码预先定义；Agent 则可以根据输入和中间观察结果选择下一步。ReAct 论文将推理与行动交错，让模型在行动结果的基础上更新计划，这解释了 Agent 为什么适合检索、诊断和开放式探索；但它也意味着每一次工具调用都可能改变环境，必须被当作正式执行事实记录。[13]

可以把 Agent 看成一个具有动态规划能力的执行单元：

Goal
  -> Plan
  -> Select Tool / Ask Human
  -> Execute
  -> Observe Ground Truth
  -> Update State
  -> Review / Continue / Stop

其中 Plan 不是承诺，Tool Result 才是环境事实；模型的自然语言总结不是状态机，Checkpoint 也不能用“对话上下文里大概记得什么”替代。Agent 每次需要继续工作时，都应从持久化的 Goal、Step、工具结果、审查结论和预算中恢复。Anthropic 的工程实践也强调，Agent 在每一步都需要从环境取得真实反馈，并在检查点或阻塞点暂停等待人类判断。[14]

6.6.2 Stateful Agent Runtime 的最小模型

一个可生产化的 Agent Runtime 至少需要以下实体：

每个 Step 至少有 PENDING、RUNNING、WAITING、SUCCEEDED、RETRYABLE、BLOCKED、REJECTED 和 CANCELLED 状态。工具调用需要保存工具版本、参数摘要、请求 ID、权限上下文、返回摘要和是否产生副作用。对代码 Agent 来说，修改文件、执行命令和提交变更的风险等级不同；对运维 Agent 来说，查询监控、生成变更计划和执行生产变更也必须有不同权限。

6.6.3 代码、调研与运维 Agent 的边界

代码 Agent 的安全链路可以是：读取需求 → 生成计划 → 扫描仓库 → 修改受限文件 → 运行测试 → 生成差异摘要 → 等待人工确认 → 提交或回滚。计划阶段可以由模型主导，修改和测试需要确定性工具，提交和发布则应由权限策略与人工门禁控制。测试失败不是“模型再想一会儿”就算恢复，而是一个带输出、环境和重试次数的失败 Step。

调研 Agent 更适合并行检索、提取证据、去重、冲突检测和摘要，但每个结论都要保留来源、访问时间和证据片段的引用关系。模型可以提出“需要继续搜索”的判断，不能把没有来源的段落自动升级为事实。对于高影响结论，可用第二个 Reviewer 检查来源覆盖和推理跳跃，并把返工次数纳入预算。

运维 Agent 必须把查询与变更分离。查询日志、指标和配置属于低风险观察动作；生成迁移计划、扩容或重启属于中风险动作；删除数据、切换流量或修改生产配置属于高风险动作。高风险动作应该要求明确授权、显示影响范围、支持 dry-run，并在执行前保存回滚点。Agent 的价值在于缩短诊断和准备时间，不等于应该把最终控制权交给模型。

6.6.4 Tool Contract、权限与成本预算

工具契约应包含名称、版本、输入 Schema、输出 Schema、超时、可重试错误、不可重试错误、幂等键、权限范围、副作用等级和审计字段。工具返回值最好分为 success、retryable_error、permanent_error、unknown，而不是只返回一段自然语言。这样 Runtime 才能决定重试、返工、等待人工还是结束。

预算至少分为四类：最大执行时间、最大模型调用次数、最大工具调用次数和最大副作用额度。预算耗尽后，任务进入 BLOCKED 或 MANUAL_REVIEW，不能通过自动循环悄悄重置。上下文也应分层保存：用户目标和权限是稳定上下文，步骤状态和工具结果是执行事实，临时推理是可丢弃上下文。把全部对话拼成一个越来越长的 Prompt，会使恢复、成本和隐私边界都变得不可控。

6.6.5 Multi-Agent 的角色、共享状态与终止条件

复杂调研或研发任务可以采用最小三角结构：Planner 负责拆解，Worker 负责执行，Reviewer 负责检查。只有在角色责任、输入输出和失败路径清晰后，才考虑增加 Router、Supervisor 或领域 Specialist。角色拆分应减少职责冲突，而不是把同一问题让多个 Agent 重复回答。

共享状态不应只是一个公共聊天房间。更稳妥的做法是维护任务账本，每个 Agent 以结构化消息写入：完成了什么、使用了哪些来源或工具、产出了什么、仍缺什么证据、推荐下一步是什么。Planner 可以读取账本生成下一轮计划，Reviewer 可以针对某个 Step 返回 ACCEPT、REWORK 或 REJECT。消息必须有版本和幂等键，避免重投后重复创建任务。

终止条件至少包括：目标判据满足、所有必需 Step 已收敛、预算耗尽、连续返工超过上限、遇到无法自动判断的冲突、人工拒绝或截止时间到达。没有终止条件的 Multi-Agent 很容易进入循环讨论；没有最终裁决者的协作系统也无法解释为什么把互相矛盾的结果交付给用户。Agent 之间的分工获得了并行和专业化能力，但牺牲了通信成本、可复现性、延迟和调试简单性，这些都应进入 ADR 和运行指标。

6.7 故障与治理：默认假设会重复、会超时、会中断

6.7.1 幂等、重复和结果未知

任何 Shard、Tool Call 或消息都可能被重复执行：消息至少一次投递、租约超时、进程在提交确认前重启，都可能造成重复。数据库写操作可以用唯一约束、条件更新或 UPSERT；外部接口应携带稳定请求号并支持按请求号查询。幂等键必须表达业务意图，而不是简单使用随机消息 ID。例如 run_id + shard_id + source_object_id 能识别同一次同步对象处理，order_id + operation_type 能识别同一次业务动作。

最危险的是“结果未知”。一次调用超时只说明调用方没有在截止时间内收到响应，并不说明下游没有执行。正确顺序是：把步骤写成 UNKNOWN，记录外部请求号；优先查询同一幂等键；确认已完成则补写执行事实；确认未执行才允许使用同一键重试；仍无法确认则进入延迟查询、对账或人工队列。直接生成一个新请求号重发，可能造成重复扣费、重复发布或两份资源占用。

6.7.2 重试、超时与失败池

重试必须分类。网络抖动、短暂限流和临时不可用通常可以指数退避并加入随机抖动；字段非法、权限拒绝、规则缺失和质量门禁失败属于永久或业务错误，应该隔离而不是重试；超过重试预算的任务应停止自动尝试。Google SRE 建议限制每次请求和客户端的重试预算，并避免多层同时重试，因为多层重试会产生组合式流量放大。[2][3]

超时至少分为单次调用、Step / Shard 执行和整次 Run 三层。单次超时保护连接与线程；Shard 超时防止死循环或异常大数据；Run 截止时间避免旧任务和下一轮长期重叠。超时触发后，先判断是否存在未知副作用，再决定取消、重试、查询或对账。失败池或 DLQ 不应是垃圾桶，每条记录至少保存原始输入引用、错误分类、尝试次数、最近错误、首次失败时间、下次动作和权限范围；运维人员可以修复输入后重放，但所有动作都要留下审计。

6.7.3 并发、限流与背压

任务系统常见事故不是完全不跑，而是跑得太快。并发度应按被保护资源设置：供应商配额、租户范围、数据库连接池、计算集群、模型服务和发布能力都可能需要独立限制。实时库存修复不应和月度索引重建共享没有隔离的资源池；紧急补数可以有受控加急通道，但不能绕过配额、权限和审计。

背压意味着下游处理不过来时，上游主动减速。需要观察队列积压、Shard 等待时间、接口 429 比例、数据库连接池、Worker 利用率、发布延迟、重试率和最老任务年龄。超过阈值后，可以降低拉取并发、延长退避时间、暂停新 Run、只保留高优先级任务或返回“稍后查询”。AWS 和 Google 的可靠性资料都把超时、退避、抖动、限流和负载削减视为同一个过载控制问题，而不是互不相关的参数调节。[2][3]

6.7.4 暂停、取消、恢复与人工接管

暂停表示保留 Run、Shard 和 Checkpoint，稍后继续；取消表示不再领取新工作，并让已运行的 Shard 在安全边界退出。Worker 应在页、批或对象边界检查控制标记，在完成当前原子单元并写入结果后退出。强行杀进程可以是故障处置手段，但不应被当作正常取消协议，因为它会把状态留在未知位置。

恢复程序应先回收过期租约，再扫描 RETRYABLE、长期 RUNNING 和 UNKNOWN Shard。对未知外部副作用先查询或对账，确认安全后再投递；对长期无进度的执行器，要结合心跳、资源指标和最后 Checkpoint 判断是卡死、慢任务还是外部依赖阻塞。人工接管不能通过直接改库绕过状态机，操作台应展示进度、最近错误、外部请求号、影响范围和建议动作，并要求操作者填写理由、证据和后续验证。

6.7.5 顺序、版本与数据一致性

任务并行化后，并不是所有对象都需要全局顺序，但同一酒店、商品或账务账户的连续更新常常需要按版本收敛。不能依赖“队列看起来有序”：扩容、重放、延迟投递和人工补发都会破坏全局接收顺序。更可靠的做法是让对象携带来源版本、更新时间或单调序号，写入时只接受不旧于当前版本的数据。

示例中的条件更新只表达版本保护思想：

UPDATE staged_inventory
SET quantity = :quantity,
    source_version = :source_version,
    updated_at = :updated_at
WHERE supplier_id = :supplier_id
  AND source_object_id = :source_object_id
  AND source_version <= :source_version;

实际比较依据必须符合来源系统语义。如果上游版本不可信，不能伪造一个“看似有序”的时间戳；应保留原始快照、运行批次和冲突记录，把无法自动判定的新旧关系转入人工核验。对 Agent 任务也一样：旧的计划或工具结果不能因为晚到就覆盖新的人工拒绝或策略版本。

6.7.6 观测、对账与发布保护

可观测性要让值班人员在几分钟内回答：Run 是否在推进，停在哪个 Step，哪些 Shard 受影响，下游是否被压垮，是否需要暂停或介入。日志、指标和追踪应携带 task_id、run_id、step_id、shard_id、幂等键、输入版本和外部请求号。OpenTelemetry 提供跨服务关联 Trace、Metric 和 Log 的统一语义，但业务字段仍需要由任务系统主动写入；没有这些字段，技术链路可见也不等于任务事实可见。[12]

对账负责发现遗漏、重复和错位，在线任务负责快速推进，二者不能互相替代。供应商同步至少核对输入、暂存、发布和下游可见版本；索引任务核对主库版本与索引版本；Agent 调研核对结论与来源引用；模型训练核对数据集、代码、参数、评估结果和产物签名。发现差异后，创建新的修复 Run 或人工任务，不要直接删除错误历史。

发布保护应有最小质量门槛、影响半径和停止条件。质量阈值突破、下游错误率持续上升、回滚次数超过上限或人工确认未完成时，系统应暂停后续发布并报警。版本化发布的回滚对象是“当前有效版本或发布开关”，不是试图删除所有已经传播的消息；如果外部副作用已经发生，回滚应被建模为新的补偿任务，并记录影响范围、进度和验证结果。

6.7.7 任务系统的测试与演练

长任务不能只测试主路径。至少要演练：Worker 在外部调用成功后崩溃、消息重复投递、租约过期、Checkpoint 写入失败、游标失效、下游限流、数据库主从切换、旧版本晚到、发布门禁阻断、人工审批超时、Agent 工具返回歧义结果，以及恢复程序重复运行。

测试结果应验证不变量，而不是只验证最终 HTTP 状态。例如同一幂等键不能产生两次副作用；旧版本不能覆盖新版本；暂停后不能新增未授权工作；取消后已运行的原子单元可以安全结束；人工拒绝后 Agent 不能自动重新提交同一高风险动作；对账差异必须能指向具体 Run、Step、Shard 和责任人。对于不可确定的模型行为，应使用固定任务集、工具桩、轨迹评估和人工抽检建立回归集，不要把一次“看起来合理”的回答当成可靠性证明。[14]

6.8 方法论总结：按问题升级，而不是按潮流堆组件

任务处理可以压缩成一条判断链：先判断是否跨执行边界，再判断是否需要大量对象推进，再判断是否需要阶段治理，最后判断是否需要动态推理与角色协作。同步调用、异步消息、Batch、Workflow、Agent Runtime 和 Multi-Agent 不是互相替代的技术潮流，而是不同复杂度区间中的执行形态。

本章的核心判断如下：

1. 先定义输入、输出、成功判据、截止时间和资源边界，再讨论框架。
2. 只要中断后必须恢复，就需要持久化 Run、分片和可信 Checkpoint。
3. 只要存在副作用，就把重复、延迟、乱序和结果未知当作默认路径。
4. 任务级成功不等于对象级成功；批量任务必须能解释局部失败和跳过。
5. 队列负责分发，状态存储负责事实，日志负责解释；三者不能互相冒充。
6. Batch 解决大规模推进，Workflow 解决阶段依赖与治理，二者经常组合。
7. Agent 可以处理不确定输入，但不能替代状态机、权限、审计、对账和人工门禁。
8. Multi-Agent 只有在角色分工能带来可验证收益时才成立，并且必须有共享状态和终止条件。
9. 重试、限流、背压、失败池、对账和演练共同构成可靠性，而不是事后补丁。

在进入实现前，可以用下面的评审清单快速检查一个方案：

成熟的任务系统不是一组“后台脚本”，也不是让模型自由循环的对话。它是一套能够跨故障、跨时间、跨人员交接持续收敛的执行机制：有明确的事实、有安全的恢复点、有可见的失败、有受控的副作用，也有在自动化无法安全判断时及时停下来的能力。

6.9 参考资料

正文中的编号用于就近说明来源支撑的事实或方法；其中“本章推导”表示本书结合供应商同步、数据处理和 Agent 协作场景做出的工程归纳，不等同于来源原文的直接结论。链接优先指向作者、出版方或长期维护的官方页面，访问与加入日期为 2026-09-21。

[1] Kleppmann M. Designing Data-Intensive Applications[M]. O’Reilly Media, 2017. 用于数据系统的可靠性、可扩展性、可维护性和数据流处理权衡。

[2] Beyer B, Jones C, Petoff J, Murphy N R, eds. Site Reliability Engineering[M]. O’Reilly Media, 2016. 用于服务目标、过载、重试预算和生产治理。

[3] Google SRE. Addressing Cascading Failures[EB/OL]. Google, 2016. 用于解释重试、资源耗尽和级联故障的正反馈关系。

[4] Richardson C. Saga Pattern[EB/OL]. Microservices Patterns. 用于区分跨服务流程协调、补偿和全局原子提交。

[5] Richardson C. Transactional Outbox[EB/OL]. Microservices Patterns. 用于说明本地事实与事件可靠交接的双写边界。

[6] Richardson C. Idempotent Consumer[EB/OL]. Microservices Patterns. 用于说明至少一次投递下的重复消费处理。

[7] Temporal. Workflow Execution overview[EB/OL]. Temporal Documentation, 2026. 用于说明持久执行、事件历史、重放、暂停和恢复。

[8] Apache Airflow. Core Concepts[EB/OL]. Apache Software Foundation, 2026. 用于说明 DAG、Task、依赖、重试和任务执行架构。

[9] Apache Spark. RDD Programming Guide[EB/OL]. Apache Software Foundation, 2026. 用于说明 RDD、分区、血缘和节点故障恢复。

[10] Apache Flink. 有状态流处理[EB/OL]. Apache Software Foundation, 2026. 用于说明状态、Checkpoint、Savepoint 和有状态流处理容错。

[11] Kubernetes. Job 中文文档[EB/OL]. Cloud Native Computing Foundation, 2026. 中文官方资料，用于说明一次性任务、并行 Job、工作队列和挂起恢复。

[12] OpenTelemetry. Documentation[EB/OL]. OpenTelemetry, 2026. 用于说明 Trace、Metric、Log 的关联观测基础。

[13] Yao S, Zhao J, Yu D, et al. ReAct: Synergizing Reasoning and Acting in Language Models[C/OL]. ICLR, 2023. 用于说明推理与工具行动交错的 Agent 执行模式。

[14] Anthropic. Building effective agents[EB/OL]. Anthropic, 2024. 英文工程资料，用于区分 Workflow 与 Agent、工具契约、环境反馈和人类检查点。

[15] Wu Q, Bansal G, Zhang J, et al. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation[C/OL]. arXiv, 2023. 用于说明 Multi-Agent 的角色化对话、工具和人工输入组合。

[16] 周志明. 《凤凰架构：构建可靠的大型分布式系统》[EB/OL]. 2026. 中文开源技术资料，用于补充分布式系统的可靠性、状态和架构演进视角。

[17] 阿里云. 协调多个分布式任务执行——Serverless 工作流[EB/OL]. 阿里云帮助中心. 中文官方资料，用于说明顺序、选择、并行、状态跟踪、重试和长时间流程编排。

[18] Apache DolphinScheduler. Apache DolphinScheduler[EB/OL]. Apache Software Foundation, 2026. 官方项目资料，用于补充 DAG 工作流、暂停恢复、工作组隔离和批量回填等调度能力。

[19] 阿里云. 云工作流：功能特性[EB/OL]. 阿里云帮助中心, 2024. 中文官方资料，用于说明状态节点、选择、并行、循环和标准模式的长流程持久化。

[20] 阿里云开发者社区. Serverless 工作流适用场景及最佳实践[EB/OL]. 阿里云开发者社区, 2020. 中文工程实践资料，用于补充单体函数、事件触发和 Workflow 编排之间的适用边界；具体产品行为以官方文档为准。

第 7 章 高准确性与强一致性系统设计方法论：支付、库存与账务场景

当系统面对支付、库存、账务、钱包、积分等“结果必须正确”的业务时，设计重点不再只是流程能不能跑通，而是事实能不能被严格定义、状态能不能被安全推进、错误能不能被可审计地恢复。

前面的章节讨论了大事务、长流程和任务处理。本章进一步收紧问题范围：有些业务流程即使暂时延迟几秒，最终也可以收敛；但有些业务一旦发生重复扣款、库存超卖、账务不平或金额丢失，事后再补偿也无法完全消除影响。

因此，本章不讨论“所有系统都应该强一致”，而是讨论一个更准确的问题：

在高并发、网络不可靠、依赖不确定的条件下，如何识别不可出错的业务事实，如何把这些事实保护在正确的事务边界内，又如何让跨系统流程在失败后继续可解释、可恢复、可对账。

本章采用八步方法：先定义问题，再确定约束和指标；然后建立业务不变量与状态模型；在此基础上设计参考架构，用 ADR 记录方案取舍，最后通过完整交易案例和故障治理验证设计是否真的可落地。

7.1 问题定义：高准确性不等于整条链路都强一致

7.1.1 先区分三个容易混淆的概念

高准确性关注业务结果是否正确。例如：支付金额是否正确、库存是否被重复扣减、账本借贷是否平衡、优惠券是否被重复核销。

强一致性关注多个副本或多个并发操作对外呈现的状态是否满足严格的可见性语义。线性一致性要求一个操作看起来像在某个时间点瞬间生效，并且不能违背真实时间顺序；它描述的是并发对象对外呈现的行为，不等于“数据库里有事务”这句泛化结论。[2]

可串行化关注一组并发事务的结果是否等价于某个串行执行顺序。它主要描述事务之间的隔离关系，而不是每个 API 的实时响应语义；数据库实现了某种隔离级别，也不代表跨服务的支付、库存和订单已经形成一个全局原子事务。[3]

业务一致性关注跨多个业务对象或多个服务的整体目标是否最终达成。例如，订单、库存和支付不一定由一个全局事务同时提交，但系统必须最终收敛到“已支付、库存已确认、订单可履约”，或者“支付失败、订单取消、库存已释放”。

这三个概念有交集，但不能互相替代：

• 一个本地数据库事务可能具备很强的隔离性，但如果金额计算规则错误，业务结果仍然不准确。
• 一个跨系统流程可能不是全局强一致，但只要每个核心事实有唯一权威源、每个状态迁移可验证、每个异常都有补偿和对账，业务仍然可以正确收敛。
• 一个系统如果只说“最终一致”，却没有定义最终要一致到什么状态、由谁修复、多久必须收敛，那么这不是设计，只是把问题延后。

7.1.2 典型场景和核心风险

设计的第一步不是选择数据库或消息队列，而是把“不能错”和“可以晚一点”分别写出来。如果一个字段只是用于搜索排序或营销展示，它不应因为“看起来重要”而被强行放进支付主事务；如果一个字段会直接决定扣款、发货或记账，它也不能因为“之后会同步”就被放到一个没有约束的异步队列里。

7.1.3 三个反例：为什么“最终一致”不能成为口号

第一个反例是支付成功但订单仍显示未支付。展示延迟几秒本身不一定是事故，真正危险的是订单服务把“未收到回调”解释成“支付失败”，于是允许用户再次创建支付单；或者支付回调与用户取消并发到达，两个处理器都直接覆盖状态。这里要保护的不是页面刷新速度，而是同一支付意图不能出现两个有效成功结果。

第二个反例是库存异步扣减。系统先接受订单，再把扣库存消息放入队列，消费者稍后才扣减。当消息积压或消费者暂时不可用时，多个请求都可能看到相同的可售数量并成功下单。后续把部分订单改成缺货虽然能让库存账恢复，却无法恢复用户已经收到的购买承诺。因此，稀缺资源的“允许延迟”必须发生在预占之后，而不能发生在决定是否出售之前。

第三个反例是钱包余额依赖多个异步任务拼接。如果余额不是由账本严格推导，而是通过充值、消费、退款、冻结和解冻任务慢慢修正，那么消息乱序、重复消费或部分失败都会让余额暂时失去解释能力。对于钱包一类对象，可以让余额查询延迟，但不能让每一笔资金变化没有唯一流水和可重放依据。

7.1.4 范围与边界：只保护 CP 核心段

CAP 讨论的是网络分区发生时，一组共享数据如何在一致性和可用性之间取舍；它不是“数据库分类表”，也不能直接推出“整个业务系统必须选择 CP”。Brewer 后续对 CAP 的说明强调，设计者应明确处理分区并按场景优化一致性和可用性。[1] Spanner 的研究则展示了在特定复制、时钟和基础设施假设下，系统可以提供外部一致的分布式事务，但这并不意味着普通业务可以无成本复制同样的前提。[4]

更务实的做法是把一条交易链路拆成两层：

• 强一致核心段：价格确认、库存预占、订单事实、支付事实和账务分录。
• 最终一致外围段：站内信、积分展示、推荐、营销统计、报表、搜索索引和用户通知。

核心段内部需要严格约束并发、状态和金额；外围段则需要可靠事件、重试、幂等和对账。这样做不是降低质量，而是把最昂贵的正确性能力集中到真正无法出错的地方。

7.1.5 本章的范围与非目标

本章聚焦以下问题：

1. 如何识别不可出错的业务事实和不变量。
2. 如何选择本地事务、Outbox、预占、TCC、Saga 或对账补偿的组合。
3. 如何处理请求重试、回调重复、状态未知、消息乱序和跨系统失败。
4. 如何建立审计、对账、人工接管和恢复机制。

本章不试图展开完整的数据库实现、支付渠道接入协议或财务会计制度。数据库隔离级别、Redis 细节、Kafka 消费模型和订单系统的完整实现，应分别结合本书后续基础设施和电商实战章节阅读。

关于大事务、Saga 和 Outbox 的通用流程可参见第 4 章《大事务处理方法论》；购物车、结算、订单和支付的完整领域实现可参见第 14 章《电商用户 C 端搜索、交易、履约与售后全生命周期设计》。本章只保留跨场景的判断框架和关键取舍。

7.2 约束与指标：先把正确性写成可以验证的条件

高准确性系统不能只用“成功率”和“接口延迟”衡量。它必须同时有业务正确性指标、状态收敛指标和恢复能力指标。更重要的是，指标必须和约束绑定：没有时间窗口的收敛率、没有金额口径的差异数、没有资源范围的库存准确率，都不足以指导设计。

7.2.1 四类约束

规模约束包括峰值请求量、并发事务数、单资源竞争度、单账户写入频率、单分片热点和跨地域复制距离。示例数字必须标记为假设或测量结果。例如，假设一个活动库存只有 10,000 件、峰值每秒 20,000 次抢购请求，那么重点不只是总吞吐，而是同一库存键的写冲突、队列积压和失败后的释放压力。

时间约束包括支付确认时限、库存预占 TTL、回调等待时间、事件最大延迟、对账周期和人工接管时限。TTL 不是一个随意的缓存过期时间，它决定资源会被锁多久、用户等待多久以及超时任务有多大的扫描压力。

正确性约束包括金额不能错、库存不能超卖、状态不能逆向跳转、同一幂等键不能产生两个副作用、补偿不能超过原始动作的影响范围。约束应优先写成可验证的关系，而不是“尽量保证”“通常不会”。

治理约束包括每条事实必须可查询、可追踪、可对账、可重放；出现差异时必须能定位责任边界；人工修复必须有审批、审计和可撤销的补偿记录。

7.2.2 用指标描述系统是否真的收敛

这些指标不能只看平均值。对于资金和库存，少量严重错误也可能比大量普通请求失败更重要；对于补偿任务，则要同时关注积压数量和最老任务年龄。一个“平均 5 秒收敛”的指标，如果其中一批任务已经等待 3 天，就会掩盖真实风险。

高准确性链路还应定义业务 SLO，例如“支付成功事实在 30 秒内被订单服务确认的比例”“库存预占超时后 5 分钟内释放的比例”“对账差异在下一个工作日内完成分类的比例”。这些数字不是行业通用标准，应根据渠道 SLA、资源成本、客服承诺和监管要求测量或协商确定。

7.2.3 用可验证不变量替代口号

一个好的不变量必须可以通过数据库约束、状态条件、查询或对账验证：

• 库存不变量：可用 + 预占 + 已售 = 总量，且每个分量不能小于零。
• 账务不变量：每笔记账必须有借方和贷方，借贷金额相等，业务流水号不可重复入账。
• 支付不变量：同一业务订单在同一支付意图下不能产生两个有效成功扣款。
• 状态不变量：支付成功不能回退为待支付，库存已确认不能被普通取消动作再次释放。
• 补偿不变量：每次补偿动作必须关联原始动作，且重复执行不能制造新的副作用。
• 版本不变量：同一聚合的状态更新必须携带版本或前置状态条件，旧请求不能覆盖新事实。

可以把不变量转成技术检查：

《Designing Data-Intensive Applications》把记录、派生数据、复制和一致性放在同一套数据系统权衡中讨论；对本章而言，直接含义是先确定哪份数据是事实，再决定哪些数据可以异步派生，而不是先选择一个“看起来可靠”的中间件。[5]

7.2.4 把一致性写成接口契约

一个可评审的接口契约至少要说明四种语义：

1. 写入语义：请求成功表示事实已经提交，还是只表示任务已接受？
2. 读取语义：读取主库、快照、缓存还是派生视图？读到旧数据时是否允许作出交易决策？
3. 重复语义：相同幂等键再次到达时返回第一次结果、当前状态，还是拒绝请求？
4. 未知语义：超时后到底是明确失败，还是进入待查询状态？谁负责查询，什么时候转人工？

如果这些语义没有写进 API、状态机和运行手册，调用方就会自行猜测。猜测在正常路径上通常不会暴露，一旦网络抖动，两个系统对“成功”的理解就会分裂。TiDB 文档也提醒，数据库对外使用的隔离级别名称可能与内部实际实现存在差异，不能只根据配置名称推断并发语义。[19] 具体数据库的锁、快照、当前读和隔离级别边界，应以所使用版本的官方手册为准。[20]

7.3 核心模型：事实、状态、不变量和权威源

7.3.1 业务事实必须有唯一权威源

系统中经常同时出现订单状态、支付状态、渠道回调状态、账户余额、账务流水和缓存状态。如果每一层都被当成“真相”，系统就会在异常时陷入争论：到底应该相信哪个状态？

建议为每类关键事实明确权威源：

缓存、消息和搜索索引都可以很快，但它们通常不应该成为支付金额、库存事实或账本流水的唯一权威源。一个系统可以有多个读模型，却只能有一个负责裁决冲突的写事实；否则补偿时没有基准，对账时也不知道应该修哪边。

7.3.2 命令、事实与事件不能混为一谈

命令表达意图，例如“提交支付”“预占库存”“申请退款”；它通常带有发起者、权限、幂等键和前置条件。命令可能被拒绝，也可能因为超时而处于未知状态。

事实表达已经被权威服务确认的结果，例如“支付单已成功”“库存预占已建立”“账务凭证已入账”。事实需要持久化、可查询和可审计。

事件是把已经发生的事实通知给其他系统，例如 PaymentSucceeded 或 InventoryReserved。事件传递失败不应撤销已经提交的本地事实；它应进入重试、补偿或重放流程。

这个区分可以防止一个常见错误：调用支付渠道的命令返回 HTTP 200，就立即把订单写成“已支付”。真正的支付事实可能还需要渠道确认、签名校验、金额核对和本地流水落账。只有事实被权威服务确认后，才能发布成功事件。

7.3.3 状态机比一个布尔字段更可靠

高准确性场景通常不是“成功 / 失败”两个状态，而是包含等待、未知和补偿中的中间态。

支付状态可以抽象为：

待支付 → 支付中 → 支付成功
             ├→ 支付失败
             ├→ 待查单
             └→ 已关闭

库存预占可以抽象为：

可预占 → 已预占 → 已确认
            └→ 已释放

订单状态则应把支付、库存和履约的事实组合起来，而不是简单复制某个下游字段：

草稿 → 待支付 → 支付处理中 → 已支付 → 待履约 → 已完成
          ├→ 已取消       └→ 待查单       └→ 异常履约

状态机至少应定义：

• 允许的状态集合、终态和不可达状态。
• 每个状态的进入条件、退出条件和责任方。
• 哪些迁移由同步请求触发，哪些由事件或定时任务触发。
• 重复迁移如何返回幂等结果，冲突迁移如何返回当前权威状态。
• 发生未知结果时进入什么状态，查询任务的最大等待时间是多少。
• 超时、补偿和人工操作能否改变状态，以及它们需要什么权限。

状态转移还要考虑并发顺序。支付成功回调、用户取消、客服补单和超时任务可能同时到达。处理器不能只按到达时间覆盖 status，而应使用版本号、前置状态条件和权威事件版本。例如，UPDATE payment SET status = 'SUCCESS', version = version + 1 WHERE payment_id = ? AND status IN ('PROCESSING', 'QUERYING') AND version = ?，受影响行数为零时再读取权威状态判断是重复、竞态还是非法请求。

7.3.4 预占模型是资源生命周期模型

“预占 + 确认 / 取消”不是简单的两次接口调用，而是资源生命周期的显式建模。预占记录至少要包含资源 ID、业务单号、数量、预占时间、过期时间、当前状态、幂等键和释放原因。确认和释放都必须带上版本或状态条件，避免旧请求把已经确认的资源再次释放。

它的价值不只在于防超卖，还在于把失败恢复转成明确动作：

1. 预占锁定资源并创建可审计的占用记录。
2. 确认把预占转为已售、已扣减或已生效。
3. 释放把预占归还可用池，并记录是支付失败、用户取消、超时还是人工操作。
4. 过期扫描处理没有收到确认或释放命令的中间态。

库存、额度、余额冻结和优惠券占用都可以使用这个模型，但不能机械套用。余额冻结需要同时记录账户、币种和可用余额；优惠券占用需要防止资格重新计算导致的重复发放；外部供应商库存可能只能“尝试预订”，确认和释放还会受第三方语义约束。本章推导是：资源越稀缺、失败后越难恢复，越应该把预占设计成独立的权威事实。

7.3.5 幂等、防重和去重必须内建

强一致场景最危险的事故，很多不是“完全失败”，而是“成功被执行了两次”。系统必须默认会遇到请求重试、回调重复、消息重复投递、任务重复执行和人工补单重复触发。

可以把幂等分成四层：

Stripe 的幂等 API 设计保存第一次请求的状态码和响应体，使网络失败后的重试可以复用相同结果；它也要求同一个幂等键不能被用于不同参数的请求。[12] 这个经验说明，幂等键不只是“去重字段”，还应绑定请求语义、参数快照、保留时长和结果查询方式。

幂等不是无条件地“重复返回成功”。如果第一次动作仍在执行，第二次请求应返回处理中；如果第一次动作已经失败且失败是可重试的，应返回可查询的失败原因；如果相同键对应不同业务参数，应直接拒绝并告警。对账任务和人工补偿也必须复用原始动作的业务键，不能每次重试都生成一笔新的资金或库存动作。

7.3.6 账本优先于余额字段

余额通常是账本流水的投影，而不是唯一事实。直接修改余额字段会让系统失去解释能力：无法说明余额为什么变化，也无法在发现错误后重放和重算。

更稳妥的结构是：

业务命令 → 记账凭证 → 借贷分录 → 余额投影 → 查询缓存 / 报表

每个记账动作要有唯一业务流水号、金额、币种、借方账户、贷方账户、来源事件和时间。余额可以是事务内维护的快速投影，也可以由分录异步重算；无论采用哪种方式，账本分录都必须可追溯、不可随意覆盖。事件溯源的核心思想也是保存状态变化事件，以便重建过去状态；但它并不意味着所有系统都必须把事件日志作为唯一存储，是否采用要根据重放、查询、合规、归档和团队能力判断。[13]

7.4 参考架构：核心事实本地原子提交，外围流程可靠收敛

7.4.1 一条可落地的总体链路

高准确性系统的通用链路可以表示为：

请求入口
  → 鉴权、参数校验、幂等校验
  → 核心服务本地事务
       ├─ 写入业务事实
       ├─ 推进状态机
       ├─ 写入预占 / 账本 / 审计记录
       └─ 写入 Outbox 事件
  → 事件可靠投递
  → 下游本地事务和幂等消费
  → 超时扫描、查单、补偿、对账
  → 结果查询与人工接管

这条链路没有试图把所有系统放进一个全局事务，而是把问题拆成三个边界。企业集成模式的价值也正在于为异步消息、路由、转换、重试和请求-响应交互提供共同词汇；组件名称不应替代这些交互语义。[6]

这条链路可以拆成三个边界：

1. 事实边界：关键事实在自己的权威服务内原子提交。
2. 传播边界：本地提交后的事实通过 Outbox、事务消息或日志可靠传播。
3. 收敛边界：跨系统的业务目标通过状态机、补偿、查单和对账最终收敛。

可以用一张责任表防止边界混乱：

7.4.2 本地事务与 Outbox 的配合

如果服务需要同时更新业务数据并发布事件，直接先写数据库再发消息会产生双写窗口：数据库提交成功但进程在发消息前崩溃，或者消息发送成功但数据库随后回滚。传统的 2PC 可能把数据库和消息代理纳入同一提交协调，但参与方能力、锁持有时间和故障恢复成本会显著增加；Pat Helland 对大规模系统中全局分布式事务的工程代价有专门讨论。[8]

Transactional Outbox 的做法是把业务事实和待发送事件写在同一个本地事务中，再由独立 relay 投递到消息系统。该模式保证“本地事务提交后有待发送记录”，但不能让消息只发送一次：relay 可能在发送成功后、记录发送结果前崩溃，于是恢复后再次投递。消费者必须幂等，这正是 Outbox 与 Idempotent Consumer 通常配套使用的原因。[10][11]

Outbox 表不应只是一个没有治理的消息垃圾桶，至少要设计：

• 事件 ID、聚合 ID、聚合版本、事件类型和 schema 版本。
• 创建时间、可投递时间、尝试次数、最后错误和锁定信息。
• 事件状态，例如待投递、投递中、已确认、重试中和死信。
• 业务事实与事件的关联键，便于从订单追到事件，也能从事件反查事实。
• 归档与清理策略，避免事件表增长拖慢核心事务和扫描任务。

如果同一个聚合的状态变化会产生多个事件，relay 还要确保版本顺序。消息代理可以提供分区内顺序，但业务必须决定按订单、支付单还是库存项分区；不能把“某个队列当前有序”误认为“跨所有消费者和所有业务对象全局有序”。

7.4.3 事务消息的能力边界

事务消息可以把本地事务结果与消息投递状态联系起来，但它通常保证的是“本地主分支与消息发送”的一致性，而不是消息消费者处理结果与上游事务的全局一致。RocketMQ 官方文档明确区分了半事务消息、二次确认、事务回查和消费端自行重试，并指出事务消息仍会存在下游处理完成前的中间不一致状态。[18]

因此，事务消息和 Outbox 的选择要看系统现状：已有关系库且希望减少新组件，可以优先使用本地 Outbox；已有成熟消息平台且需要生产者事务回查，可以评估事务消息；无论哪一种，消费者都必须具备幂等、乱序处理和失败重试能力。消息机制不能替代业务状态机。

7.4.4 跨系统流程的主控与补偿

当订单、库存、支付和履约分别拥有自己的数据库时，主控方需要保存流程状态和每一步的结果，而不是只保存一个“订单处理中”字段。每一步最好记录：

• 请求和业务幂等键。
• 发送时间、响应时间和超时时间。
• 下游返回的业务状态与技术状态。
• 已执行的动作及其补偿动作。
• 当前重试次数、下一次重试时间和失败原因。
• 对应的上游事件、下游流水和人工处理单。

Saga 把跨服务事务拆成多个本地事务，并为失败设计补偿；原始 Sagas 论文就是为长生命周期事务提出可交错执行的本地事务和补偿事务模型。[7] 微服务环境下，Saga 可以采用编排式或协同式；编排式更容易集中保存流程状态，协同式耦合更松但更难追踪。无论选择哪种方式，Saga 都不是全局原子提交，也不能自动保证补偿一定成功。[9]

补偿还必须尊重业务事实。已扣款后不能用“把支付状态改成失败”伪造退款，已发货后不能用“释放库存”掩盖履约事实，已入账后不能直接删除分录。正确的补偿通常是建立一笔新的退款、冲正、释放或调账动作，并引用原始流水。

7.4.5 可观测性必须跟随业务事实

只记录 HTTP 状态码不足以排查支付和库存问题。日志、链路和指标必须携带订单号、支付单号、库存预占号、账务流水号、幂等键、事件 ID、状态版本和责任域。OpenTelemetry 将 traces、metrics 和 logs 作为可关联的遥测信号，为跨服务定位事实传播和状态变化提供了统一的观测基础。[15]

对于一个“支付成功但订单未更新”的事件，系统至少要能够回答：

1. 支付事实是否已经落地，金额和币种是否核对通过？
2. Outbox 事件是否生成，事件版本和支付流水是否关联？
3. relay 是否读取并投递，是否发生重复投递或死信？
4. 订单消费者是否收到并处理，处理事务是否提交？
5. 订单状态是否因为版本冲突、金额不符或状态不允许而拒绝更新？
6. 是否进入补偿、查单、对账或人工队列，最老任务年龄是多少？

这类问题应能通过一个关联 ID 从用户请求追到业务事实、事件、消费者、补偿和对账结果，而不是依赖工程师在多个日志系统里猜测时间线。

7.5 方案选型：用 ADR 记录获得了什么、牺牲了什么

7.5.1 ADR 不只是写“选择了某个组件”

本章的方案选型必须回答一个问题：在当前约束下，为什么接受一种取舍，而不是另一种取舍。ADR 至少包含：

1. 背景和问题。
2. 决策驱动因素。
3. 候选方案。
4. 最终决策。
5. 获得的能力。
6. 主动牺牲的能力。
7. 已接受的风险和缓解措施。
8. 验证指标与重新评估条件。

“采用 Kafka”“使用 Redis 锁”“引入分布式事务框架”都不是决策本身。决策应描述它如何保护哪个不变量、在什么前提下成立、不能解决什么问题、失败后怎么办。

7.5.2 方案对比

Seata 官方文档把 AT、TCC、Saga 和 XA 分成不同模式，并分别说明本地事务、业务 Try/Confirm/Cancel、补偿和资源协调的前提；这说明“分布式事务”不是一个单一开关，而是一组不同侵入性、隔离性和恢复语义的方案。[16][17]

7.5.3 选择路径：先问边界，再问组件

可以按以下顺序做选型：

1. 关键事实能否通过领域边界调整，收敛到一个服务和一个数据库？如果能，优先本地事务。
2. 如果事实已经落地，问题只是可靠传播，优先本地事务加 Outbox 或受控事务消息。
3. 如果资源需要先锁定再决定最终结果，优先预占、确认、释放模型。
4. 如果流程跨多个服务且允许中间态，使用 Saga 或显式编排状态机。
5. 如果参与方都能提供稳定的 Try、Confirm、Cancel，并且确实需要更强的隔离，再评估 TCC。
6. 只有在参与方受控、边界很窄且团队能够承担阻塞与故障恢复成本时，才考虑 XA / 2PC。

分布式锁只应出现在这个判断链条的局部位置：它可以保护一个短时间内的资源竞争，却不能把多个数据库写入、消息投递和第三方调用变成一个事务。把锁的租约时间、续租、失效和 fencing token 设计好，也不能替代账本、状态机和对账。

7.5.4 示例 ADR：电商创单采用局部原子 + 可靠事件

背景：订单、库存和支付属于不同服务；库存需要预占，支付渠道存在回调延迟和未知状态，外围通知和积分不影响交易事实。业务既要防止超卖和重复扣款，又要承受活动期并发。

决策驱动因素：不能超卖，不能重复扣款，支付结果必须可查；同时需要控制锁等待和第三方依赖带来的尾延迟，不能让通知或报表系统成为全局事务参与者。

候选方案：三方 XA / 2PC、TCC、全链路同步 RPC、Saga + Outbox、订单服务单体化。

最终决策：订单服务在本地事务中创建订单、支付意图和 Outbox；库存采用预占、确认、释放；支付以支付单和渠道查单作为权威事实；跨服务推进使用 Saga 或显式状态机；通知、积分、推荐和报表全部异步化。订单创建只在价格快照、库存预占和本地事实满足条件后进入待支付，不等待所有外围动作完成。

获得的能力：

• 订单事实可以在本地事务内原子落地。
• 库存有明确的预占和释放语义，超时可以扫描。
• 支付未知状态可以通过查单、回调和对账继续推进。
• 事件可以重试，消费者可以幂等，外围系统可以独立扩缩容。
• 每个异常都有订单、支付单、库存预占单或账务流水作为人工接管对象。

主动牺牲的能力：

• 不再追求订单、库存、支付三方瞬时原子提交。
• 用户可能短暂看到“支付处理中”或“订单待确认”。
• 系统需要维护更多状态、补偿任务、对账任务和人工流程。
• 设计和运维复杂度高于单体本地事务，开发团队必须维护事件版本和兼容策略。

已接受风险与缓解措施：支付渠道或消息系统发生长时间故障时，订单会积累在处理中；通过待查单队列、超时查询、用户可见的处理中状态和人工队列限制影响范围。补偿逻辑可能因下游再次故障而延期；通过幂等动作记录、指数退避、死信和对账任务避免无限重试。库存确认长期失败时可能出现已支付但不可履约；进入异常履约和退款流程，不能静默关闭订单。

验证指标：重复扣款为零，超卖差异为零，Outbox 积压的最老事件在目标时间内处理，待查单任务在目标时间内收敛，对账差异自动修复率达到目标，人工接管任务有上限；这些目标应通过压测、故障演练和历史数据测量，而不是凭经验填充。

重新评估条件：单库事务已经成为容量瓶颈、跨地域合规要求改变、支付和库存需要独立扩展，或当前补偿复杂度已经超过引入受控分布式事务的成本。重新评估时不能只看吞吐，还要比较锁等待、异常处理人力、恢复时间和错误影响半径。

7.6 完整案例：电商创单、支付与库存如何闭环

7.6.1 先声明假设和边界

下面使用一个标准电商创单场景演示方法，不把示例数字当成通用标准。假设商品中心提供价格快照，库存中心管理可售库存和预占，订单中心是订单状态权威源，支付中心管理支付意图和渠道流水；通知、积分、推荐和报表是外围消费者。

强一致核心段是：价格快照校验、库存预占、订单创建、支付事实和账务入账。最终一致外围段是：订单通知、积分发放、购物车清空、搜索索引刷新和经营报表。库存预占 TTL、支付查询间隔和人工接管时限应由商品稀缺性、渠道 SLA 和客服承诺测量得到。

7.6.2 正常链路

用户提交订单时，结算服务生成结算快照，包含商品版本、价格、优惠资格、币种、配送信息和渠道。订单服务验证价格版本、用户资格和幂等键；库存服务以订单号和行项目号创建预占记录；支付服务创建支付意图，但此时不应把“支付意图已创建”误写为“支付已成功”。订单服务在本地事务中保存订单、支付意图引用、库存预占引用和 Outbox 事件，状态置为“待支付”。

用户完成支付后，支付服务先验证渠道回调签名、支付单号、订单号、金额和币种，再把支付事实落到自己的事务中。支付事实提交成功后发布 PaymentSucceeded 事件。订单服务消费事件时，以支付单号、事件 ID 和订单当前版本做幂等更新；库存服务收到确认指令后，将预占转为已确认；订单进入“已支付”或“待履约”。积分和通知消费订单事实，不能反过来决定订单是否支付成功。

这条链路中的关键点是：支付成功不能仅以 HTTP 回调成功为依据，库存确认不能仅以 Redis 预扣为依据，订单成功也不能仅以前端收到响应为依据。每个核心状态都必须有自己的持久化事实，并且通过业务主键可以反查上下游流水。

7.6.3 状态、键和责任矩阵

重复请求的结果不应该简单返回“重复错误”，而应返回原始业务结果。例如第一次请求已经创建订单，第二次请求应返回同一个订单号，而不是重新创建订单或让用户陷入未知状态。入口层要保存幂等键与参数摘要，避免同一个键被错误地用于另一份订单。

7.6.4 重复请求、重复回调和重复消费

客户端可能因为网络超时重复提交订单，支付渠道可能重复发送回调，消息 relay 可能重复投递事件。系统必须把这些重复行为当作正常输入。

入口幂等可以使用业务幂等键和唯一约束；支付回调幂等可以使用“渠道标识 + 渠道流水号”；消息消费幂等可以使用事件 ID、状态版本或已处理消息表。重复的 PaymentSucceeded 事件如果订单已经是已支付，应记录为已处理但不再触发新的确认、发货或积分动作；如果订单状态仍为支付处理中，则推进一次；如果订单已经关闭，则进入异常队列，等待对账与人工判断。

重复确认和重复释放也需要状态条件。例如库存已经确认后再次收到释放指令，不能把可用库存增加两次；库存已经释放后再次收到确认指令，不能直接把已释放记录改为已确认。状态机应返回“已经完成”“当前状态冲突”或“需要人工处理”，而不是让每个调用方自行决定。

7.6.5 超时和未知结果

最危险的情况不是明确失败，而是请求在服务端可能已经成功执行，但客户端没有收到响应。

例如支付请求发出后连接断开，客户端不能立即认为支付失败，也不能无限次用新支付单重试。正确处理是保留原支付单号，进入“待查单”，通过渠道查询、异步回调、支付对账或人工核验确认最终结果。查询结果需要再次核对订单号、金额、币种和渠道流水，不能只因为渠道返回“成功”就更新任意订单。

同理，库存确认超时后不能立即重复扣减；订单创建超时后不能只依据客户端响应判断。所有未知结果都需要显式状态、查询接口和后续确认任务。客户端可以通过 GET /orders/{id} 查询订单事实，服务端可以通过 GET /payments/{id} 查询支付事实；查询接口本身也要说明它返回的是权威状态还是派生视图。

7.6.6 失败与补偿

补偿不是简单的“把状态改回去”。退款、库存释放和账务冲正都可能是新的业务动作，因此补偿动作本身也必须有幂等键、流水和审计记录。补偿应遵循原动作的业务语义和依赖顺序：先确认支付结果，再决定是否退款；先确认预占仍存在，再决定是否释放；先确认原分录，再生成冲正分录。

7.6.7 支付、库存和账务如何互相约束

支付中心不能把渠道回调直接当作订单命令，而应先建立支付事实；订单中心不能根据展示缓存判断已支付；库存中心不能根据搜索索引判断可售量；账务中心不能根据订单状态自行推断已经入账。每个系统消费上游事实，但对自己的事实负责。

一个安全的支付成功推进顺序可以是：

校验渠道结果
  → 落支付事实
  → 生成账务记账意图或记账凭证
  → 发布支付成功事件
  → 订单状态推进
  → 库存确认
  → 履约、通知、积分异步推进

不同业务可以把订单确认和账务入账的先后顺序调整，但必须在 ADR 中写清楚。如果支付事实已经成功而账务入账失败，系统不能把支付事实删除；应进入待记账或异常对账状态，最终通过重试、补账或退款处理。这个顺序保护的是“事实不可丢失”，不是追求所有系统同时返回成功。

7.7 故障与治理：把异常闭环做成一等能力

7.7.1 对账设计

对账应先明确三件事：比较双方、比较口径和允许窗口。没有这三件事，对账任务只能制造“差异数量”，却无法说明哪些差异是正常延迟，哪些差异需要修复。

差异至少分为数据延迟、重复记录、缺失记录、金额差异、状态冲突、超时未收敛和无法自动判断。自动修复只能覆盖确定性差异；金额不明或跨系统冲正必须进入人工队列。对账结果本身也应保存输入范围、版本、执行时间、处理人和修复动作，避免“任务跑过了但无法复盘”。

7.7.2 审计和人工接管

人工接管不是承认系统失败，而是高准确性系统在不可判定状态下的安全边界。人工操作必须：

• 使用专门的操作类型，不能直接修改核心字段。
• 记录操作者、原因、审批单、原始事实和操作前后的状态。
• 经过状态机校验，不能绕过不变量。
• 支持撤销或追加冲正，而不是覆盖历史记录。
• 限制权限范围，资金、库存和账务操作应分离授权。
• 具备幂等保护，重复点击同一个处理单只能产生一个动作。

后台页面不应提供“把订单改成已支付”“把库存加回来”这类直接写字段能力。更安全的操作是“确认渠道支付事实”“创建退款任务”“释放某条预占”“生成库存调账申请”，由领域服务根据当前事实执行并写入审计。这样即使人工判断错误，也能通过反向动作修正，而不是丢失原始证据。

7.7.3 监控和告警

至少应该监控：支付未知状态年龄、库存预占超时、Outbox 积压、消息重复率、消费者失败率、补偿失败率、对账差异金额、账本借贷差额、锁等待、事务回滚率和人工队列最老任务年龄。告警要区分“数量突然增加”和“单个任务超过最大允许年龄”，后者通常更能反映资金和库存风险。

过载时不能无条件扩大重试。Google SRE 对过载处理的经验是，服务要能够降级、拒绝或限制重试，避免客户端和服务端相互放大负载；重试预算、快速失败和不同请求类型的优先级都应成为容量设计的一部分。[14] 对高准确性写链路而言，降级不应表现为“少记一笔账”或“先扣款后补库存”，而应表现为暂时关闭非核心入口、限制热点资源并把未知请求转入查询队列。

7.7.4 故障演练和发布治理

发布前应演练以下场景：

1. 支付回调重复、乱序、签名错误和金额不符。
2. 消息积压、重复投递、消费进程在提交后崩溃。
3. 数据库主从切换、锁等待升高和事务提交超时。
4. 库存预占成功但订单创建失败，订单已支付但库存确认失败。
5. 支付渠道不可用、查单接口超时、退款结果未知。
6. 对账任务中断、补偿任务重复执行、人工操作权限错误。

演练的通过条件不能只看服务是否恢复，还要检查业务事实：有没有重复扣款、库存是否平衡、账本是否平衡、未知状态是否进入正确队列、重复执行是否保持幂等、审计记录是否完整。高准确性系统的回滚也要分成代码回滚、配置回滚和业务冲正；部署旧版本并不等于已经撤销新版本产生的资金或库存事实。

7.7.5 评审时的证据链

一次方案评审至少应沿着一条业务事实追问：从用户命令开始，事实在哪里落地，谁能改变它，事件如何传播，消费者如何去重，超时如何判断，失败如何补偿，最终如何对账。每个环节都要有表、状态、键、指标或操作手册作为证据。

如果只能画出成功时序图，却回答不了“响应丢失后怎么办”“回调和取消同时到达怎么办”“补偿执行两次怎么办”“渠道成功但本地没有记录怎么办”，说明设计还停留在接口编排层，没有进入高准确性系统真正的治理问题。

7.8 方法论总结

7.8.1 十个判断句

1. 高准确性首先保护的是业务不变量，而不是某个组件的“强一致”标签。
2. 强一致边界应围绕不可出错的事实划定，而不是覆盖整条用户链路。
3. 线性一致性、事务隔离和跨服务业务一致性是不同语义，必须分别写清楚。[2][3]
4. 本地事务能解决的问题，不要用跨系统事务解决。
5. 可靠事件只能保证事实传播，不能自动保证下游业务正确；消费者仍需幂等。
6. 预占、确认和释放是一套资源生命周期模型，不能只实现成功路径。
7. 支付、库存和账务都必须显式建模未知状态。
8. Saga 解决流程收敛，不等于全局原子提交；补偿本身也是需要治理的业务动作。[7][9]
9. 账本、状态事件和审计记录要保留解释能力，不能用直接改字段掩盖差异。
10. 没有对账、补偿、审计和人工接管，就没有完整的高准确性系统设计。

7.8.2 一份可执行的评审清单

7.8.3 一句话表达

高准确性与强一致性系统设计的核心，不是把整条链路做成昂贵的全局原子事务，而是先识别不可错的业务事实，再用本地事务、状态机、预占模型、幂等、可靠事件、账本、补偿和对账，把核心事实保护住，把跨系统流程收敛住。

这套方法也说明了系统如何演进：早期可以用单体和单库保护核心事实；拆分后用 Outbox 和状态机维持边界；流量增长后再对热点资源分片、排队或引入受控事务协调。每一步都应以不变量和故障证据为依据，而不是以组件数量或架构图复杂度证明系统更成熟。

7.9 参考资料

[1] Eric Brewer, “CAP Twelve Years Later: How the Rules Have Changed”, Computer, 2012。

[2] Maurice Herlihy, Jeannette M. Wing, “Linearizability: A Correctness Condition for Concurrent Objects”, ACM Transactions on Programming Languages and Systems, 1990。

[3] Hal Berenson, Phil Bernstein, Jim Gray, Jim Melton, Elizabeth O’Neil, Patrick O’Neil, “A Critique of ANSI SQL Isolation Levels”, SIGMOD Record, 1995。

[4] James C. Corbett et al., “Spanner: Google’s Globally-Distributed Database”, OSDI, 2012。

[5] Martin Kleppmann, Chris Riccomini, Designing Data-Intensive Applications, 2nd Edition, O’Reilly, 2026。

[6] Gregor Hohpe, Bobby Woolf, Enterprise Integration Patterns, Addison-Wesley, 2003。

[7] Hector Garcia-Molina, Kenneth Salem, “Sagas”, Proceedings of ACM SIGMOD, 1987。

[8] Pat Helland, “Life beyond Distributed Transactions: an Apostate’s Opinion”, CIDR, 2007。

[9] Chris Richardson, “Saga Pattern”, Microservices Patterns。

[10] Chris Richardson, “Transactional Outbox”, Microservices Patterns。

[11] Chris Richardson, “Idempotent Consumer”, Microservices Patterns。

[12] Stripe, “Idempotent requests”, Stripe API Reference。

[13] Martin Fowler, “Event Sourcing”, 2005。

[14] Google SRE, “Handling Overload”, Site Reliability Engineering。

[15] OpenTelemetry, “Documentation”, OpenTelemetry Project。

[16] Apache Seata, “Seata 是什么？”, Apache Seata 官方文档，2025。

[17] Apache Seata, “Seata TCC 模式”, Apache Seata 官方文档。

[18] Apache RocketMQ, “事务消息”, Apache RocketMQ 官方文档。

[19] PingCAP, “TiDB 事务隔离级别”, TiDB 文档中心。

[20] Oracle, “InnoDB Transaction Isolation Levels”, MySQL 8.4 Reference Manual。

第 8 章 低延迟与复杂读场景系统设计方法论：搜索、推荐、广告与 Feed

当系统面对搜索、推荐、广告投放、Feed 流、详情页这类“用户一打开就要马上看到结果”的场景时，设计重点不再只是数据对不对，而是如何在复杂查询、高 QPS 和持续变化的数据之间，把延迟、吞吐、结果质量和数据新鲜度一起控制住。

上一章讨论了支付、库存和账务等“事实不能错”的系统。本章讨论另一类同样典型的问题：结果不一定要求全链路瞬时强一致，但必须在严格的延迟预算内稳定产出，并且能够解释结果为什么这样生成、什么时候更新、过载时如何降级。

低延迟复杂读系统最容易被误解成“加一个缓存”或“部署一个搜索引擎”。真正的系统设计问题是：写模型、索引、候选集、特征、缓存、排序和页面拼装之间如何协作；哪些计算应该在写入时完成，哪些必须在请求时完成；当某个依赖变慢或数据暂时陈旧时，系统应该牺牲什么来保护用户体验。

8.1 问题定义：复杂读的核心是稳定地产出结果

8.1.1 复杂读不是简单地把数据查出来

简单读通常是按主键查询一个事实，复杂读则包含多个阶段：解析请求、过滤候选、全文检索、召回、排序、特征读取、聚合、权限判断、分页和结果拼装。

典型请求包括：

• 搜索商品、内容、酒店或文档。
• 推荐下一条内容、商品或广告。
• 根据用户、上下文、预算和频控进行广告决策。
• 生成按时间、关系和排序规则组织的 Feed。
• 拼装商品详情、价格、库存、营销、评价和推荐信息。

这些请求通常具有五个共同点：查询逻辑复杂，读取远多于写入，数据会持续变化，流量具有尖峰和热点，用户对延迟与结果质量都敏感。它们的“读”并不是对某张表执行一次 SELECT，而是一次面向用户意图的结果生成过程。

从业务角度看，系统最终交付的也不是“数据库返回了多少行”，而是一个可以被用户使用的结果集合。搜索空结果、推荐列表重复、广告候选缺失、Feed 顺序抖动、详情页核心字段过期，都会被用户感知为产品质量问题，而不只是某个基础设施指标变差。

8.1.2 复杂读场景的五个设计轴

这五个轴会互相冲突。提高召回数量可能提高结果质量，但会增加排序延迟；缩短缓存 TTL 可以提高新鲜度，但会降低命中率并增加回源压力；增加实时特征可以提高个性化效果，但会拉长依赖链路。

可以把复杂读抽象成下面的优化问题：

在总延迟预算、资源预算和新鲜度窗口内，最大化结果质量与业务价值

这个表达式不是要求团队计算一个精确的数学最优解，而是提醒设计者：任何“更快”的方案都要说明牺牲了什么。例如，减少精排候选可以降低 P99，却可能降低相关性；延长缓存 TTL 可以提高命中率，却可能放大陈旧价格的展示风险；把 Feed 预先写入用户时间线可以降低读取成本，却会增加写放大和关系变化时的维护成本。

8.1.3 本章的范围与非目标

本章聚焦：

1. 如何从查询模式设计读模型，而不是直接复用写库模型。
2. 如何建立延迟预算，并把预算分配到检索、特征、排序和拼装阶段。
3. 如何通过索引、缓存、预计算、物化视图和 Fanout 保护读路径。
4. 如何在不一致、依赖故障和过载时提供可解释的降级结果。

本章不展开具体搜索分词算法、推荐模型训练细节或某个云厂商的产品配置。搜索引擎、Redis、Kafka、推荐模型和 Elasticsearch 的实现细节，应结合本书后续基础设施章节阅读。

索引和搜索引擎的底层面试题可参见后端面试基础知识题单中的 Elasticsearch 主题，商品发现的完整业务读路径可参见第 14 章电商用户全生命周期设计。本章重点保留复杂读场景的统一模型、延迟预算和方案取舍。

8.2 约束与指标：把“快”拆成预算，把“好”拆成质量

8.2.1 不要使用一个统一的延迟目标

“P99 必须小于 100 ms”可以作为讨论起点，但不能成为脱离场景的通用标准。搜索建议、广告决策、商品详情和离线管理后台的延迟目标不同；同一个接口在不同请求类型下的资源成本也可能完全不同。

Google 的《The Tail at Scale》说明，在大规模服务中，尾延迟会因为请求扇出、依赖抖动和资源利用率上升而被放大。因此设计时必须关注 P95、P99 和最慢依赖，而不是只看平均响应时间。[1]

延迟目标应该按场景写成契约：搜索建议要求首字响应快，详情页保证基础字段先返回，推荐模块允许独立超时，广告决策必须在极短时间内完成，运营后台则可以接受更长等待。契约还应说明超时后的行为：是返回旧结果、减少候选、跳过增强模块，还是直接拒绝请求。

8.2.2 延迟预算示例

假设商品详情页的目标预算为 180 ms，可以先建立一张可调整的预算表。数字不是通用标准，应以线上测量和容量测试为依据；它的作用是迫使团队明确每一段时间花在哪里。

网关、鉴权和请求解析：10 ms
详情物化视图读取：25 ms
价格与库存动态字段：40 ms
推荐和营销模块：35 ms
结果拼装与序列化：30 ms
网络余量与降级判断：40 ms
总预算：180 ms

更适合评审和容量测试的形式是阶段预算表：

预算不能简单地被每个服务都复制一份。如果价格服务和库存服务各自要求 100 ms，详情页就不可能稳定满足 180 ms；如果推荐不是核心结果，就不应让它拥有一个“必须完成”的预算。工程上需要区分服务自己的处理预算、调用方等待预算和端到端用户预算。

预算还要包括排队、连接池等待、序列化、跨可用区网络、重试和熔断判断。很多系统在单次调用压测中很快，在混合查询和高并发下却变慢，原因正是这些共享资源没有被计入阶段预算。真正的预算应来自分阶段 trace，而不是来自每个服务负责人对自己接口的主观估计。

8.2.3 指标体系

点击率和转化率只能作为业务信号，不能直接替代技术指标。一个推荐结果点击率下降，可能是排序质量问题，也可能是延迟变高导致用户根本没有看到完整结果；一个搜索空结果率上升，可能是索引构建失败，也可能是查询改写或过滤规则发生变化。指标必须能沿着请求 ID、查询版本、索引版本和策略版本回溯到具体阶段。

质量指标也不能只看一个总平均值。推荐系统需要观察候选覆盖、长尾覆盖、重复率、曝光分布和用户负反馈；搜索系统要观察无结果 Query、错误召回、首条点击和满意度；Feed 要观察新鲜内容比例、重复内容比例和游标连续性。美团公开的搜索排序实践将数据层、召回层、粗排、精排、重排和展示层拆开，并以分层架构平衡排序效果和性能，这种拆分也便于分别定义质量与延迟指标。[14][15]

8.2.4 数据新鲜度要写成业务契约

“近实时”不是指标。应针对不同字段定义窗口：商品标题允许延迟几十秒，价格可能只允许几秒，库存可能必须在下单校验时回源，推荐特征可能允许分钟级延迟，广告预算则需要更严格的扣减语义。

同一个页面也可能同时存在不同新鲜度：商品描述可以读缓存，价格和库存必须读取受控的动态服务，推荐搭配可以使用旧候选集。页面级“全局一致”往往不是必要目标，字段级新鲜度契约才更容易落地。契约至少要包含数据源、允许年龄、版本含义、超时行为、回退值和恢复动作。

可以把读结果的状态划分为：当前版本、可接受旧版本、超过窗口但仍可展示、禁止展示和未知状态。这样，服务不是简单返回一个对象，而是返回对象、来源版本、生成时间、数据年龄和状态。调用方才能决定是继续展示、标注“正在更新”、回源校验，还是直接隐藏该字段。

8.3 核心模型：读模型是派生数据，查询模式决定数据结构

8.3.1 写模型和读模型承担不同职责

写模型主要保护领域事实、写入约束和业务事务；读模型主要服务检索、过滤、排序、聚合和展示。它们可能来自同一份原始数据，但不应被迫使用同一种数据结构。

一个典型的数据流是：

权威写模型
  → 变更事件 / CDC / Outbox
  → 索引、物化视图、候选集、特征库、缓存
  → 在线复杂读服务

读模型是派生数据，因此必须记录来源版本、更新时间、构建状态和失败原因。出现异常时，系统才能知道某条结果是源数据、旧版本派生数据，还是降级数据。数据系统的设计通常要区分系统记录与派生数据：派生数据可以被重建，但必须有明确的重建输入、顺序和校验方式。[2]

8.3.2 从事实到结果的统一数据模型

复杂读可以拆成六类对象：

权威性只属于明确承担业务约束的事实源。索引中的价格可以帮助展示和排序，但它不是结算价格；搜索结果中的库存标签可以帮助用户筛选，但不能替代下单时的库存校验；推荐缓存中的广告候选可以参与竞价，但不能替代预算扣减。把派生数据误当权威数据，是复杂读系统最危险的边界错误。

8.3.3 复杂读的统一管道

搜索、推荐、广告和 Feed 虽然业务不同，但可以用一条统一管道理解：

请求解析
  → 查询改写 / 权限过滤
  → 候选召回或索引检索
  → 规则过滤
  → 特征读取
  → 粗排 / 精排 / 重排
  → 去重、分页、拼装
  → 缓存、降级与结果解释

每个阶段都可能成为瓶颈。只优化搜索引擎而忽略排序，或者只提高缓存命中率而忽略回源风暴，都不能保证端到端延迟。

每个阶段还要说明它可以放弃什么。例如，召回可以只保留高置信度候选，粗排可以使用较低成本的模型，精排可以限制候选数量，重排可以在超时后跳过；但权限、删除、合规和核心事实校验不能因为延迟紧张而被静默跳过。分层的价值不是把一个服务拆成很多服务，而是让质量、延迟和失败语义能够分别治理。

多路召回通常需要先并行得到候选，再做去重、配额、粗排和精排。候选数量应当是可计算的资源预算，而不是越多越好：候选越多，排序特征读取、模型推理和去重成本越高；候选过少，又会造成质量天花板。腾讯公开的推荐系统资料也将召回理解为从海量物品中快速筛选小候选集，再进入排序阶段，并强调不同召回策略应根据业务和成本组合。[17][18]

8.3.4 预计算不是偷懒，而是把成本转移到可控路径

当结果可以提前准备时，应优先考虑：索引文档、物化详情、聚合统计、候选集、商品热度、用户画像和模型特征。

预计算获得的是更短的请求路径，但牺牲了部分实时性和更新链路的简单性。因此必须同时设计：更新触发、失败重试、版本传播、重建索引、旧版本回退和热点强刷。

批处理和流处理的价值不是让所有事情都异步，而是把可重复、可并行、对请求上下文不敏感的工作移出用户请求路径。Google 的 MapReduce 工作说明了大规模数据处理可以通过批量任务、分片和失败重试来完成；在复杂读系统中，这类离线能力常被用来生成索引、候选和统计特征。[3] 预计算不是“把一致性问题消失”，而是把它从用户请求中移动到可观测的传播链路。

8.3.5 缓存的语义比命中率更重要

缓存设计至少应回答：

• 缓存的是事实、派生结果还是临时计算结果？
• 允许陈旧多久？
• 失效由谁触发？TTL 和主动失效冲突时谁优先？
• 热点失效后如何防止所有请求同时回源？
• 缓存不可用时是否有更慢但正确的路径？
• 缓存命中时是否需要校验版本或业务状态？

Redis 官方文档将 cache-aside 定位为以 TTL 约束陈旧窗口、降低主数据库读压力的模式，同时提醒热点失效会造成缓存击穿。[12] Facebook 的 Memcache 工程实践进一步说明，大规模缓存系统会涉及一致性、失效、复制、故障转移和负载均衡；当缓存承担了过多职责时，缓存本身可能从“加速层”变成系统必须依赖的状态层。[4]

因此，缓存命中率只能回答“多少请求没有回源”，不能回答“返回的结果是否可信”。应同时记录数据年龄、命中来源、版本差距、回源原因和回源结果。对于价格、库存、权限、删除标记等高风险字段，命中缓存后仍可能需要短路校验或版本校验；对于商品描述、图片和推荐搭配，可以允许更长的陈旧窗口。

8.3.6 分页、候选和排序也属于数据模型

复杂读的分页不是界面层的小功能。offset 分页需要先跳过前面大量结果，随着页码增加，查询和排序成本可能持续上升；在数据变化时，offset 还可能导致重复或漏项。对稳定排序的搜索结果，可以使用基于排序值和唯一 ID 的游标；Elasticsearch 的 search_after 文档将游标式分页用于深分页场景，并要求调用方维护一致的排序条件和游标语义。[11]

游标必须绑定查询版本、排序版本、过滤条件摘要和过期时间，否则用户翻到下一页时，前后两次请求可能已经使用了不同的排序逻辑。Feed 还应保存时间线快照或游标生成时间，避免热点内容插入导致一条内容在不同页重复出现。推荐结果则要保存去重和曝光过滤所需的窗口，不能只缓存一个没有上下文的 ID 列表。

8.4 参考架构：从写入传播到在线读路径

8.4.1 写入侧：构建派生读模型

写入侧可以采用以下流程：

1. 权威服务在本地事务内提交业务事实。
2. 通过 Outbox、CDC 或事件日志发布变更。
3. 索引构建器更新搜索文档。
4. 物化视图构建器更新详情和聚合结果。
5. 特征计算任务更新在线特征或候选集。
6. 缓存刷新器主动刷新热点数据，长尾数据按需加载。
7. 记录版本号、更新时间、失败原因和重建进度。

写入传播失败不能直接覆盖权威事实，也不能让读模型无限重试。应使用重试、死信、全量重建和差异校验保证最终收敛。

8.4.2 在线侧：围绕预算执行

在线请求可以按以下顺序处理：

接收请求
  → 识别场景和优先级
  → 命中结果缓存或本地缓存
  → 未命中时执行检索 / 召回
  → 并行读取必要特征
  → 在预算内执行排序
  → 拼装核心结果
  → 超时则跳过非核心依赖并返回降级结果

关键依赖应设置独立超时，禁止使用一个全局超时掩盖内部预算失控。依赖失败时，应该知道哪些字段可空、哪些字段可以使用旧值、哪些结果必须直接失败。

8.4.3 各类系统的主要差异

不同系统的共同架构不能抹平业务边界。推荐可以接受旧候选，但不能展示已下架内容；广告可以使用预计算候选，但不能无视预算和频控；详情页可以展示旧描述，但不能把超过允许窗口的库存当成可购买事实。读路径必须在“速度”和“业务安全”之间明确红线。

8.5 方案选型：用 ADR 记录延迟、质量和新鲜度的取舍

8.5.1 典型方案的获得与牺牲

方案比较不能只写“推荐使用某组件”，而要写清楚当前约束下的优先级。直接查交易库得到的是事实新鲜和开发简单，但复杂排序、聚合和热点会争抢写资源；索引得到的是查询性能和横向扩展，但必须接受传播延迟；物化视图得到的是短读路径，但要付出重建、版本和差异校验成本。CQRS 的核心也不是增加一个读库，而是承认同一业务数据的写入组织方式和读取组织方式可能不同，并为两侧建立明确的同步边界。[7]

ADR 中的“获得 / 牺牲”应使用同一组维度比较，例如一致性、新鲜度、延迟、吞吐、质量、成本、复杂度、可运维性和恢复能力。若方案不能保证某项能力，应直接写出，而不是用“最终一致”把具体窗口隐藏起来。每个决策还应给出验证指标和重新评估条件，让 ADR 成为可被后续数据推翻的工程假设，而不是上线前的形式文档。

8.5.2 示例 ADR：商品发现采用索引 + 物化详情 + 动态事实校验

背景：商品搜索需要关键词、过滤和排序；详情页需要拼装商品、价格、库存、营销和推荐；商品信息更新频率低于读请求，但价格和库存变化更快。

决策驱动因素：搜索和详情不能持续回源交易库；价格和库存不能完全依赖陈旧缓存；读链路需要在高峰时降级，且搜索结果必须能说明索引延迟。

候选方案：所有查询直接查交易库、全量 Redis 缓存、搜索索引承担全部字段、CQRS + 物化视图、搜索索引与动态事实服务组合。

最终决策：商品主数据构建搜索索引；详情页使用物化视图减少多源拼装；价格和库存作为动态字段由受控服务校验；推荐和营销属于可降级模块；索引和物化视图通过事件传播并记录版本。

获得的能力：

• 复杂查询不再挤压交易库。
• 搜索、详情和推荐可以按查询模式独立扩展。
• 页面核心字段与非核心字段可以分级处理。
• 价格和库存不会因为页面缓存而完全失去事实约束。
• 发生索引延迟时可以通过版本和更新时间解释。

主动牺牲的能力：

• 商品修改不会在所有读模型中瞬时可见。
• 需要维护事件传播、索引重建、物化视图和缓存失效。
• 页面数据来自多个版本，短时间内可能出现字段之间的新鲜度差异。
• 系统不能只靠数据库事务保证完整读结果一致。

已接受风险与补救：索引延迟可能导致搜索结果短暂缺少新商品，通过索引延迟监控、热点强刷和全量重建补救；价格或库存服务超时时，页面只能展示基础信息，并标注暂不可购买；缓存失效可能造成回源压力，通过单飞、随机 TTL、本地兜底和按优先级限流保护数据库。

验证指标：索引 P99 延迟、商品详情缓存命中率、价格和库存动态字段超时率、页面整体 P99、非核心模块降级率、过期数据比例和搜索空结果率。

重新评估条件：索引重建窗口超过业务新鲜度要求、动态字段请求成为页面主要瓶颈、缓存回源成本超过独立读模型成本，或业务需要读己写和强新鲜度保证。

8.5.3 Fanout 的 ADR 判断

Feed 不能只问“写扩散还是读扩散”，而应按用户关系规模、内容热点、读写比例、允许延迟、存储放大和删除语义综合判断。

• 普通用户关注关系稳定、读取频繁时，写扩散可以换取更短的读路径。
• 超级节点粉丝数巨大时，写扩散会造成不可接受的写放大，应转为读扩散或混合策略。
• 混合策略获得了更好的总体平衡，但牺牲了实现简单性，需要维护两套路径和去重规则。
• 内容删除、权限变化和用户拉黑必须能够影响已经生成的时间线，不能因为写扩散完成就认为结果永久有效。

Facebook 的 TAO 论文展示了面向固定访问模式的读优化图存储：它在持久化存储之上提供图关系访问和缓存，以低延迟服务大规模社交图；但它也明确选择了适合业务的有限一致性，而不是把所有关系读取都变成强一致事务。[5] 这个例子说明，读优化存储的价值来自清晰的访问模式和接受边界，而不是来自某个产品名称。

8.6 完整案例：商品搜索与详情页的读路径设计

8.6.1 写入到读模型

假设一个电商平台有商品主数据、价格、库存、营销、评价和推荐搭配六类信息。用户输入关键词进入搜索列表，再点击商品进入详情页。系统要满足以下假设性约束：搜索列表优先保证相关性和响应速度；静态商品信息允许几十秒内收敛；价格和库存必须在下单前重新校验；推荐和营销可以在高峰时跳过；新发布商品需要在可接受窗口内进入搜索。

商品的读状态不应只有“存在 / 不存在”，而应至少包含源版本、索引版本、详情视图版本、价格版本、库存版本和生成时间。商品主数据事件携带 product_id、source_version、event_type、occurred_at；每个派生消费者维护自己的 applied_version。当事件乱序到达时，旧版本只能被记录为过期事件，不能覆盖已经应用的新版本。

商品服务提交商品、类目、属性和展示状态后，在同一业务事务中写入变更记录。事件发布器将变更发送到索引、详情物化、推荐特征和缓存刷新任务。流程可以表示为：

商品权威库
  → 商品版本 V42
  → 变更事件 product.updated(V42)
  ├─→ 搜索索引：文档版本 V42
  ├─→ 详情物化：视图版本 V42
  ├─→ 推荐特征：候选 / 属性版本 V42
  └─→ 热点缓存：按需刷新或标记失效

每个派生结果都携带商品版本号。索引服务更新失败时，商品仍然保留在权威库；详情物化失败时，系统可以返回上一个完整视图并记录版本差距；价格或库存变化时，可以只更新动态字段，避免重建完整详情。对高热度商品，事件系统可以提升优先级，但不能无限制地让热点重建任务挤压全量恢复任务。

事件传播的可观测性至少包括：源版本到索引版本的差值、事件进入队列时间、消费者处理时间、重试次数、死信数量、单商品重建耗时和最近一次全量校验结果。版本水位比单纯的“消息消费成功率”更能说明用户是否已经看到更新。

8.6.2 搜索请求

搜索请求首先解析关键词、过滤条件、排序方式、地域和分页游标。查询理解阶段可以做同义词、实体和意图处理，但必须记录改写后的 Query，避免出现“用户搜什么”和“系统实际查什么”无法解释的问题。索引负责召回和过滤，排序字段尽量提前写入文档；聚合和高成本统计必须有独立预算。

多路召回可以包括文本匹配、类目过滤、地理距离、热门商品、个性化候选和向量召回。各路召回先并行得到候选，再经过去重、配额、粗排和精排。美团搜索公开文章将召回、粗排、多路融合、精排和重排拆成不同层次，并指出多业务场景需要在效果与性能之间做配额和截断，这正是复杂读系统需要保留的工程边界。[14]

深分页不能无限依赖 offset，因为跳过大量结果会放大查询成本。更稳定的方式是使用游标或基于排序键的连续读取，并把游标绑定到查询版本、排序规则和过期时间。

搜索结果不是商品事实本身。价格、库存和活动资格如果属于强业务约束，展示层可以使用索引中的近似值，但下单前必须回到权威服务重新校验。搜索结果还要记录结果生成时间和索引版本；当用户投诉“新商品搜不到”时，系统应能回答是商品尚未发布、事件未投递、索引未刷新，还是查询过滤规则排除了它。

8.6.3 详情页请求

详情页可以把字段分成三组：

• 核心静态字段：商品标题、图片、规格和描述，可进入物化视图和长 TTL 缓存。
• 动态交易字段：价格、库存、优惠资格，需要更短的新鲜度窗口或实时校验。
• 非核心增强字段：推荐搭配、评价摘要、猜你喜欢，可以独立超时和降级。

请求到达后先读详情物化视图，再并行读取动态价格和库存；推荐和营销模块拥有独立的等待预算。若动态服务在预算内返回，页面附带当前版本；若超时，页面可以返回静态字段，但必须将商品状态标为“价格或库存正在更新”，不能把旧值渲染成仍然可下单的事实。

缓存策略也应按字段拆开。整页缓存命中快，但容易把价格、库存和推荐全部绑定在同一个 TTL 上；局部缓存更容易表达不同新鲜度，却增加拼装复杂度。商品描述和图片可以使用物化详情缓存，价格和库存使用短 TTL 快照或受控服务，用户个性化推荐则使用候选集缓存加实时过滤。

8.6.4 推荐与广告的映射

推荐系统通常采用召回、粗排、精排和重排分层。YouTube 推荐论文公开描述了候选生成模型与排序模型分离的两阶段结构，说明“把所有候选都交给一个大模型一次性排序”通常不是可扩展的在线方案。[6] 推荐候选可以来自用户历史、相似商品、内容标签、热门池和实时行为；候选层追求覆盖与速度，排序层才承担更昂贵的个性化计算。

推荐结果进入详情页时，还要执行商品下架、地域限制、已购买、曝光频控和库存状态过滤。推荐特征可以准实时，商品可售状态却不能因为旧候选而失效。推荐服务超时可以返回热门搭配或空模块，但不能让它占用价格和库存的核心预算。

广告请求还要加入预算、定向、频控、出价和合规过滤。它不是简单的推荐排序：候选相关性、商业约束和预算事实必须分层处理。推荐候选可以预计算，广告预算扣减则需要更严格的事实控制；如果预算服务超时，宁可减少广告候选或返回保底广告，也不应无界重试。

8.6.5 Feed 和热点内容的变体

Feed 场景的核心不是单条内容查询，而是把用户关系、时间顺序、内容质量和热点扩散合并成一条可分页的时间线。普通用户可以使用 Fanout-on-write，把新内容提前写入关注者的时间线；超级节点或热点内容则更适合 Fanout-on-read，在读取时合并。

混合方案需要额外处理三个问题：

• 同一内容可能同时来自用户时间线、热点池和推荐候选，必须按内容 ID 去重。
• 内容写入和删除传播存在延迟，必须在读取时执行最小权限和状态过滤。
• 时间线不能只依赖 offset 分页，否则新内容插入会导致重复或漏读；应使用带版本或时间边界的游标。

因此，Feed 的 ADR 往往不是“选择写扩散”或“选择读扩散”，而是按用户类型、内容热度和资源成本选择不同路径。获得的是总体吞吐和延迟的平衡，牺牲的是两套数据路径、去重逻辑和一致性治理的复杂度。内容删除、权限变化和用户拉黑必须能够影响已经生成的时间线，不能因为写扩散完成就认为结果永久有效。速度来自预组织数据，但业务有效性仍然需要在线检查。

8.7 故障与治理：允许结果降级，不允许系统失控

8.7.1 缓存故障：击穿、穿透和雪崩要分开处理

缓存故障至少有三种形态：

• 击穿：单个热点 Key 过期或失效，瞬间大量请求回源。
• 穿透：请求的对象不存在或参数非法，反复绕过缓存访问后端。
• 雪崩：大量 Key 同时失效，或缓存集群整体不可用，造成回源洪峰。

三者的保护手段不同。击穿需要 Singleflight、互斥重建、逻辑过期或热点预热；穿透需要参数校验、空值短缓存、布隆过滤器和访问限流；雪崩需要 TTL 打散、多级缓存、容量预留、故障切换和按优先级降级。中文工程资料对这三类问题的区分和治理有较多实践总结，但具体阈值必须根据业务流量和数据分布测量，不能把示例配置当成通用标准。[20]

缓存故障时，降级路径必须在正常设计中就存在。可以读取上一次成功的静态结果、切换到本地快照、只返回核心字段或限制长尾查询；不能在缓存故障后临时发明一套更复杂的“备用实时计算”，否则所谓 fallback 可能比原路径更容易失败。AWS 的优雅降级建议将部分硬依赖转为软依赖，在下游延迟或错误时返回最后一次成功值或简单静态结果，同时避免用复杂的替代机制扩大故障面。[10]

8.7.2 索引和物化视图延迟

索引延迟不是一个单一指标，应区分事件未产生、事件未投递、消费者积压、文档更新失败、刷新未完成和查询侧版本过旧。每一层都要记录水位：源版本、队列版本、构建版本、已刷新版本和查询返回版本。

出现延迟时，先保护业务，再修复派生数据。热门商品可以执行定向强刷，长尾商品等待队列自然收敛；索引构建失败进入重试或死信，持续失败进入全量重建；详情页可以使用上一完整版本，但在超过陈旧窗口后改为基础字段或不可购买状态。不要在所有请求上同步等待索引追平，否则一处传播延迟会变成全站读延迟。

全量重建也需要限速和校验。重建任务应使用独立资源，不能与在线查询抢占全部 CPU 和磁盘；新索引应先在旁路完成校验，再通过别名或版本指针切换；切换后保留旧索引一段时间，以便在字段映射或数据清洗错误时回滚。重建完成的标准不是任务结束，而是版本差距、文档数量、关键字段覆盖率和抽样比对都通过。

8.7.3 过载、重试和部分依赖失败

过载时最危险的行为通常是无条件重试。一次页面请求同时调用多个依赖，若每个依赖超时后再重试，实际请求量会迅速超过入口 QPS。Google SRE 的过载治理强调，系统应结合 CPU、队列、连接池和下游健康度进行负载削减，而不是只看请求数；级联失败往往是健康实例减少、排队增长和重试放大的结果。[8][9]

读链路应建立分级降级：

1. 关闭高成本特征和非核心排序；
2. 减少召回深度、聚合数量和 Feed 扩散范围；
3. 优先返回缓存、上一版本或热门兜底结果；
4. 对长尾 Query、深分页和低优先级调用限流；
5. 只有在核心事实无法可靠返回时，才返回明确错误。

降级需要有状态、原因和恢复条件。不能只在日志中打印 fallback=true，还要知道是缓存故障、排序超时、索引滞后、过载保护还是策略主动降级。恢复时先小流量探测，再逐步放开候选数、特征和非核心依赖，避免流量恢复本身再次冲垮系统。

8.7.4 可观测性、质量回放与容量治理

复杂读系统应把一次请求拆成可关联的 trace：入口、查询改写、召回、候选过滤、特征读取、排序、拼装、缓存和降级。每阶段记录候选数量、耗时、版本、命中情况和错误原因；不要只记录最终总耗时，因为总耗时无法回答“是索引慢还是模型慢”。OpenTelemetry 的 trace、metric 和 log 关联能力可作为统一观测入口。[13]

质量治理需要保存 Query、召回源、过滤原因、排序版本、曝光列表和用户反馈，但要遵守隐私和数据保留边界。对搜索可以做 bad case 回放，对推荐可以做离线候选覆盖与线上 A/B 对比，对 Feed 可以检查重复、顺序和删除生效。美团公开的搜索质量实践强调把结果质量分层诊断，区分供给存在但链路未召回、召回后被过滤、排序失配和展示问题，这种诊断思路适合迁移到复杂读平台。[16][19]

容量治理不能只做峰值 QPS 压测，还要做混合请求、热点倾斜、缓存冷启动、索引重建、依赖超时、节点丢失和降级恢复测试。测试结果应记录资源曲线和拐点：在什么利用率下 P99 开始非线性上升，队列多长时需要拒绝，候选数量降低多少会影响质量，缓存恢复需要多长时间。没有这些边界，SLO 只是一个愿望数字。

8.7.5 读己写、版本和陈旧数据解释

复杂读系统不能只用“缓存是否命中”解释结果，还要能解释结果对应哪个版本。用户刚修改商品、刚发布内容或刚完成关注操作后，常常会期待读己写；如果系统无法做到全局即时可见，就应通过版本标记、请求会话版本或局部回源保证关键页面的可见性。

一种常见做法是让写请求返回变更版本，后续读请求携带该版本。读模型若尚未追上版本，可以短暂回源、等待有限时间、读取同一主分片，或者返回明确的处理中状态；不能无限阻塞，也不能静默承诺已经生效。版本等待必须受预算约束，否则“读己写”会变成一条不受控的同步链路。

对于允许陈旧的数据，应记录数据年龄和来源版本。页面可以展示旧的推荐候选，但价格、库存、权限和内容删除状态不能被普通缓存掩盖。这样“不一致”就从一个无法解释的异常，变成具有时间窗口、版本号和处理策略的业务状态。

8.8 方法论总结

8.8.1 十个判断句

1. 低延迟不是某个缓存或搜索引擎的能力，而是端到端预算、并行边界和降级策略共同产生的结果。
2. P99 比平均延迟更能暴露复杂读系统的真实体验；请求扇出越大，越需要治理最慢依赖和共享资源排队。
3. 查询模式决定读模型，写模型不应该被强行复用到所有读取场景；但读模型必须保留来源、版本和重建能力。
4. 能预计算的不要在线计算，能缓存的不要重复计算，但任何预计算和缓存都必须定义陈旧、失效、回源和恢复语义。
5. 搜索、推荐、广告和 Feed 都应拆成召回、过滤、排序、拼装和降级阶段；拆分是为了预算和治理，不是为了增加服务数量。
6. 候选数量、特征维度和排序层级都是资源预算，结果质量提升必须与额外 CPU、网络、存储和延迟成本一起评估。
7. 一致性要按字段和业务动作定义窗口，而不是对整个页面做笼统承诺；价格、库存、权限和删除状态应有更严格的在线校验。
8. 读系统的降级目标是保护核心结果和整体可用性，不是无条件保留所有增强功能；降级还必须带原因、等级和恢复条件。
9. 方案选型必须通过 ADR 说明获得了什么、牺牲了什么、失败后如何收敛，以及什么条件下重新评估。
10. 一次设计评审至少要追问：权威事实是什么、读模型如何生成、延迟预算在哪里、陈旧多久可接受、热点怎样保护、失败如何解释、结果如何重建。

8.8.2 读链路评审清单

8.8.3 一句话表达

低延迟与复杂读系统设计的核心，不是让所有请求实时回源并现场完成全部计算，而是围绕查询模式构建派生读模型，用索引、缓存、预计算、分层排序、延迟预算和可控降级，把复杂结果稳定地压进用户可接受的时间窗口。

8.9 参考资料

[1] Jeffrey Dean, Luiz André Barroso, “The Tail at Scale”, Communications of the ACM, 2013。

[2] Martin Kleppmann, Chris Riccomini, Designing Data-Intensive Applications, 2nd Edition, O’Reilly, 2026。

[3] Jeffrey Dean, Sanjay Ghemawat, “MapReduce: Simplified Data Processing on Large Clusters”, OSDI, 2004。

[4] Rajesh Nishtala et al., “Scaling Memcache at Facebook”, 10th USENIX Symposium on Networked Systems Design and Implementation, 2013。

[5] Nathan Bronson et al., “TAO: Facebook’s Distributed Data Store for the Social Graph”, 2013 USENIX Annual Technical Conference, 2013。

[6] Paul Covington, Jay Adams, Emre Sargin, “Deep Neural Networks for YouTube Recommendations”, ACM Conference on Recommender Systems, 2016。

[7] Martin Fowler, “CQRS”, Martin Fowler’s Bliki。

[8] Google SRE, “Handling Overload”, Site Reliability Engineering。

[9] Google SRE, “Addressing Cascading Failures”, Site Reliability Engineering。

[10] AWS, “REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies”, AWS Well-Architected Framework。

[11] Elastic, “Paginate search results”, Elasticsearch Reference。

[12] Redis, “Redis cache-aside”, Redis Documentation。

[13] OpenTelemetry, “Documentation”, OpenTelemetry Project。

[14] 美团技术团队，《多业务建模在美团搜索排序中的实践》，2021。

[15] 美团技术团队，《深入浅出排序学习：写给程序员的算法系统开发实践》，2018。

[16] 美团技术团队，《美团点评旅游搜索召回策略的演进》，2017。

[17] 腾讯云开发者社区，《业内推荐系统架构介绍》，2019。

[18] 腾讯云开发者社区，《推荐系统的召回》，2018。

[19] 美团技术团队，《美团综合业务推荐系统的质量模型及实践》，2022。

[20] 阿里云开发者社区，《深入解析 Redis 缓存击穿穿透雪崩的解决方案》，2024。

第 9 章 高并发写与热点场景系统设计方法论：秒杀、社交互动与流量洪峰处理

当系统面对秒杀、社交点赞、评论洪峰、直播互动、抢票、短时间上传等场景时，设计重点不再只是单次写入是否成功，而是如何在极端流量下保护入口、隔离热点、控制写入速率，并让用户看到的结果与最终事实安全收敛。

第 7 章保护不可出错的业务事实，第 8 章保护复杂读路径和延迟预算。本章讨论第三类问题：写入请求会在很短时间内集中爆发，且大量请求可能竞争同一个库存、同一个热门对象、同一个分区或同一个活动窗口。

这类系统不能只用“扩容”回答。扩容解决的是总资源不足，但无法自动解决单 Key 热点、库存唯一性、无上限重试、队列无限增长和用户结果不明确。真正的设计顺序应当是：

先定义用户和业务要看到的结果，再控制进入量；先隔离热点，再决定哪些动作同步完成；最后通过异步处理、幂等、补偿和对账把结果收敛到权威事实。

9.1 问题定义：高并发写不是一个单一问题

9.1.1 五个设计轴

高并发写场景至少包含五个不同的设计轴。它们相互影响，却不能混为一个“TPS 不够”的问题：

平均 TPS 只能描述总量，不能描述这些请求是否集中在一个 Key、一个分区或一个锁上。系统可能有足够的总 CPU，却因为一个热点行或一个队列分区先崩溃。反过来，一个写入总量很大的行为流，如果能够均匀分区、允许批量落库，可能比少量但集中竞争单行库存的请求更容易扩展。这种“总量、局部性和一致性同时约束吞吐”的视角，也是数据密集型系统设计中反复出现的基本判断。[1]

这类场景中有一个重要背景：常规系统的写路径通常很直接——请求进来、鉴权、校验、写数据库、同步返回。它在日常流量下有明显优势：链路短、语义直观、排障简单。但在洪峰场景中，数据库会同时承受连接数、行锁、索引更新、日志刷写和下游事务等待，最终事实存储被迫充当流量入口。此时即使增加应用实例，也只是让更多请求更快地撞向同一个热点资源。

9.1.2 同步成功和最终完成不是同一件事

高峰场景中，用户常常只需要快速知道请求是否被接受，而不是要求所有后端动作在一次请求内完成。系统应明确区分以下结果：

• 已成功：核心事实已经完成，结果可以直接信任。
• 已受理：请求已经通过准入，后续会异步处理。
• 排队中：请求尚未获得处理资格，但仍在等待。
• 处理中：后端已经开始执行，最终结果尚未确定。
• 失败：系统明确拒绝或执行失败，用户可以看到原因和后续动作。
• 待确认：请求可能已经产生副作用，但当前无法确认，需要查询、重试或人工处理。

如果接口只返回一个模糊的“成功”，用户和下游系统都会把“请求被接收”误认为“库存已扣减、订单已创建或评论已发布”。后续一旦发生超时，客户端可能再次提交，运营人员也无法判断应该补单、退款还是释放库存。可靠的异步接口通常返回业务对象 ID、当前状态、状态查询地址、重试建议和幂等键，而不是只返回一个 HTTP 200。

在 HTTP 接口中，超过准入速率时可以使用 429 Too Many Requests 表达请求被限流，并在适合的场景下通过 Retry-After 告知客户端等待时间；RFC 6585 同时指出，服务端并不必须使用同一种计数维度，可以按用户、资源或整个服务计算限额。[8] 这意味着 429 只是协议层结果，真正的设计仍然要回答“按什么限”“拒绝是否可重试”“重试是否会改变业务结果”。

9.1.3 本章的范围与非目标

本章聚焦：

1. 如何识别突发流量、单 Key 热点和持续写入瓶颈。
2. 如何设计准入、限流、排队、预处理、异步落库和背压。
3. 如何在热点场景中保护库存、计数、顺序、公平性和用户结果语义。
4. 如何处理队列积压、重复消息、快速预处理层故障、写库失败和最终对账。

上传文件本身更适合使用对象存储和异步媒体处理；本章只讨论上传任务元数据、任务状态和热点任务调度，不把文件传输和数据库写入混成一个问题。实时音视频、搜索索引和大规模数据分析也有各自的写入模型，本章只抽取它们与洪峰、热点和最终收敛相关的共同方法。

Redis 的数据结构、缓存和集群边界可参见后端面试基础知识题单中的 Redis 主题，消息分区、消费和积压治理可参见后端面试基础知识题单中的 Kafka 主题，库存权威事实则可参见库存系统实战。本章关注这些基础设施如何组合成抗洪峰的写入方法论，而不是重新介绍某一个中间件的全部 API。把消息、事务和状态迁移视为可以组合的模式，而不是把某个产品名称当成方案本身，符合企业集成模式所强调的“上下文决定模式”。[5]

9.2 约束与指标：先算清到达速率、处理速率和可接受等待

9.2.1 入口速率和服务速率

用 λ 表示请求到达速率，用 μ 表示稳定处理速率。当 λ 长时间大于 μ 时，队列一定会增长；当队列达到容量上限后，系统只能拒绝、丢弃、降级或把压力传播到更危险的下游。队列只能把时间上的波峰变得平滑，不能把长期能力不足变成能力充足。

一个用于讨论的容量示例如下，数字只是设计假设，不是通用标准：

活动峰值到达：100,000 req/s
入口准入能力：20,000 req/s
异步处理能力：5,000 req/s
队列容量：600,000 条

如果 100,000 req/s 持续五分钟，而消费者只有 5,000 req/s，即使入口只接受 20,000 req/s，队列仍会以 15,000 条每秒的速度增长，约 300 秒后新增积压达到 4,500,000 条，远超 600,000 条容量。若系统在第 30 秒发现积压并立刻拒绝新请求，队列仍然需要约 120 秒才能消化原有积压；若消费者处理速率只能提升到 10,000 req/s，恢复时间还会更长。排队设计必须同时给出最大积压、最大等待时间、满队列策略和恢复速率。

可以用近似公式帮助评审：

积压变化率 = 到达速率 - 有效处理速率
预计等待时间 ≈ 当前积压量 / 有效处理速率
清空时间 = 当前积压量 / (恢复后的处理速率 - 恢复期间的到达速率)

其中“有效处理速率”不能只看消费者线程数，还要扣除失败重试、数据库锁等待、限流、死信和下游超时的成本。如果消费者因为热点行锁把一半时间耗在等待上，表面上的并发数并不能代表真正的业务完成速率。

9.2.2 容量指标不能只有 QPS

Google SRE 对过载的总结特别强调，不同请求可能消耗完全不同的 CPU、内存、线程、网络或后端资源，用单一 QPS 作为能力指标很容易误判。[2] 本章可以把指标分成七组：

指标还要带上维度：活动、租户、用户等级、资源 ID、分区、错误类型和版本。只看全局平均值会掩盖“全站很健康但一个热门商品已经无法下单”的情况；只看成功率又会掩盖服务端为了保护系统而拒绝了大量请求的事实。

9.2.3 用户承诺必须可计算

如果系统承诺“排队后一定有机会成功”，就必须有队列容量、资格有效期和处理时限；如果系统承诺“提交成功即占库存”，就必须让库存事实在成功响应前可验证；如果系统只承诺“已受理”，就必须提供查询接口、状态变化通知和超时处理。承诺越强，同步链路要保护的事实越多，吞吐和可降级空间通常越小。

可以把业务承诺写成一个简单的契约表：

高峰场景最危险的不是拒绝，而是给出超过系统能力的承诺。对用户明确说“当前未获得资格”，往往比先返回成功、数分钟后再解释订单不存在更容易恢复信任。

9.3 核心模型：准入、缓冲、热点、事实和收敛

9.3.1 准入控制优先于后端扩容

准入控制回答“谁能进入系统”。它至少包括用户级频控、资源级频控、活动级全局限流、令牌或资格预发放、租户与风险等级分级，以及根据后端利用率动态拒绝。入口保护的对象不只是 API 服务器，还包括连接池、缓存、消息代理、数据库和任何拥有有限并发槽位的下游。

令牌桶适合控制平均速率并允许有限突发；漏桶适合把请求平滑成较稳定的处理速率；固定窗口实现简单但窗口边界可能形成双倍突发；滑动窗口更准确但需要更多存储和计算。Sentinel 的中文文档把流量控制、排队等待、系统负载保护和热点参数限流分成不同能力，并强调应结合 QPS、并发线程、平均 RT、CPU 或 Load 等运行信号进行保护。[14] 这说明限流算法只是实现细节，关键是限流维度、信号来源和超限后的结果语义。

入口通常需要多层限流：先按 IP、设备或用户阻挡明显的异常流量，再按活动和资源控制总量，最后按下游实际容量控制进入队列的速度。层层限流不能简单相乘，否则会出现一个入口允许 10,000 req/s、活动允许 5,000 req/s、热点商品允许 1,000 req/s，但因为重试和预热同时发生，最终仍然超过消息、缓存或数据库的有效能力。

9.3.2 热点需要分类处理

分片不是万能药。如果所有请求争夺同一个商品的剩余库存，简单把请求分到多个分片可能破坏库存唯一性；必须先改变资源分配模型，例如预发放资格、分段库存或按时间窗口分配令牌。相反，对于点赞计数，写入可以按内容 ID 与桶号打散，展示时再合并；这种方案牺牲的是读取和重算复杂度，而不是库存唯一性。

热点还会动态变化。活动开始前可以按历史数据预热，但真正开场后 Top Key、Top 分区和最老队列消息可能迅速改变。因此热点观测应同时支持实时 Top K 和历史趋势，隔离策略也要能动态生效。否则为了防止未知热点而给每个资源都配置独立队列，会让系统的运维成本和资源空置率先失控。

9.3.3 快速预处理层不是最终事实源

Redis、内存令牌和边缘限流适合做快速判断：是否有资格、是否重复、是否还有预分配额度、是否需要进入队列。Redis Lua 脚本在服务器端原子执行，脚本执行期间其效果具有原子性，适合把“检查额度—扣减—记录请求”这类短操作放在同一原子步骤中。[11] 但原子执行不等于业务事实已经持久化，也不等于跨数据库、消息系统和支付系统的事务已经完成。

预处理层获得低延迟和高吞吐，牺牲的是持久化语义、跨系统事务和长期可审计性。因此每次预处理都必须生成业务 ID，并把预扣、资格、版本和过期时间写入可恢复的受理记录。后续事实层应能够根据业务 ID 查询、重放、释放或补偿，而不能只有一个无法解释的缓存计数。

快速层与事实层之间还要定义失败顺序。例如“Redis 预扣成功、受理记录写入失败”时，系统不能假设这份额度自动存在；可以采用先写受理记录再预扣、短期补偿扫描预扣记录，或者使用带状态的令牌表。每种方案都有成本，但都比把 Redis 数字直接当成库存账本更容易审计。

9.3.4 异步链路必须有背压

消息队列是缓冲器，不是无限仓库。背压意味着后端处理能力下降时，入口能感知并降低接收量，而不是继续把更多请求塞进队列。队列必须定义最大长度、消息最大存活时间、消费超时、重试上限、死信策略、优先级、可丢弃事件规则和恢复速率。

不同事件要使用不同的可靠性等级：

如果队列已经接近上限，入口应快速返回“暂不可受理”或降低业务等级，而不是让请求等待一个注定超时的连接。Redis Streams 的消费者组通过待处理列表、确认和重新认领机制表达了类似的恢复边界，但确认并不等于业务副作用天然幂等，业务层仍需保存处理状态。[12] 消费者恢复后也不能立即把最大并发打满，应该逐步升速，否则积压清理本身会形成第二次洪峰。

9.3.5 异步状态机和幂等键

异步写入必须把“请求 ID”“业务对象 ID”“消息 ID”和“幂等键”区分开。请求 ID 用于追踪一次客户端请求，业务对象 ID 用于查询订单或任务，消息 ID 用于识别一次投递，幂等键用于识别同一个业务动作。四者混用会导致重试时无法判断到底是同一次动作，还是同一对象上的新动作。

受理记录可以采用如下状态：

已接收 → 已排队 → 处理中 → 成功
                     ├→ 失败
                     ├→ 待重试
                     └→ 待人工

状态迁移必须带版本或条件更新。重复消费成功状态时返回已有结果；重复消费失败状态时不能无条件重新执行；过期消息到达时，应根据业务时间和当前版本决定丢弃、补偿或人工处理。状态机还要区分“业务失败”和“技术未知”：前者可以给用户稳定的失败结论，后者不能在未查询事实前直接告诉用户“失败”。

不要把“恰好一次投递”当成异步系统的默认前提。Kafka 官方文档将至多一次、至少一次和恰好一次区分为不同的投递语义，并指出端到端的恰好一次需要生产、处理和输出链路共同满足条件。[13] 工程上更普遍的做法是接受消息可能重复，把副作用放进可提交的本地事务，用唯一约束、处理记录和状态条件保证重复执行不会重复产生业务结果。Idempotent Consumer 模式明确建议把已处理消息的 ID 与业务更新放在同一事务边界中；重复消息到达时，业务结果应与第一次处理相同，而不是依赖消息代理替应用保证业务唯一性。[7]

9.4 参考架构：把洪峰挡在最终事实存储之前

9.4.1 通用写入链路

高并发写系统可以拆成六层：

客户端 / 活动入口
  → 网关鉴权、风控、幂等和准入
  → 快速预处理层：令牌、资格、去重、预扣
  → 队列或缓冲层：按资源、租户或房间分区
  → 工作层：按可承受速率执行本地事务
  → 权威存储：订单、库存、账本、互动事实
  → 查询、通知、对账、补偿和人工接管

入口受理层只做必须快速完成的动作：校验身份、判断资格、写入受理记录、生成业务 ID、返回状态。订单创建、库存确认、评论审核和媒体处理可以异步执行，但必须能够被查询和重放。工作层要有独立的并发上限和超时，不能因为队列里消息很多就无限增加消费者。

如果业务事实和消息发送必须同时成立，可以把事件写入同一数据库事务中的 Outbox，再由独立 relay 发布。Transactional Outbox 的核心是避免“数据库提交了但消息没发出去”或“消息发出但数据库回滚”的不一致；但 relay 在发布后崩溃仍可能重复发送，因此消费者仍然需要幂等。[6] 这比把消息发送直接塞在数据库事务中更容易在故障时重试和审计。

9.4.2 分区和队列设计

队列分区键应根据业务一致性选择：库存可以按资源 ID 或活动 ID 分区，社交互动可以按对象 ID 分桶，用户任务可以按用户 ID 或租户 ID 分区。分区键决定顺序、热点和扩展性，不能只为了均匀 Hash 而忽略业务约束。

分区设计通常需要在三种能力之间取舍：同一 Key 的顺序、不同 Key 的并行度和单分区的热点上限。严格按商品 ID 分区可以简化库存顺序，但一个爆款商品会锁住一个分区；按商品 ID 加桶号可以提高并行度，却要求业务层解决同一库存的竞争。RocketMQ 的顺序消息文档也强调，顺序通常按消息组定义，同一组可以保证局部顺序，不同组则可以并行；顺序消费还受到生产串行、消费确认和有限重试等条件约束。[16]

对单个热点资源，可以采用专属队列、分段令牌或串行消费者；对长尾资源，则可以共享普通队列。热点发现后进行动态隔离，通常比预先为所有资源配置独立队列更节省成本。动态隔离必须有迁移边界：切换前后的消息版本、重复消费、旧消费者停止时间和未确认消息归属都要有明确规则。

9.4.3 最终事实和展示结果分离

点赞事实可以按“用户 + 内容”唯一写入，点赞总数可以异步聚合；评论原文需要持久化和审核，评论列表可以延迟建立索引；直播弹幕可以允许丢弃低价值事件，但抽奖资格和中奖结果不能丢。这里的关键不是“所有内容都最终一致”，而是分别定义事实、投影和可重建边界。

可以把一个业务动作拆成三类数据：

1. 权威事实：决定库存、订单、资格、账本和用户行为是否发生。
2. 派生投影：计数、列表、搜索索引、推荐特征和通知状态，可以由事实重建。
3. 运行记录：队列偏移、重试次数、处理耗时、最后错误和人工任务，用于恢复和治理。

事实必须优先保证唯一性和可审计性；投影优先保证可重算和延迟可控；运行记录优先保证故障时有人知道“下一步该做什么”。不能因为所有请求都叫“写入”，就给它们相同的可靠性等级，也不能把一个不可重建的计数器当成事实层。

9.5 方案选型：用 ADR 说明吞吐、正确性和体验的取舍

9.5.1 方案对比

选型时先问“哪个约束不能破坏”，再问“哪个组件最快”。如果库存唯一性不能破坏，就不能因为 Redis 延迟低而把 Redis 数字直接当成订单事实；如果互动消息可以丢弃，就没有必要为每条弹幕设计和订单相同的重试链路；如果公平性比瞬时吞吐更重要，就要把排队和抽签规则写成用户可理解的业务规则。

9.5.2 示例 ADR：秒杀采用资格准入、预扣和异步下单

背景：活动开始瞬间有大量请求竞争少量库存；库存不能超卖，但用户不要求在一次请求内完成支付和订单全部写入。

决策驱动因素：需要保护数据库，控制单商品热点，防止用户重复提交，并让失败预扣能够回补；同时要给用户一个可查询的明确结果。还要控制机器人和脚本流量，避免把网络到达时间误当成唯一公平依据。

候选方案：请求直接扣数据库、数据库内部排队、Redis 预扣后同步下单、资格令牌 + Redis 预扣 + MQ 异步下单、预分配库存到多个逻辑桶。

最终决策：入口先完成用户资格、风控和频控；通过令牌限制进入量；快速预处理层执行用户去重和库存预扣；成功请求进入按商品或活动分区的队列；消费者创建订单并在权威库存中确认；任何中间失败都通过状态机和补偿回补。受理记录与业务事实使用同一个业务请求 ID 关联，支付超时和订单创建失败分别处理。

获得的能力：

• 入口可以拒绝明显无资格、重复或超过容量的请求。
• 数据库不直接承受第一波洪峰，热点商品可以按队列或分段库存隔离。
• 用户可以先获得受理结果，再通过订单查询最终状态。
• 订单、库存和补偿都可以使用业务 ID 做幂等。
• 失败预扣、未支付订单和消息死信都有明确的回收路径。

主动牺牲的能力：

• 请求受理成功不等于订单已经创建成功。
• 用户可能经历排队、处理中和待确认状态。
• Redis 预扣、队列和数据库事实之间存在收敛窗口。
• 系统增加了队列、回补、对账、风控和人工处理成本。

已接受风险：预扣成功但订单创建失败时需要及时回补；队列积压会延迟用户结果；Redis 或消息系统故障时需要进入受控拒绝或降级模式；如果资格规则不透明，用户可能认为排队不公平。

验证指标：超卖差异为零，重复订单为零，预扣回补延迟在目标内，队列最老消息年龄可控，入口拒绝率可解释，用户查询状态与最终订单事实一致，异常流量拦截率和不同用户群体的成功概率处于可接受范围。

重新评估条件：单商品热点仍超过单队列能力、回补和对账成本持续上升、活动公平性要求改变，或库存必须提供更强的同步确认语义。

9.5.3 选型不应把“全部接住”当成目标

在供给远小于需求的场景中，让所有请求进入系统并不代表服务质量高。系统应该尽早拒绝没有资格、重复或超过处理能力的请求，把有限资源留给能够产生有效业务结果的请求。RFC 6585 对 429 的定义也允许服务端在响应中说明限制原因或等待时间，这为“拒绝但可解释”提供了协议层基础。[8]

Google SRE 对过载和级联故障的总结强调，系统需要在过载时快速拒绝、提供降级结果并进行负载削减；如果每一层都在失败后立即重试，单个用户请求可能在下游被放大成多次调用，最终让健康实例继续减少。[3] 因此重试预算应该由一个明确的层负责，客户端、网关、服务和数据库驱动不能各自默认重试。

9.6 完整案例：从秒杀受理到最终库存事实

9.6.1 正常链路

1. 活动服务发布商品、库存窗口、用户资格规则、队列容量和过期时间。
2. 用户请求进入网关，完成鉴权、风控、频控和资格判断。
3. 系统为用户生成一次业务请求 ID，并在快速层完成去重。
4. 预扣层判断令牌和可用预扣额度，失败则快速返回未获得资格。
5. 预扣成功后写入受理记录，并把请求放入按商品分区的队列。
6. 订单消费者消费消息，在本地事务中写入订单、库存确认记录和 Outbox 事件。
7. 订单进入待支付，支付成功后进入已支付和已确认状态。
8. 创建订单失败、支付超时或用户取消时，触发库存释放和预扣回补。
9. 查询服务从受理记录和订单事实生成用户可见状态，通知服务只负责投影，不改变库存事实。

正常链路中最容易被忽略的是第 6 步的边界：消费者确认消息前，订单事实、处理记录和需要发送的后续事件应当形成可恢复的提交点；如果业务更新提交了但消息确认失败，消息会再次投递，此时唯一约束和状态条件必须让第二次处理变成查询已有结果，而不是再次扣库存。把本地事务、事件外发和消费者幂等组合起来，是《凤凰架构》中反复讨论的分布式一致性实践之一。[19]

9.6.2 重复、超时和乱序

用户重复点击时，入口幂等键保证只获得一个受理结果；消息重复消费时，订单服务使用业务请求 ID 或唯一订单约束；预扣成功但订单响应超时时，不能重新申请一份库存，而应查询原请求状态。AWS 的幂等 API 设计也把“客户端不知道服务端是否已经产生副作用”视为重试的基本问题，建议使用客户端提供的唯一 token 让服务端返回同一结果。[9] 从客户端请求角度看，这也是 Idempotent Receiver 模式要解决的问题：请求可能已经完成但响应丢失，服务端应根据唯一请求标识返回已保存结果，而不是再次执行。[20]

支付超时与订单创建失败是不同故障：前者可能需要等待支付状态并最终关闭订单，后者需要立即释放预扣。事件乱序时，状态机必须根据版本或允许迁移表拒绝旧事件，不能简单使用“最后收到的消息覆盖当前状态”。例如已支付订单收到旧的“待支付”事件时，旧事件只能记录为过期消息，不能把订单倒退。

重试也必须分层控制。AWS 的可靠性指南建议使用指数退避、随机抖动和最大重试次数，以避免多个客户端在同一时刻重复冲击已经限流的服务。[10] 对库存和订单这样的非幂等业务，还要先判断“是否已产生事实”，再决定是否重试；对网络超时不能直接假设业务失败。

9.6.3 对账、回补与未知结果

秒杀系统至少需要两条恢复任务：一条扫描“预扣存在但受理记录缺失或未推进”的记录，另一条扫描“订单关闭但预扣未释放”的记录。扫描任务不能简单全表重试，而应根据租约、版本和最后更新时间领取任务，避免多个补偿 worker 同时操作同一业务对象。

库存对账可以用下式表达，但每一项都要有来源和时间窗口：

可解释库存 = 初始库存 - 已确认订单 - 有效预扣 + 已释放预扣 + 人工调整
库存差异 = 权威库存 - 可解释库存

当差异不为零时，先冻结自动补偿，保留原始事件、订单和操作日志，再判断是重复扣减、漏记回补、过期预扣未释放还是人工调整未入账。直接修改缓存数字只能掩盖差异，不能证明系统恢复正确。

9.6.4 社交互动变体

点赞通常需要保证“同一用户对同一内容最多一条有效点赞事实”，但展示计数可以异步聚合。可以将事实表和计数表分离：事实表使用唯一约束，计数事件进入队列，聚合任务批量更新计数，定期用事实表重算计数。取消点赞不能简单把计数减一，因为重复事件、乱序事件和事实删除可能同时发生；更稳妥的方式是让聚合器依据事实变化或版本计算净变化。

评论需要区分受理、审核、发布和删除。热门内容上的评论写入可以按对象分桶，但楼层顺序、审核状态和删除传播必须有明确规则。若产品只要求“按审核通过时间展示”，就不应承诺提交时间就是楼层顺序；若必须保持楼层连续，则需要一个可序列化的楼层分配器，并接受它成为新的热点。把所有评论直接写入同一张热点表，通常会让数据库成为第一道洪峰吸收器。

9.6.5 直播、上传与抢票变体

直播互动应按房间隔离资源，热房间使用独立队列和限额；弹幕可以丢弃或合并低价值事件，但抽奖资格、红包结果和订单不能采用同样的丢弃策略。房间内的消息顺序也要区分：弹幕展示可以近似按到达顺序，抽奖资格则必须按规则和事件版本决定结果。

短时间上传的热点不一定是数据库，而可能是签名服务、对象存储带宽、转码队列或元数据表。入口可以先发放上传凭证，把文件流量移到对象存储，再异步写入媒体任务状态；任务状态需要幂等，转码结果需要版本，失败任务需要死信和人工重试。这样恢复了“上传元数据可异步处理”的边界，也避免把文件字节流和业务事实塞进同一个事务。

抢票除了库存正确性，还要处理公平性和唯一性：用户资格、排队顺序、座位锁定 TTL、超时释放、防刷和退票回补都需要进入状态模型。它与秒杀共用削峰和预占能力，但不能简单复制“谁先到谁先成功”的实现，因为入口网络差异和重试可能改变用户顺序。

9.6.6 抢票中的公平性 ADR

如果采用严格到达顺序，系统需要可信的排队时间、单一入口和稳定的排序依据；它获得了顺序可解释性，但牺牲了跨地域网络公平，且重试和代理会影响到达时间。如果采用资格池后随机抽签，系统获得了更强的抗刷和机会公平，牺牲了用户对“先来先得”的直观预期。如果采用分批放号，系统获得了更好的热点控制和可运营性，但必须解释批次、等待和失效规则。

因此抢票的 ADR 不能只记录“采用排队系统”，而要明确公平性的定义：按请求到达、按资格、按批次、按随机抽签，还是按业务优先级。公平性指标可以包括不同用户群体的进入概率、排队等待分布、重复资格拦截率、异常流量占比、座位锁定超时率和退票回补延迟。公平性不是单独的反作弊功能，而是准入、排序、重试和结果通知共同形成的业务语义。

9.7 故障与治理：高峰是常态，失败必须可控

9.7.1 队列满和消费者变慢

队列达到上限时，系统必须按业务价值做决策：拒绝新请求、只保留高优先级、合并重复事件、丢弃可重建事件，或暂停非核心功能。不能无限增加重试，因为重试会把已过载的消费者再次打满。对于队列满的结果，要区分“用户不符合业务资格”和“系统暂时没有容量”，两者的提示、监控和后续动作不同。

消息消费者应记录处理耗时、重试次数、最后错误、业务状态和事件版本。RocketMQ 的消费重试文档把消息从就绪、处理中、待重试到死信等状态区分开，并明确不同消息类型的重试策略；这类状态机思路适合迁移到自建消费者治理中。[17] RocketMQ 的发送重试和流控文档还提醒，客户端超时后无法确定服务端是否已经处理，发送重试可能产生重复消息，因此业务方必须自行处理重复问题。[18] 处理失败后，必须判断是可重试的临时错误、不可重试的业务错误、数据损坏，还是未知结果。所有错误都重试会把死循环隐藏在队列里。

9.7.2 Redis 或快速预处理层失败

快速层失败时，不能直接绕过保护层把所有请求打到数据库。可选策略包括：受控拒绝、进入低容量保护队列、切换到预分配令牌、只允许查询已有状态，或短暂关闭活动入口。Sentinel 文档中关于系统自适应保护和热点参数限流的思路说明，入口保护应结合整体负载与局部热点，而不是只看某一个接口是否返回成功。[15]

恢复后必须核对预扣记录、订单事实和权威库存，不能因为 Redis 恢复就假设之前的预扣全部有效。预处理层的可用性目标不能高于事实层的可恢复性；如果无法证明一份令牌的来源和状态，就宁可把它标记为待核对，也不要静默再次发放。

9.7.3 重试风暴、存储故障和级联失败

重试风暴通常来自三个叠加因素：客户端没有预算、服务端超时阈值过长、多个调用层各自重试。一次用户请求可能经过网关、订单服务、库存服务和数据库驱动，每层重试三次，最坏情况下会把一次请求放大成几十次下游尝试。治理办法包括只让一个层拥有主要重试责任、为每次请求携带剩余 deadline、对不可确认结果使用查询而不是创建重试，以及把限流错误与业务失败区分开。

Google SRE 对级联故障的分析指出，服务在资源耗尽后即使把流量稍微降下来，也可能因为健康实例减少而无法恢复；负载削减、快速失败、降级和真实压测要作为同一个恢复设计来验证。[3] 因此数据库连接池耗尽时，应用不应继续等待更长时间；消息代理异常时，也不应让每个请求同步等待发送结果。失败要尽早暴露在最靠近入口、最容易恢复的边界。

9.7.4 库存和计数对账

库存对账至少比较初始库存、预扣记录、订单确认、取消释放、人工调整和最终库存。计数对账则比较事实记录与聚合结果，发现差异时优先从事实重算，不直接手工修改展示计数。对账任务也属于写入系统，必须有时间窗口、租约、幂等和审计记录，否则对账本身可能制造新的重复变更。

对于可重建投影，可以把修复过程设计成“生成新版本—校验—切换指针”，而不是在原表上边读边改。对于库存和账本这类权威事实，修复必须产生人工审批或明确的补偿事件；任何直接改数操作都应记录操作者、原因、旧值、新值和关联工单。

9.7.5 热点和过载演练

发布前要验证：热点集中在一个 Key、一个分区或一个消费者时，系统是否会隔离；队列满时用户看到什么；重试是否有上限；Redis、数据库、消息系统分别失败时是否进入安全模式。压测不能只测平均流量，还要测峰值斜坡、瞬时尖峰、热点倾斜、重复请求、慢消费者、网络超时和恢复过程。

Google SRE 建议使用真实负载测试验证系统的过载点，因为服务在接近资源上限时经常出现非线性延迟、重试放大和级联故障，而不是简单地线性变慢。[4] 演练结果要记录“在哪个资源、哪个指标、哪条保护规则先触发”，而不是只给出一个最大 QPS。

9.7.6 发布、灰度和容量复盘

高并发写功能不能只在活动当天验证。发布前应使用逐步放量、影子流量和可回退配置验证入口限流、令牌发放、队列分区和消费者扩容。核心开关应支持快速关闭活动、降低准入速率、暂停非核心消费者、切换只读查询和延长处理窗口。变化大的消费者版本要保证旧消息可以解析，或者在发布前清空并隔离不兼容的队列。

容量复盘不能只记录“最终扛住了多少 QPS”，还要记录峰值到达曲线、真实资源消耗、最热 Key、最慢队列、拒绝原因、重试放大倍数、降级时间、最终积压清空时间和对账差异。下一次活动应根据这些数据重新计算入口、队列和消费者容量，而不是继续使用过时的 TPS 经验值。

9.7.7 用户查询和运营处置

异步结果必须提供稳定的查询接口，例如根据业务对象 ID 查询当前状态、最近一次失败原因、预计下一次处理时间和是否需要用户重试。运营侧则需要看到活动级准入量、资格池消耗、队列积压、回补数量、死信数量和人工任务，而不是只看到接口成功率。

当系统进入保护模式时，用户提示、运营开关和后台指标必须使用同一套状态定义。否则前端显示“抢购成功”、后台显示“排队中”、订单系统显示“未创建”，最终会把技术不确定性转化为投诉和人工对账。未知状态要有明确的“查询中”或“待确认”界面，而不是让用户靠重复点击猜测结果。

9.8 方法论总结

9.8.1 八个判断句

1. 高并发写系统的首要目标不是把所有请求都处理完，而是让系统在洪峰下仍然可控。
2. 突发流量、总写入量和单 Key 热点是不同问题，不能用一个扩容方案覆盖。
3. 先控进入量，再谈处理量；先保护热点，再谈整体吞吐。
4. 入口返回“已受理”时，必须提供可查询的状态、过期规则和最终结果。
5. 队列可以削峰，但不能消除处理能力不足；最大积压和最长等待时间必须可计算。
6. Redis 预扣、令牌和快速计数是保护层，不是订单、库存和账本的最终事实。
7. 重试、重复消息、超时和乱序是正常输入，幂等和状态机必须内建。
8. ADR 必须说明方案获得了什么、牺牲了什么、接受了什么风险，以及什么条件下需要重新评估。

9.8.2 评审清单与迁移边界

评审一个高并发写方案时，可以沿着以下顺序提问：

1. 峰值是瞬时尖峰、持续高流量，还是热点集中？三者的假设是否有测量或压测依据？
2. 入口最多允许多少请求进入，拒绝和排队分别意味着什么？队列满时谁先被牺牲？
3. 哪些数据是不可丢失的权威事实，哪些是可以合并、延迟或重建的投影？
4. 热点 Key、分区、锁、连接池和下游调用是否分别有指标和保护规则？
5. 客户端重试、消息重试、补偿重试是否共享预算？未知结果如何查询？
6. 快速预扣与最终事实之间有哪些状态，谁负责回补，回补失败如何进入人工流程？
7. 是否有一条完整的正常链路、重复链路、超时链路、乱序链路和恢复链路？
8. 是否用真实热点倾斜和故障恢复验证过，而不是只测均匀流量下的平均 QPS？

这套方法不要求所有系统都引入 Redis、MQ、分片或复杂的分布式事务。低流量、强同步、热点有限的业务可能直接写 OLTP 更合适；如果引入异步化后用户必须等待很久、无法查询结果，或者补偿成本高于同步处理，应该重新评估边界。方法论的目标是把不可避免的取舍显式化，而不是堆叠中间件名称。

9.8.3 一句话表达

高并发写与热点场景系统设计的核心，不是把后端数据库做成无限吞吐的洪峰吸收器，而是先定义结果承诺，再用准入、限流、队列、预处理和热点隔离保护系统，最后通过异步处理、幂等、补偿和对账让最终结果回到权威事实。

9.9 参考资料

[1] Martin Kleppmann、Chris Riccomini，《Designing Data-Intensive Applications, 2nd Edition》，O’Reilly，2026。

[2] Google SRE，“Handling Overload”，Site Reliability Engineering，Google，2017。

[3] Google SRE，“Addressing Cascading Failures”，Site Reliability Engineering，Google，2017。

[4] Google SRE，“Reliable Product Launches at Scale”，Site Reliability Engineering，Google，2017。

[5] Gregor Hohpe、Bobby Woolf，Enterprise Integration Patterns，Addison-Wesley，2003。

[6] Chris Richardson，“Transactional Outbox”，Microservices.io，访问：2026-09-21。

[7] Chris Richardson，“Idempotent Consumer”，Microservices.io，访问：2026-09-21。

[8] Mark Nottingham、Robert Fielding，RFC 6585: Additional HTTP Status Codes，RFC Editor，2012。

[9] Malcolm Featonby，“Making Retries Safe with Idempotent APIs”，Amazon Builders’ Library，访问：2026-09-21。

[10] Amazon Web Services，“Control and limit retry calls”，AWS Well-Architected Framework，2022。

[11] Redis，“Scripting with Lua”，Redis Documentation，访问：2026-09-21。

[12] Redis，“Redis Streams”，Redis Documentation，访问：2026-09-21。

[13] Apache Kafka，“Message Delivery Semantics”，Apache Kafka Documentation，访问：2026-09-21。

[14] Alibaba，“Sentinel 介绍”，Sentinel 中文文档，访问：2026-09-21。

[15] Alibaba，“热点参数限流”，Sentinel 中文文档，访问：2026-09-21。

[16] Apache RocketMQ，“顺序消息”，Apache RocketMQ 中文文档，访问：2026-09-21。

[17] Apache RocketMQ，“消费重试”，Apache RocketMQ 中文文档，访问：2026-09-21。

[18] Apache RocketMQ，“消息发送重试和流控机制”，Apache RocketMQ 中文文档，访问：2026-09-21。

[19] 周志明，《凤凰架构：构建可靠的大型分布式系统》，访问：2026-09-21。

[20] Unmesh Joshi，“Idempotent Receiver”，Patterns of Distributed Systems，Martin Fowler，2023。

第 10 章 电商系统全景图

本章定位：在读完第一部分的方法论之后，进入第二部分「电商系统设计实战」之前，用一张可落地的全景图把业务能力、应用系统、数据资产与技术基础设施对齐到同一坐标系。后续第 11 章至第 14 章将沿本章划定的边界逐域深入；第 4 章已经从方法论层面讨论了跨系统集成与一致性模式。

阅读建议：若你已熟悉 DDD 战略术语，可快速浏览 10.2 后进入 10.1 的图示；若你更习惯从接口与数据表入手，建议从 10.1.3 数据架构读起，再回到 10.1.1 校正业务语义。无论哪种路径，都请至少完成 10.4 的三条时序走读，因为后续各章的「集成小节」默认你已经知道主链路的参与者与先后次序。

本章产出物（可用于团队对齐）：

1. 一页 限界上下文图（10.1.1）贴在内网架构 wiki。
2. 一张 服务依赖图（10.1.2）导入架构治理工具（如 Backstage / 内部 CMDB）。
3. 一份 主数据清单（10.1.3 表格）作为数据 Owner 会议的输入。
4. 一套 集成模式评审话术（10.3）写进 RFC 模板。
5. 一张 十二系统职责表（10.5.1）作为新人 Onboarding 必读。

10.1 系统全景架构

中大型电商平台的架构讨论，如果只停留在「微服务拆分清单」，很容易失去业务语义；如果只停留在「业务功能列表」，又难以指导工程依赖与数据落点。实践中常用 EA（企业架构）+ 4A 的多视角方法并行：

下面四节分别给出图示与解读要点。图示刻意与后续各章的术语保持一致，便于你在阅读第 11 章至第 14 章时「对照地图」。

本章的阅读方式：不要把全景图当成服务清单，而要把它当成后续实战章节的索引地图。商品、库存、营销、计价、搜索、购物车、订单、支付、供给治理和供应商同步都会在后文展开；本章先把它们放到同一张业务地图上，帮助读者理解每个系统的职责、上游、下游和失败边界。

下面这张图先给出 Part 2 的功能全景索引图。它不试图一次讲完所有实现细节，而是回答四个更基础的问题：平台有哪些能力域、这些能力域如何分工、主链路如何推进、治理闭环如何反哺供给。读完这张图，再进入后面的业务架构、应用架构、数据架构和技术架构，会更容易建立“先有地图，再看局部”的阅读节奏。

flowchart LR
    A["供应商 / 商家<br/>入驻与资质<br/>基础商品 / 资源<br/>库存或券码供给<br/>价格与履约能力"]

    subgraph P["数字电商平台 / B2B2C 平台"]
        direction LR

        B["供给平台<br/>接入与同步<br/>Draft / Staging / QC<br/>批量导入与任务编排<br/>库存运营与供应商治理"]

        C["商品中心<br/>Resource / SPU / SKU<br/>Offer / Rule / Snapshot<br/>正式商品主数据<br/>交易前契约"]

        D["运营平台<br/>活动与促销<br/>CMS / 会场 / 分类<br/>搜索与流量运营<br/>上下架与曝光编排"]

        E["用户前台<br/>搜索导购<br/>详情与列表<br/>购物车与结算<br/>下单入口"]

        F["订单 / 履约 / 售后<br/>订单创建与支付<br/>履约编排与发货<br/>退款售后与补偿<br/>清结算与对账"]
    end

    U["消费者 / 用户"]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    U --> E

    G["质量巡检<br/>商品质量分 / 风险识别"]
    H["生命周期治理<br/>上下架 / 冻结 / 下线 / 回滚"]
    I["供应商同步治理<br/>Raw Snapshot / Checkpoint / 质量监控"]
    J["Outbox / DLQ / 补偿<br/>异常闭环 / 人工修复"]

    G --> B
    H --> B
    I --> B
    J --> B
    F -.异常、质量与售后信号回流.-> G

    K["主链路：把货组织成资产 → 把资产组织成销售 → 把销售沉淀成交易结果"]
    B -.-> K
    C -.-> K
    D -.-> K
    E -.-> K
    F -.-> K

术语对照（避免口语歧义）：

从单体到分布式的认知迁移：在单体时代，模块边界靠包名与 Code Review 维持；在分布式时代，网络边界会放大设计缺陷——原本一次函数调用的地方，变成了超时、重试与部分失败。因此全景章的价值，不在于「数有多少个微服务」，而在于为每个跨边界调用预先分配 一致性语义、超时预算与观测标签。当你在第 14 章阅读订单状态机时，应能指出：某次迁移对应 10.4.2 中的哪一步、失败时由谁补偿。

10.1.1 业务架构（DDD 视角）

从 DDD 战略设计看，电商平台的业务能力应被组织为一组限界上下文（Bounded Context）：每个上下文内部有独立的通用语言与生命周期；上下文之间通过显式关系（客户方 / 供应方、防腐层、发布语言等）协作。[1] 下图用「限界上下文 + 域分类」表达业务架构，颜色区分核心域、支撑域、通用域；此处沿用全书系统设计方法论中的分类，并侧重系统级映射。

flowchart TB
  subgraph Core["核心域（Core Domain）"]
    BC_Order["限界上下文：订单<br/>契约：订单号、状态机、履约编排"]
    BC_Pay["限界上下文：支付<br/>契约：支付单、渠道、清结算"]
    BC_Checkout["限界上下文：结算<br/>契约：试算、预占、拆单预览"]
    BC_Cart["限界上下文：购物车<br/>契约：行项目、会话合并"]
  end

  subgraph Support["支撑域（Supporting Domain）"]
    BC_Product["限界上下文：商品中心"]
    BC_Inv["限界上下文：库存"]
    BC_Price["限界上下文：计价"]
    BC_Mkt["限界上下文：营销"]
    BC_List["限界上下文：商品上架"]
    BC_Ops["限界上下文：B 端运营"]
    BC_Life["限界上下文：生命周期与供给治理"]
  end

  subgraph Generic["通用域（Generic Domain）"]
    BC_Search["限界上下文：搜索与导购"]
    BC_User["限界上下文：用户与会员（外采/标准能力）"]
    BC_Msg["限界上下文：消息通知（外采/标准能力）"]
  end

  BC_Cart --> BC_Checkout
  BC_Checkout --> BC_Order
  BC_Order --> BC_Pay

  BC_Checkout -.->|试算/ Hydrate| BC_Price
  BC_Checkout -.->|预占| BC_Inv
  BC_Checkout -.->|券与活动校验| BC_Mkt

  BC_Order -.->|快照与金额确认| BC_Price
  BC_Order -.->|库存确认/回退| BC_Inv
  BC_Order -.->|营销锁定与扣减| BC_Mkt
  BC_Order -.->|商品快照| BC_Product

  BC_List --> BC_Product
  BC_List --> BC_Inv
  BC_List --> BC_Price
  BC_Ops --> BC_Product
  BC_Ops --> BC_Inv
  BC_Ops --> BC_Mkt
  BC_Ops --> BC_Price
  BC_Life --> BC_Product
  BC_Life --> BC_List

  BC_Search -.->|发现与列表| BC_Product
  BC_User -.->|身份与权益| BC_Order
  BC_Msg -.->|异步触达| BC_Order

读图要点：

1. 核心域集中了「钱与承诺」相关的上下文：购物车暂存购买意图，结算把意图推进为可支付的约束集合（价格、库存、优惠），订单把承诺持久化为合同，支付完成资金侧的闭环。
2. 支撑域提供可售性、可算价、可营销、可供给四类「规则与主数据」能力；它们高度影响交易，但行业模式相对可参照。
3. 通用域中的搜索本书会在第 14 章深入，因其在工程上与商品、计价、库存的 Hydrate 编排强耦合；用户与消息等更常采购标准方案，在全景中保留接口位即可。

上下文映射（与第 1 章 DDD 部分衔接）：上图中实线箭头多表示「客户方依赖供应方」的下游调用关系；虚线表示「通过发布语言（Published Language）或 ACL 防腐」的弱耦合。[1][2] 落地时建议显式标出：

• 供应方（Upstream）：商品中心对「商品快照 ID」、计价系统对「价格快照版本」、库存对「预占凭证」拥有定义权。
• 客户方（Downstream）：订单与结算消费上述契约，但不应要求供应方暴露内部表结构。
• 防腐层（ACL）：对接供应商、旧单体或外采营销引擎时，把外部模型挡在边界之外，避免污染核心域通用语言。

答辩提示：业务架构图的表述模板已统一收录到附录 D 的相应核心案例。

10.1.2 应用架构（微服务视角）

应用架构关注可部署单元之间的依赖。原则是：依赖方向自上而下、由稳定侧指向易变侧，避免出现「基础数据服务回调订单服务」这类环。[3][4] 下图在典型分层架构上，补全 C 端读路径（搜索、购物车）与结算编排，并标注后续章节编号，便于索引。

flowchart TB
  subgraph L0["接入与 BFF"]
    GW[API Gateway / BFF]
  end

  subgraph L_read["读路径与暂存"]
    SearchSvc["搜索与导购服务<br/>第 14 章"]
    CartSvc["购物车服务<br/>第 14 章"]
  end

  subgraph L_data["主数据与规则基座"]
    ProductSvc["商品中心<br/>第 11 章"]
    InvSvc["库存系统<br/>第 12 章"]
    MktSvc["营销系统<br/>第 13 章"]
    PriceSvc["计价系统<br/>第 13 章"]
  end

  subgraph L_trade["交易编排与资金"]
    CheckoutSvc["结算编排服务<br/>第 14 章"]
    OrderSvc["订单系统<br/>第 14 章"]
    PaySvc["支付系统<br/>第 14 章"]
  end

  subgraph L_supply["供给与运营"]
    ListingSvc["商品上架<br/>第 11 章"]
    OpsSvc["供给与运营管理<br/>第 11 章"]
    LifeSvc["生命周期协调<br/>第 11 章"]
  end

  GW --> SearchSvc
  GW --> CartSvc
  GW --> CheckoutSvc
  GW --> OrderSvc
  GW --> PaySvc
  GW --> ListingSvc
  GW --> OpsSvc

  SearchSvc --> ProductSvc
  SearchSvc --> InvSvc
  SearchSvc --> PriceSvc
  CartSvc --> ProductSvc

  CheckoutSvc --> PriceSvc
  CheckoutSvc --> InvSvc
  CheckoutSvc --> MktSvc
  CheckoutSvc --> OrderSvc

  OrderSvc --> ProductSvc
  OrderSvc --> InvSvc
  OrderSvc --> MktSvc
  OrderSvc --> PriceSvc
  OrderSvc --> PaySvc

  ListingSvc --> ProductSvc
  ListingSvc --> InvSvc
  ListingSvc --> PriceSvc
  OpsSvc --> ProductSvc
  OpsSvc --> InvSvc
  OpsSvc --> MktSvc
  OpsSvc --> PriceSvc
  LifeSvc --> ProductSvc
  LifeSvc --> ListingSvc

依赖解读：

• 商品中心是多数读路径与订单快照的事实来源（System of Record for catalog）；库存、计价、营销在各自上下文内维护规则，但在创单链路上被订单编排调用。
• 结算服务常实现为独立部署的「长事务 / Saga 编排器」，在应用层与购物车解耦：购物车偏会话与展示，结算偏资源锁定与一致性门槛（详见第 14 章）。
• 上架、运营、生命周期在应用层可能合并为一个「供给平台」团队维护的多个服务，逻辑上仍建议按限界上下文拆分数据与发布节奏（第 11 章展开）。

典型调用链（便于与 10.4 对照）：

循环依赖治理：若发现「商品中心回调订单」一类需求，优先改为事件订阅或查询倒置（由订单侧拉取快照），而不是在数据层打开反向通道。

10.1.3 数据架构

数据架构回答三件事：主数据放哪、派生数据如何构建、事件与缓存如何对齐。下图描述一条典型的「写主库、异步投影、读多路」路径，与第 7 章 CQRS 和第 4 章 Outbox 思路衔接。

flowchart LR
  subgraph Writers["写入侧（Command Path）"]
    SVC_W[业务服务<br/>订单/商品/库存等]
    DB[(MySQL 集群<br/>事务边界内)]
    Outbox[(Outbox 表<br/>同库事务)]
  end

  subgraph Bus["集成与解耦"]
    MQ[Kafka / Pulsar<br/>领域事件总线]
    CDC[CDC 可选<br/>Binlog 流]
  end

  subgraph Readers["读取侧（Query Path）"]
    ES[(Elasticsearch<br/>搜索索引)]
    Redis[(Redis<br/>库存热点/购物车)]
    DW[(数仓 / OLAP<br/>分析投影)]
  end

  SVC_W -->|本地事务| DB
  SVC_W -->|同事务写入| Outbox
  Outbox -->|Relay| MQ
  DB -.->|可选| CDC
  MQ -->|商品变更订阅| ES
  MQ -->|库存变更| Redis
  MQ -->|订单事实| DW
  CDC --> ES

落地要点：

1. 订单、支付、商品主档等强一致实体以 MySQL（或同类）为权威存储；跨聚合协作优先 Outbox + 消息（见第 1 章 1.3.9），避免「双写」在故障时无法对账。
2. 搜索索引、推荐特征、报表属于派生视图，允许最终一致；延迟由业务容忍度与补偿任务共同约束。
3. 库存常见「Redis 扛热点 + MySQL 审计」的双存储形态，必须单写者（Single Writer）与周期对账（第 12 章）。

主数据与派生数据清单（评审用）：

数据所有权一句话：谁对「业务不变量」负责，谁就拥有该数据的写入 API；其余路径只能投影或引用。

离线数仓与实时数仓的边界：订单与支付事件进入数仓后，用于分析与风控建模，不得反向写回在线交易库作为业务依据；若运营需要「实时看板」，应通过专用 OLAP 或流式聚合服务读取消息总线，而不是直接查询订单主库拖垮 P99。若确需运营干预线上数据，应走带审批的正式 API 与审计日志，而不是「数仓导表回灌」。这类约束也是第 7 章上线前检查中「数据变更路径」的必审项。

10.1.4 技术架构

技术架构把应用服务映射到运行时与平台能力：流量入口、服务通信、数据存储、异步集成、可观测性与零信任边界。下图为参考拓扑，实际规模会按环境裁剪。

flowchart TB
  subgraph Edge["边缘与接入"]
    CDN[CDN / WAF]
    LB[负载均衡]
    GW2[API Gateway<br/>鉴权 限流 mTLS]
  end

  subgraph Runtime["服务运行时"]
    SVC_POD[Kubernetes Pods<br/>Go 微服务]
    Mesh[可选 Service Mesh<br/>重试 熔断 流量镜像]
  end

  subgraph Data["数据与中间件"]
    MY2[(MySQL)]
    RD2[(Redis)]
    ES2[(Elasticsearch)]
    KF2[Kafka]
  end

  subgraph Platform["平台能力"]
    REG[服务注册发现]
    CFG[配置中心]
    SEC[密钥管理]
    LOG[日志聚合]
    MET[指标与告警]
    TRACE[分布式追踪]
  end

  CDN --> LB --> GW2 --> SVC_POD
  GW2 --> Mesh
  Mesh --> SVC_POD
  SVC_POD --> MY2
  SVC_POD --> RD2
  SVC_POD --> ES2
  SVC_POD --> KF2
  SVC_POD --> REG
  SVC_POD --> CFG
  SVC_POD --> SEC
  SVC_POD --> LOG
  SVC_POD --> MET
  SVC_POD --> TRACE

与后续章节的关系：第 11 章至第 14 章主要在应用与数据架构层面展开；当你评估「是否需要 Service Mesh」「Kafka 分区策略」时，应回到本节检查观测性是否先于网格、消息是否已成为事实管道等平台前提。

非功能需求（NFR）与全景的对应关系：

• 可用性：网关限流与服务熔断保护核心交易路径；搜索与报表故障不得拖垮创单。
• 性能：读路径大量使用缓存与索引；写路径控制扇出深度，结算页试算可合并批量 RPC（第 14 章）。
• 安全：密钥不进仓库；支付回调验签在独立模块；内部服务 mTLS 或网络策略隔离。
• 可观测性：以 trace_id 贯穿网关、结算、订单、支付；对 Saga 每一步有结构化日志与业务指标（转化率、预占失败率）。
• 合规与审计：订单与支付字段变更可追溯；营销补贴与实付金额可对账。

渐进式演进建议：早期可用「单体 + 清晰包边界」模拟上图拓扑；当团队规模与发布冲突上升时，再按限界上下文拆出独立部署单元，避免「先拆微服务、后补边界」的高成本路径。

容灾与多活（点到为止）：技术架构图未展开「单元化 / 多 Region」，但在全景阶段应预留认知：订单与支付数据往往要求 Region 内强一致 + 跨 Region 异步复制；搜索索引与购物车会话更适合 就近读取。若在多活场景下仍沿用单 Region 的强同步调用链，容灾切换时容易遭遇「依赖未起、核心不可用」；因此第 4 章在谈 Saga 时也会隐含「地理边界上的超时预算」问题。

10.2 核心域与支撑域

DDD 强调：不是所有子域都值得同等投入。战略设计的产出之一，是一张「域分类表」，用于指导组织排兵布阵与技术选型（自研 / 定制 / 采购）。

10.2.1 核心域：交易与支付

核心域承载差异化与最高业务风险，典型包括：

本书将购物车、结算、订单与支付作为交易链路主轴（第 14 章），并在第 4 章从一致性模式上把它们串成可复用的集成语言。

投资与组织策略（与系统设计方法论中的技术投资判断对照）：

常见误区：把「购物车」当成纯前端本地存储。实际上购物车是高并发有状态服务，涉及登录合并、库存展示与营销提示，与结算的边界必须在 API 契约上划清（第 14 章）。

10.2.2 支撑域：商品、库存、营销、定价与供给

支撑域是核心域的「地基」：没有可售商品与可算价格，订单与支付无从谈起；没有库存与营销约束，结算编排也会失去输入。

第 11 章至第 14 章分别深入各支撑系统；第 11 章从组织上常合并「上架 + 运营 + 生命周期」，但限界上下文仍建议在模型层分开，以避免「一个上帝服务」拖垮发布节奏。

为什么支撑域也值得深度自研：支撑域虽非「卖点」，却是故障的放大器。例如库存超卖、计价错误、营销叠加漏洞，都会在订单层集中爆发。架构评审中常问：「若该支撑域宕机 30 分钟，核心域能否优雅降级？」——答案决定缓存策略、兜底价、降级开关的设计深度。

与核心域的集成契约（摘要）：

• 商品中心输出：快照 ID、类目路径、禁售标签。
• 库存输出：预占凭证、可售数量区间、渠道库存类型（第 12 章二维模型）。
• 营销输出：可叠加规则集、锁定 token、预算占用凭证。
• 计价输出：试算结果哈希或版本号，供创单时校验「结算页所见即所得」。

10.2.3 通用域：用户、搜索、消息等

通用域标准化程度高，通常采购或薄封装即可；例外是搜索与导购：虽然模式成熟，但在中大型平台中与商品、价格、库存的实时编排深度交织，本书第 14 章将其放入完整交易旅程展开。

反模式提醒：把「通用域 = 可以随便写」等同于降低质量要求。正确做法是：减少自研范围，但不降低 SLO 与可观测性要求。

关于搜索域的「重要性升级」：从严格 DDD 分类看，搜索常被归为通用域（技术方案成熟）；但从业务入口与 GMV 贡献看，它又接近核心体验。本书采取工程折中：在域分类上保留通用属性，在章节权重上按核心链路对待（第 14 章），因其失败模式会直接影响列表价、库存态与活动标签的呈现。

用户与消息：用户域提供主体标识与会员等级，消息域消费订单与支付事件做触达。二者与交易链的耦合主要是读侧鉴权与异步通知，应避免在下单同步路径强依赖外部推送可用性。

10.3 系统间的交互模式

跨系统协作可归纳为三类：同步 RPC、异步事件、数据同步（批式或流式）。它们不是互斥的，同一链路常组合使用；选型取决于一致性语义、延迟上限与故障隔离需求。[5][6]

10.3.1 同步调用

典型场景：结算页试算、创单前库存确认、支付创建。特征是调用方阻塞等待结果，语义接近「读己之写」或强校验。

优点：实现直观、调试路径短。
风险：级联故障、线程占用、超时风暴；需配合超时、重试、熔断、舱壁与清晰的错误契约（第 4 章相关小节）。

工程要点（Go 服务常见落地）：为出站 RPC 设置上下文超时与每依赖独立超时；重试仅对幂等读或带幂等键的写开放；对核心交易路径实施舱壁线程池或并发上限，避免试算扇出把进程拖死。返回错误时区分业务可预期错误（如券不可用）与基础设施错误（如超时），前者映射为 4xx 与明确 code，后者触发降级与告警。

电商实例：结算页打开时，编排服务并行调用计价、库存、营销；只要任一关键依赖超时，应整体返回「请稍后重试」或切换至缓存兜底价 + 延迟锁券策略，而不是无限等待（第 14 章详述降级矩阵）。

10.3.2 异步事件

典型场景：订单已创建、支付已成功、商品变更。特征是最终一致，通过消息中间件解耦峰值与异构消费者。

优点：吞吐与弹性好，天然适合多订阅者（搜索索引、数仓、营销统计）。
风险：重复消息、乱序、滞后；需幂等消费、版本号、可补偿流程（第 4 章 Outbox 与事件驱动）。

工程要点：事件体应携带聚合 ID、版本号、发生时间、幂等键；消费者使用「处理表」或唯一索引实现 at-least-once 下的精确一次业务效果。对支付成功类事件，建议以支付系统 Outbox 为唯一发布源，避免订单与支付双写双发导致重复记账。

电商实例：ProductChanged 发布后，搜索索引、推荐特征、运营看板可能各自消费；它们失败不应阻塞商品主事务，但需要通过死信队列与可观测面板暴露积压，防止索引长期陈旧引发客诉。

10.3.3 数据同步

典型场景：搜索索引重建、报表 T+1、跨机房冗余。实现路径包括定时批处理、CDC、双写（谨慎）。

优点：对在线路径侵入小。
风险：延迟与对账；CDC 需处理 schema 演进与回放。

工程要点：优先 CDC + 消息 或 Outbox 形成可回放管道，避免业务代码里手写双写。若必须双写，应配置对账任务比较主从差异并自动修复。搜索全量重建应走蓝绿索引别名切换，避免重建期间查询抖动。

同步 / 异步 / 数据同步对比总览：三者回答的是不同维度的问题——同步保障「此刻的正确」，异步保障「吞吐与解耦」，数据同步保障「派生视图的规模构建」。架构评审可用下图作开场白板，再落到具体接口与 SLA。[3][5]

flowchart TB
  subgraph Sync["同步 RPC（Request/Response）"]
    S1["一致性：强一致读 / 即时校验"]
    S2["延迟：毫秒级 P99 约束"]
    S3["故障：调用链扩散 → 需熔断舱壁"]
    S4["典型：试算 创单校验 支付创建"]
  end

  subgraph Async["异步事件（Message/Event）"]
    A1["一致性：最终一致 + 补偿"]
    A2["延迟：秒级可接受 / 削峰"]
    A3["故障：隔离好 → 消费者独立重试"]
    A4["典型：订单已支付 商品变更广播"]
  end

  subgraph DataSync["数据同步（Batch / CDC）"]
    D1["一致性：以快照或日志为准"]
    D2["延迟：分钟级 ~ 小时级"]
    D3["故障：可回放 / 对账修复"]
    D4["典型：搜索索引 数仓 跨库复制"]
  end

  Q["选型提问：调用方能否接受短暂不一致？失败能否补偿？是否必须占用用户请求线程？"]
  Q --> Sync
  Q --> Async
  Q --> DataSync

Go 侧抽象示例：在应用层用接口表达三种出口，避免在业务代码里散落 HTTP 客户端细节。

package integration

import "context"

// SyncPricing 同步计价试算（RPC）：强一致读、可返回明确业务错误码。
type SyncPricing interface {
	QuoteCheckout(ctx context.Context, req CheckoutQuoteRequest) (*CheckoutQuoteResult, error)
}

// AsyncPublisher 异步领域事件（Outbox relay 之后投递）。
type AsyncPublisher interface {
	PublishOrderPaid(ctx context.Context, evt OrderPaidEvent) error
}

// ProductIndexProjector 数据同步投影（可由 Kafka consumer 或 CDC worker 实现）。
type ProductIndexProjector interface {
	ApplyProductChanged(ctx context.Context, change ProductChangedLog) error
}

结算编排中的幂等键（与第 13、14 章衔接）：同一用户多次点击「提交订单」时，应以客户端或服务端生成的 idempotency_key 贯穿结算会话与创单请求，避免重复扣减与重复订单。下面展示在 Go 中的最小承载方式（字段名可按公司规范调整）：

package checkout

import "time"

// CheckoutSession 表示结算页的一次编排会话。
type CheckoutSession struct {
	SessionID        string
	UserID           string
	IdempotencyKey   string
	QuoteVersion     int64
	ExpiresAt        time.Time
}

10.4 数据流转全景

本节用三条完整时序链把 10.1 至 10.3 的静态结构串成动态故事线。图中参与者命名与后续章节标题一致，便于对照。

三条链路的共同模式（背诵版）：每条链路都同时存在 同步确认（保证局部不变量）与 异步传播（放大读模型与运营可见性）两类步骤。设计时请先标出「哪一步失败会导致资损或客诉」——这些步骤应尽量落入短事务 + 明确幂等键；其余步骤尽量推出消息总线。另一个共同点是 Hydrate：搜索与列表在 C 端读路径上，往往需要二次拉取商品、价格、库存以修补索引延迟；这与订单创单时的「快照固化」是同一思想的不同形态——用显式版本与快照对抗时间差。

与大促场景的关系：商品流在大促前表现为「批量改价、改库存、改活动」的洪峰；订单流在秒杀瞬间表现为「创单与扣减」的尖峰；支付流在峰值表现为「渠道限流与回调延迟」。全景上需要预留 降级开关与异步化边界：例如列表页短时跳过非关键 Hydrate、支付回调与订单状态更新解耦等（细节分散在第 8、12、13、15 章）。

10.4.1 商品数据流

覆盖从 B 端提交到 C 端可搜、可算、可卖的闭环。

sequenceDiagram
  autonumber
  actor Merchant as 商家/运营
  participant Listing as 商品上架
  participant Life as 生命周期管理
  participant Product as 商品中心
  participant Inv as 库存系统
  participant Price as 计价系统
  participant Bus as 消息总线
  participant ES as 搜索索引
  participant Search as 搜索与导购

  Merchant->>Listing: 提交上架申请
  Listing->>Listing: 审核/风控策略
  Listing->>Product: 创建/更新 SPU SKU
  Listing->>Inv: 初始化/同步可售库存
  Listing->>Price: 配置基础价与费用模板
  Product->>Bus: ProductChanged 事件
  Inv->>Bus: InventoryChanged 事件
  Price->>Bus: PriceSheetChanged 事件
  Bus-->>ES: 投影商品文档
  Note over ES: 异步最终一致
  Merchant->>Life: 发起下架/同步修正
  Life->>Product: 状态迁移与编辑边界控制
  Life->>Listing: 回流审核/发布任务
  Search->>ES: 列表/搜索召回
  Search->>Product: Hydrate 缺失字段（可选）
  Search->>Price: 列表价 Hydrate（可选）
  Search->>Inv: 可售状态 Hydrate（可选）

阶段解读：步骤 1～5 属于 B 端写路径，强一致要求集中在「商品主档 + 初始库存 + 基础价」三者是否同事务可见；多数平台会拆成多个本地事务 + Saga，用补偿保证最终一致。步骤 6～8 属于 异步投影，搜索可见略滞后于库表写入是预期行为，但应对运营提供「索引就绪率」指标。步骤 9～12 体现 生命周期对上架与主数据的回流：下架、供应商同步修正、违规处罚都会触发再次审核或索引失效。

伏笔：第 11 章讲清商品模型与快照；第 12 章区分预占与实物库存；第 11 章拆解上架与运营编辑的权限与状态机；第 14 章展开 Hydrate 编排与降级。

10.4.2 订单数据流

从结算页到订单持久化，强调编排、快照与回滚责任。

sequenceDiagram
  autonumber
  actor User as 用户
  participant GW as API Gateway
  participant Cart as 购物车
  participant Checkout as 结算编排
  participant Price as 计价系统
  participant Inv as 库存系统
  participant Mkt as 营销系统
  participant Product as 商品中心
  participant Order as 订单系统
  participant Bus as 消息总线

  User->>GW: 进入结算页
  GW->>Checkout: 打开结算会话
  Checkout->>Price: 试算（基础价+营销+费用）
  Checkout->>Inv: 库存预占（或预校验策略）
  Checkout->>Mkt: 券/活动可用性校验
  Price->>Product: 读取商品主数据
  User->>GW: 提交订单
  GW->>Order: 创单请求（携带试算令牌/版本）
  Order->>Product: 拉取/确认商品快照
  Order->>Price: 固化价格快照
  Order->>Inv: 确认预占或二次扣减
  Order->>Mkt: 锁定或扣减营销资源
  Order->>Order: 持久化订单与状态机
  Order->>Bus: OrderCreated 事件
  Bus-->>Cart: 提示清理已下单行（异步）

阶段解读：结算阶段（打开结算页）与创单阶段（提交订单）必须对试算结果有明确版本策略：常见做法是计价返回 quote_version 或签名摘要，订单持久化时校验，防止「页面价与实付不一致」引发纠纷。库存侧若已在结算预占，创单多为确认；若仅在结算校验、创单时才预占，则需评估高峰下的重试风暴（第 12 章）。营销锁定与扣减宜拆成「锁定 → 确认 / 释放」两阶段，与订单状态机对齐，避免券冻结长期占用。

异常路径（图中未展开但工程必备）：创单任一步失败应沿 Saga 反向释放预占与券锁定；若订单已写库但后续异步失败，应依赖订单状态机驱动补偿任务，而不是人工改库。

伏笔：第 13 章定义营销资格、试算与快照边界；第 14 章给出购物车、结算、订单、支付状态机、回调和补偿；第 4 章把这些步骤抽象为可复用的一致性模式。

10.4.3 支付数据流

聚焦支付单生命周期与订单回写、清结算衔接。

sequenceDiagram
  autonumber
  actor User as 用户
  participant Order as 订单系统
  participant Pay as 支付系统
  participant Chan as 支付渠道
  participant Ledger as 账务/清结算
  participant Bus as 消息总线

  User->>Order: 去支付
  Order->>Pay: 创建支付单（order_id 幂等键）
  Pay->>Pay: 路由渠道路由/风控标签
  Pay->>Chan: 调用渠道下单接口
  Chan-->>User: 收银台/重定向
  Chan-->>Pay: 异步支付结果通知
  Pay->>Pay: 验签 幂等 状态机推进
  Pay->>Order: 同步支付结果（或订单轮询）
  Pay->>Ledger: 记账/分账指令
  Pay->>Bus: PaymentSucceeded 事件
  Bus-->>Mkt: 实付触达营销核算（可选）
  Note over Pay,Order: 失败/关单需可补偿：关支付单、回滚营销、释放库存（与各域策略绑定）

阶段解读：支付创建应以 order_id（或业务侧支付请求号）做天然幂等键，渠道侧重复调用不产生重复扣款。回调处理必须「先记账、后通知订单」或采用可对账的两阶段状态：确保账务系统（Ledger）与支付核心状态一致。PaymentSucceeded 事件驱动营销核算、分润、积分等下游时，仍应坚持 Outbox 语义，避免在回调线程堆叠扇出。

与订单的边界：订单系统关心「应付金额与履约状态」；支付系统关心「渠道收单结果与资金事实」。订单不应直接保存渠道原始报文全字段，应由支付系统规范化后回写支付结果摘要。

伏笔：第 14 章展开渠道适配、对账与退款；第 4 章讨论跨系统幂等与补偿事务编排。

10.5 系统边界总览

10.5.1 各系统的职责边界（十二个核心系统）

下表给出本书采用的十二个核心可部署系统（与 10.1.2 应用架构及第 11 章至第 14 章对应）。「不负责」列用于架构评审时的负面清单，防止边界侵蚀。

说明：第 11 章在目录上合并了上架、运营与生命周期；在工程上可拆为多服务，但在边界表中仍建议分开陈述职责，以便治理。

十二系统「一句话职责」扩展（评审口播版）：

• 商品中心：维护「卖得是什么」——结构化商品、类目约束与面向订单的快照能力；对外暴露稳定读模型与快照创建接口。
• 库存系统：维护「还能卖多少」——把可售量、渠道库存、预占凭证与对账闭环收敛在库存库表与热点缓存中。
• 营销系统：维护「怎么促卖」——圈品、券活动、补贴预算与叠加互斥规则；不负责把最终应付金额写入订单。
• 计价系统：维护「收多少钱」的规则引擎与快照——对接商品基础价与营销减免，输出可校验的试算版本。
• 搜索与导购：维护「怎么找得到」——索引与排序是手段，Hydrate 与场景识别是业务核心；索引永远晚于主库一秒是常态而非事故。
• 购物车：维护「用户想买什么」——会话级行项目与合并逻辑，不承担资金与库存的最终承诺。
• 结算编排：维护「现在能不能付」——把试算、预占、营销校验收敛为短窗口内的可执行计划，再交给订单持久化。
• 订单系统：维护「合同与履约状态」——状态机、拆单、快照引用与对外协调接口；不保存渠道密钥与支付通道报文。
• 支付系统：维护「资金事实」——支付单、渠道、回调、账务分录与对账；不反向驱动商品编辑。
• 商品上架：维护「供给侧流程」——审核、发布、异步补偿与状态机；它是编排器而非商品主数据的越权写入者。
• 供给与运营管理：维护「运营效率」——批量导入导出、配置工具、权限审计；所有落库应通过正式领域 API。
• 生命周期与供给治理：维护「时间与责任的边界」——上下架、同步冲突、编辑互斥与跨系统回滚策略的协调者。

按价值链聚类（便于向业务方解释）：

10.5.2 边界不清的常见问题

1. 商品中心写库存流水：库存的并发语义与对账域应收敛在库存上下文，否则易出现双写不一致。
2. 营销系统直接改订单金额：优惠「算出来」与订单「记下来」应分离；否则退款与审计难以追溯。
3. 搜索索引当主库：索引延迟会导致「搜得到但买不了」，必须在 Hydrate 或结算侧再次以权威服务为准。
4. 支付系统承载订单状态机：资金状态与履约状态相关但不同；混写会导致渠道回调与拆单场景难以治理。
5. 计价系统写订单行：计价负责「算」与试算令牌；订单负责「记」与版本校验。混写会让退款金额拆分失去依据。
6. 购物车持有库存预占：预占属于资源锁定，应落在结算或订单编排；购物车仅存意图与展示缓存。
7. 运营后台直连生产库改价：绕过计价与审计，极易产生监管与对账风险；应走审批流 + 正式 API。
8. 搜索服务在召回阶段调用支付：读路径不应触碰资金系统；价格与活动以 Hydrate 调用计价与营销只读接口为界。

10.5.3 边界划分原则（落地检查清单）

1. 单一事实来源（SSOT）：每个聚合只有一个权威上下文持久化。
2. 编排与状态分离：编排服务可以无状态或仅存会话；合同状态由订单上下文持有。
3. 读模型可替换：搜索、推荐、报表可重建；不可重建的是资金流水与订单合同。
4. 跨域用契约，不用隐式共享表：表连接是反模式；用 API、事件与明确 DTO。
5. 把「能不能买」的最后一次校验放在离钱最近且可审计的一步（通常是创单或支付创建）。
6. 明确「编排」与「领域服务」：编排负责步骤顺序与超时；领域服务负责业务规则判定。二者勿混在同一「上帝类」中。
7. 每个跨系统接口都有 SLI：例如试算 P99、索引延迟上限、支付回调处理延迟；无指标的接口等于无边界。
8. 用例驱动的边界测试：为每个系统维护「本系统拒绝处理的请求样例」，在 CI 或契约测试中固定下来，防止回归侵蚀。

10.6 本章小结

本章是全书的总领章，目标不是替代后续各章的深度，而是建立三样东西：同一套词汇（限界上下文与十二个系统）、同一张依赖图（应用与数据架构）、同一套交互纪律（同步 / 异步 / 数据同步的组合拳）。[2][7]

你可以带走的关键结论：

1. 四视角对齐：BA 决定投资与语义边界，AA 决定可部署单元与依赖方向，DA 决定权威数据与投影路径，TA 决定规模化运行时能力。缺任一视角，评审容易出现「各说各话」。
2. 十二个核心系统：商品中心、库存、营销、计价、搜索、购物车、结算编排、订单、支付、商品上架、供给与运营、生命周期治理——分别对应第 11 章至第 14 章的主体叙事；其中第 11 章在工程上常合并多个部署单元，但在治理上仍建议按职责拆分讨论。
3. 域分类指导排兵：核心域（订单、支付、结算、购物车）追求正确性与可审计性；支撑域追求稳定与可替换的集成契约；通用域追求成本与 SLO 的平衡。搜索处于「通用技术 + 核心体验」的交叉带，第 14 章会展开其 Hydrate 与降级策略。
4. 交互模式不可偏科：只有同步会导致故障传播；只有异步会拉长不一致窗口；只有批式同步无法满足实时导购。实际架构是在 SLA、成本、团队成熟度 约束下的组合。
5. 三条主链路是阅读地图：商品流回答「货怎么进来并被发现」；订单流回答「承诺如何形成」；支付流回答「资金如何闭环」。后续章节均可挂载到这三条链上自检：本章的哪个小节、哪张图覆盖了当前话题。

与第 4 章的衔接：第 4 章将把 10.3 的交互模式上升为 Saga、幂等、对账、事件驱动 等一致性语言，并把 CAP 折中讲透。建议在阅读实战章节时，用 10.4 的时序图遮住文字，尝试口述一遍每条箭头上的失败与补偿，检验是否已建立全景肌肉记忆。

与第 11 章至第 14 章的衔接：进入任一系统章时，建议先回答四个问题——谁是上游、谁是下游、我的 SSOT 是什么、我发布哪些事件。答不上来则回到 10.5.1 边界表补齐。

面向架构师的自检清单（离开本章前）：能否在 10 分钟内手绘 10.1.2 依赖图并标出三条可能形成环的依赖？能否用业务语言向非技术干系人解释「为什么搜索不是订单的一部分」？能否列举支付回调失败时的三个系统状态组合及各自补偿动作？若尚不能，建议在笔记中重画一遍 10.4 时序图，再进入后续系统实战章节。

建议阅读顺序：若你更熟悉业务，可按 10.4 节三条链路走读，再回看 10.1.1 的限界上下文；若你更熟悉工程，可从 10.1.2 与 10.3 节开始，把依赖与交互模式对齐后再进入各系统章节。若你正在准备架构评审，可携带 10.1.3、10.3.3 与 10.5.3 作为一页纸附录。

10.7 参考资料

[1] Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003, https://www.domainlanguage.com/ddd/。

[2] Martin Fowler, “BoundedContext”, martinfowler.com, https://martinfowler.com/bliki/BoundedContext.html。

[3] Robert C. Martin, Clean Architecture, Pearson, 2017, https://www.pearson.com/en-us/subject-catalog/p/clean-architecture/P200000009830。

[4] AWS, “Build services focused on specific business domains and functionality”, AWS Well-Architected Framework, https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_service_architecture_business_domains.html。

[5] Gregor Hohpe, Bobby Woolf, Enterprise Integration Patterns, Addison-Wesley, 2003, https://www.enterpriseintegrationpatterns.com/。

[6] Martin Kleppmann, Designing Data-Intensive Applications, O’Reilly Media, 2017, https://dataintensive.net/。

[7] Simon Brown, The C4 Model for Visualising Software Architecture, https://c4model.com/。

第 11 章 商品中心、商品供给与生命周期治理

本章讨论一个看似普通、实际很容易失控的问题：平台如何把来自人工录入、批量文件、供应商接口和内部系统的商品供给，经过标准化、审核、版本化和发布，转化为可查询、可售、可履约、可追溯且可恢复的商品资产。

电商系统里的商品并不是一行可以随意修改的数据库记录。一个酒店房型、一个数字商品、一个门票套餐或一个实物 SKU，往往同时包含基础描述、售卖计划、价格上下文、履约约束、库存资源、审核状态、上下架窗口和面向订单的历史契约。它们的变化来源不同，变化频率不同，权威事实也不同。如果所有变化都直接写入一张“商品表”，再用一个 status 字段表示全部生命周期，系统很快就会出现状态覆盖、审核失效、库存漂移、搜索脏数据和订单无法解释等问题。

本章把商品中心、供给平台、库存控制面和下游投影放到同一个端到端模型里分析。重点不在于给出某个公司的唯一实现，而在于建立一套可迁移的判断框架：什么是业务事实，什么是流程状态；谁拥有哪个字段，哪个系统可以写入；哪些动作必须在本地事务内完成，哪些动作只能通过事件最终收敛；当任务超时、消息重复、供应商乱序、库存创建失败或审核对象被再次修改时，系统如何恢复。

11.1 问题定义与系统边界

11.1.1 先定义平台真正要交付的对象

商品平台最终交付的不是“商品编辑页面”，而是一组可以被其他业务可靠消费的事实和契约。至少要区分以下四类对象：

这四类对象可以共享业务标识，但不能共享所有权。供给流程中的 draft_id 表示一次待发布变更，正式商品中的 item_id 表示稳定的线上资产，库存中的 reservation_id 表示一次资源预占，订单中的 snapshot_id 表示一份不可变的交易解释。把这些标识都简称为“商品 ID”会让接口看起来简单，却会把不同的生命周期和失败语义隐藏起来。

领域驱动设计强调，模型边界应围绕业务能力和不变量划分，而不是围绕一张数据库表或一个页面划分。[1] 企业应用架构中的分层和服务边界也不是为了增加目录，而是为了让数据访问、领域规则和流程协调有清晰的责任归属。[2] 因此，本章先把商品平台定义为多个协作域，再讨论它们如何通过命令、事件和查询模型协作。

11.1.2 典型业务场景

一个可复用的商品供给平台至少需要处理五类入口。

第一类是人工单品创建。运营人员填写标题、类目、属性、售卖计划和履约规则，系统即时返回字段校验结果。这个入口强调交互反馈和可解释错误，通常需要同步完成草稿保存，但不应在用户点击保存时直接让商品对消费者可见。

第二类是人工编辑在线商品。编辑对象已经存在正式 item_id，因此系统必须记录编辑基线，例如 base_publish_version。如果编辑期间线上版本已经发生变化，平台不能静默覆盖，而应将冲突交给差异比较、合并或重新审核流程处理。

第三类是批量导入和批量编辑。运营人员上传 Excel 或 CSV，系统需要先保存原始文件，再进行解析、行级校验、标准化、风险审核和分批发布。一个文件中允许部分行成功、部分行失败，但每一行都必须能追溯到输入行号、错误原因、目标对象和重试结果。

第四类是供应商或 ISV 推送。外部系统可能只提供全量列表，也可能提供增量事件；可能重复发送同一版本，也可能出现延迟和乱序。平台不能假设供应商具有稳定的消息语义，而要通过来源标识、外部版本、指纹、时间戳和对账窗口识别无效更新。

第五类是运营和生命周期治理。平台要支持上架、下架、封禁、重新上线、销售窗口调整、属性修正、库存补货、券码批次导入和异常修复。这类动作有的改变正式商品状态，有的改变库存事实，有的只改变流程状态，不能通过一条万能更新接口完成。

11.1.3 系统边界：谁负责什么

建议把平台拆成四个边界，而不是把所有能力称为“商品中心”。

商品中心负责正式商品主数据和交易前契约。它维护 Resource、Item、SPU、SKU、Offer、Rate Plan、类目属性、履约规则、退款规则、发布版本和商品快照模板。商品中心可以拒绝不符合模型不变量的发布命令，但不应承担 Excel 解析、供应商租约、人工审核队列或库存流水账。

供给平台负责流程控制面。它接收多种供给入口，创建 Draft、Task、Task Item、Staging、QC 和错误文件，维护来源、操作人、任务进度、字段主导权和审核记录。供给平台可以发起发布，但不应绕过商品中心直接写正式商品表。

库存系统负责可售资源事实。数量制库存、券码库存、房态库存和日期时段库存的扣减、预占、确认、释放、过期和对账属于库存语义。供给平台可以创建库存配置或发起库存任务，但不应把库存余额当作商品属性写入商品中心。

下游读模型负责按消费场景投影数据。搜索索引、列表缓存、详情缓存、推荐特征和运营看板都可以从商品中心事件构建，但它们不是商品主数据的权威来源。订单和支付还要保留交易时的快照，因为“当前商品”不能解释过去成交时的合同。

11.1.4 业务事实、不变量与非目标

任何设计开始前，都应把“必须永远成立”的不变量写出来。下面这些不变量比组件名称更重要：

1. 已发布的正式商品版本具有单调递增的逻辑版本，旧版本不能覆盖新版本。
2. 审核通过的对象必须有明确的内容版本，不能审核一个对象、发布另一个未被审核的对象。
3. 同一个外部来源对象的同一版本重复到达，不应造成第二次业务副作用。
4. 库存预占、确认和释放必须属于同一库存语义，商品发布不能假装已经完成库存扣减。
5. 订单创建后必须依赖订单自己的商品快照和价格快照，不能回查商品中心当前内容作为历史事实。
6. 任意异步任务都必须能回答：谁提交、处理到哪、哪一行失败、是否可以重试、重试会不会重复副作用。
7. 事件消费失败不能阻塞正式事实写入，但必须进入可观测、可重试、可对账的恢复路径。

本章不讨论完整的推荐算法、营销优惠计算、支付渠道路由、订单履约编排和供应商结算。它们会在其他章节展开；本章只描述这些系统与商品供给之间的契约和边界。

11.1.5 读者应该带走的判断

如果一个商品系统只能回答“商品表有哪些字段”，却回答不了以下问题，它就还停留在 CRUD 层面：谁批准了这次变更？批准的是哪个版本？发布时库存是否已经准备好？搜索结果为什么还显示旧内容？供应商重复发送是否会导致重复库存？订单为什么不会随着商品编辑而改变？任务失败以后由谁恢复？

本章的主线可以压缩为一句话：供给平台治理变化，商品中心确认事实，库存系统确认资源，下游模型接受版本化投影，订单保存历史契约。

11.2 约束、指标与核心判断

11.2.1 约束先于组件

商品平台的技术选型不能从“是否使用微服务、消息队列或 Redis”开始，而应从约束开始。对于一个中大型平台，可以先建立如下假设；这些数字只是容量规划示例，不是行业通用标准，落地时必须替换为测量结果。

数据密集型系统的核心难点不是把数据写入某个存储，而是承认不同访问模式会导致不同的读模型、索引和一致性选择。[3] 因此，同一商品可以有商品中心正式模型、搜索投影、详情缓存、运营看板和订单快照，但它们必须有明确的生成关系，而不能互相竞争成为事实源。

11.2.2 指标体系：业务结果和系统过程分开

只监控接口 QPS 和 CPU 不足以判断供给平台是否健康。至少需要四组指标。

第一组是供给结果指标，包括创建成功率、审核通过率、发布成功率、商品可售转化率、供应商有效更新比例、重复更新比例和人工接管比例。它们回答“平台是否把输入转成了可用资产”。

第二组是过程指标，包括任务等待时间、解析耗时、标准化耗时、QC 耗时、发布耗时、事件延迟、索引刷新延迟、库存初始化延迟和对账修复时长。它们回答“慢在哪里”。

第三组是正确性指标，包括版本回退次数、乱序消息数、幂等冲突数、重复库存副作用数、快照缺失数、下游版本落后数、库存配置与事实不一致数和错误文件重试成功率。它们回答“系统是否在静默地产生错误”。

第四组是资源与韧性指标，包括队列深度、最老任务年龄、Worker 租约超时数、DLQ 增长速度、数据库锁等待、缓存击穿次数、供应商限流比例和人工修复队列。它们回答“系统距离失控还有多远”。

11.2.3 一致性不是一个开关

商品平台至少有四种一致性语义。

商品中心本地事务需要原子性。正式 Item、Publish Version、Snapshot 和 Outbox 记录之间的关系不能出现“版本已经变更但没有任何可发布事件”或“事件说已发布但正式事实没有提交”的裂缝。

跨域发布通常只能最终一致。商品中心不能把搜索、库存、营销、计价和订单都塞入一条跨服务长事务，否则失败恢复、锁持有时间和可用性都会变差。Helland 对大规模系统的讨论指出，许多实际系统会把强一致范围收缩到单个实体或单个服务，再通过消息和补偿协调更大的业务过程。[4]

读模型允许受控陈旧。列表搜索可以接受索引延迟，但必须在进入购物车、结算或订单创建时重新校验商品状态、价格和库存。陈旧不是“无所谓”，而是必须有明确的时间预算、版本标识和用户体验降级。

历史事实需要不可变。订单快照、审核结果、发布记录和审计日志不能随着当前商品变更而被覆盖。事件日志可以帮助回放和审计，但本章不把所有表都改造成全量 Event Sourcing；是否采用事件溯源应根据重放价值、外部副作用和运维复杂度单独决策。[5] 对跨服务协作而言，事件更适合表达已经发生的事实，协作方仍需定义事件所有权、处理结果和失败边界。[6]

11.2.4 复杂度预算

每增加一种入口，系统至少增加一类失败模式。人工入口增加并发编辑和权限问题；文件入口增加格式、行级错误和大任务恢复问题；供应商入口增加重复、乱序、来源可信度和全量删除误判问题；库存入口增加资源生命周期和扣减语义问题。复杂度不是由服务数量决定，而是由状态数量、事实源数量、异步边界和恢复动作共同决定。

因此，平台需要给每种能力设置复杂度预算：

1. 只要同步保存草稿能够满足体验，就不要把草稿保存也拆成多个远程服务调用。
2. 只要数据库 CAS 和短事务能够支撑任务领取，就不要为展示“分布式”而引入 Redis 锁。
3. 只要单个供应商任务可以在可接受窗口内完成，就先使用 Batch + Checkpoint + DLQ，再根据测量结果引入分片。
4. 只要搜索投影能够通过版本号过滤旧事件，就不要让搜索索引反向决定商品是否发布。
5. 只要交易时可以重新校验，就不要为了列表页的即时准确把高频库存写入搜索引擎。

这不是保守，而是把复杂度放在真正需要它的地方。阿里巴巴的公开工程规范也把数据库、异常、日志、工程结构和安全约束放在同一套开发治理框架中，说明系统质量不只来自业务代码本身，还来自边界和习惯的长期一致性。[20]

11.2.5 本章的默认数量模型

后文案例使用一个假设的多供应商酒店与数字商品平台。平台有约 1,000 万个正式 Item，平均每个 Item 有 4 个 SKU 或 Offer；每天接收 50 万条供应商输入，其中约 20% 经过标准化后被判定为无效更新；运营侧每天提交 2 万个批量任务，单任务平均 2,000 行，长尾任务可能达到 10 万行。搜索索引允许 60 秒内收敛，详情读模型允许 10 秒内收敛，交易前商品状态和库存校验必须在一次请求内基于权威系统返回。

这些数值只用于说明设计方法。它们不能推出“所有电商平台都应使用 60 秒新鲜度”或“所有任务都应拆成 2,000 行批次”。真正的设计输入应来自生产日志、压测、供应商 SLA、业务窗口和恢复演练。章节中所有示例数字都标记为假设，避免把单一经验包装成标准答案。

11.3 领域模型、事实源与状态机

11.3.1 商品不是一张表，而是一组有边界的事实

商品模型需要同时表达“卖什么”“如何卖”“什么时候能卖”“卖了以后如何履约”和“当时卖给用户的是什么”。这几类信息的变化速度和生命周期不同，应该拆成多个相互引用但不互相越权的对象。

Resource 表示被平台管理的可供给资源，例如酒店、景区、课程、数字权益或供应商提供的外部服务。它通常承载资源级名称、地理位置、供应商归属和基础履约能力。Product Item 表示平台面向用户展示和交易的正式商品，是一个可发布、可下架、可归档的业务资产。SPU 用来归纳同一商品族的共性，SKU 表示具体可交易的规格组合，Offer 表示在某个渠道、售卖计划或供应商条件下的销售报价，Rate Plan 表示价格、退改、库存和履约规则组合。

这套模型不是固定的行业标准。实物电商可以让 SPU 关联多个 SKU；酒店场景可能把房型作为 SKU、日期和入住人数作为资源条件；数字商品可能把一个兑换码批次作为库存资源。关键不在于名词是否完全一致，而在于模型能够回答：对象的稳定身份是什么，哪些字段属于它，哪个变化会创建新版本，哪个变化只更新运行时资源。

11.3.2 供给对象和正式对象必须分开

供给平台接收的第一份数据不能直接被当作正式商品。一个草稿可能缺少图片、履约规则、库存配置或合规材料；一个供应商对象可能使用本地字段名、旧类目和不稳定的外部 ID；一个批量文件可能同时包含 10 万行，其中只有 9 万行满足最小发布条件。因此，需要用供给对象承载“正在变成商品的变化”。

Draft 表示一次可以被继续编辑的变更草稿。它应记录 draft_id、supply_trace_id、operation_id、来源、操作者、基线版本和草稿内容引用。对于新建商品，Draft 尚未拥有正式 item_id；对于编辑在线商品，Draft 需要指向已有 item_id 和 base_publish_version。