1 为什么先学「架构图表达」
零售活动开始后，顾客点击「提交订单」，页面转了很久，最后提示失败。客服想知道订单有没有生成，开发想知道哪个调用超时，业务负责人想知道是否需要暂停活动。如果方案里只有几排服务方框，大家可能看着同样的图，却分别把「失败」理解成入口拒绝、库存不足、订单没保存，或者响应没有送到。架构图表达要解决的，正是这种看似达成共识、实际各自理解的沟通问题。
本课以创建订单 API 为主线。顾客提交商品与数量，订单服务核验请求，调用库存服务预留库存，把订单写入数据库，再返回订单编号。订单创建成功后，还可能触发通知。这里把支付作为后续业务处理，不把「创建成功」等同于「支付成功」。这些边界需要在图旁明确写出来，否则读者很容易根据自己熟悉的购物流程，替作者补出本来没有承诺的行为。
图的价值不在于容纳多少组件，而在于支持具体判断。面对「库存变慢会不会拖慢下单」，图应标出同步依赖与等待位置；面对「通知故障是否影响创建」，图应交代异步边界与持久化条件；面对「谁可以读订单」，图要展示访问入口和身份检查。不同问题需要不同视图。把所有答案挤进同张图，往往会让最重要的关系消失在交叉线里。
架构图也是可以被证据修正的模型。图上画出订单服务直接调用库存，并不意味着线上始终如此；实际请求可能经过代理，也可能因为配置变化调用了旧地址。作者应写明环境、适用范围、版本和假设，让读者知道哪些是已经确认的事实，哪些是拟议设计。没有这些标记，设计草稿很容易在转发后被当成生产现状，进而误导排查和变更。
阅读这张总览图时，先找系统边界，再找入口和最终结果。顾客位于系统外，入口接收请求，订单服务负责创建流程，库存服务负责预留，订单数据库保存记录。消息队列与通知消费者属于后续通知路径。图里的订单库只代表订单服务拥有的数据存储，不表示库存也保存在这里；队列旁的说明则提醒读者，订单事件能否可靠进入队列，需要额外机制保证。
入门阶段不必追求完整掌握某套制图语言。先做到每个框有明确职责、每条线有方向和含义、每个关键结果有可检查的条件。只要读者能沿着图解释正常请求如何完成、某处失败后会留下什么状态，以及应去哪里找证据，图就已经开始发挥作用。后续增加部署细节、容量数字或安全控制，也应服务于这些判断，而不是为了让画面显得复杂。
2 核心概念与边界
架构图中的节点表示对象，边表示关系，但对象和关系都需要选定层次。节点可以是业务系统、服务、进程、数据库，也可以是部署位置。如果同张图里同时出现「交易平台」「订单服务」「某台机器上的线程」，读者很难判断它们是否处在相同层级。开始绘图前，先用句子说明视角，例如「本图展示创建订单涉及的服务与数据存储，不展示服务内部线程」。
系统上下文视图关注谁使用系统、系统依赖谁，适合解释业务范围。组件视图关注系统由哪些职责单元组成，适合讨论依赖与所有权。时序视图关注事件发生顺序，适合解释等待、超时和返回结果。部署视图关注组件运行在哪里，适合讨论故障影响范围。它们可以描述相同系统，却不能互相替代；时序上的先后关系，也不能直接推出部署上的物理隔离。
边界表示某种规则的分界处。订单服务与库存服务之间是职责边界，应用与数据库之间可能涉及不同访问权限，系统与外部通知渠道之间还存在管理权边界。边界不是画个大框就自动成立。应说明跨越边界时检查什么、由谁配置、失败由谁负责。如果仅画出「安全区」而没有入口规则、身份校验或数据访问限制，读者仍然无法判断访问是否受到约束。
箭头尤其容易制造误解。订单服务指向数据库，可能代表写入、读取、网络连接，也可能只代表依赖。入门图应优先写出「写订单」「查询状态」这样的动词，并在需要时标注协议。双向通信通常包含请求和响应，但无需每张总览图都画出双向箭头；可以用图例说明箭头表示调用发起方向，另用时序图展示返回。不要让读者靠箭头颜色猜业务含义。
数据所有权意味着哪个组件负责解释与修改某类数据，并不等于哪支团队拥有机器。本例由订单服务维护订单状态，库存服务维护可售库存及预留记录。订单服务通过库存 API 发起预留，不能因为画图方便就直接连到库存库修改数量。绕过接口后，库存服务原有的校验、并发控制和审计可能失效，图也无法再解释到底由谁保证库存规则。
还要区分逻辑组件与运行实例。图中只有 1 个「订单服务」框，不代表线上只有 1 个实例；画出 3 个实例，也不代表它们拥有互相独立的数据。若本次讨论不涉及实例数量，可直接写「逻辑服务，实例数省略」。如果讨论容错，则需要补充实例所在故障域、共享依赖和流量分配方式。多个方框只是多个对象，不能单凭数量证明系统可用性。
最后明确图的状态：现状图描述已确认的运行方式，目标图描述拟实施的设计，故障图描述某段时间的异常。给它们不同标题，并注明更新时间和证据来源。新增队列尚未上线时，不应在现状图中用普通实线表示已经存在的路径。可以单独提供目标图，或通过图例标明拟建部分，避免业务评审、研发实施和故障值班引用到不同含义的版本。
3 关键机制（可迁移）
绘图的起点是问题和结果。以「创建订单为什么可能超时」为例，先定义成功：请求经过校验、库存预留得到确认、订单记录完成提交，入口在约定时限内向客户端返回订单编号。再限定范围：本次不包含支付和发货。这样才能判断哪些节点必须出现，哪些可以暂时省略。缺少成功定义时，作者很容易把「入口收到请求」误当成「业务已经完成」。
接着沿业务结果反推最小必要路径。先画客户端、入口、订单服务、库存服务和订单库，再写出校验、预留、提交、响应等动作。此时暂不添加缓存、搜索、推荐等外围能力。每增加组件，都应能回答它改变了哪项判断：减少了哪段等待，保存了哪份状态，隔离了哪类故障，或者引入了哪个新依赖。无法解释作用的组件，通常不应占据主图中心。
同步调用意味着发起方需要等待下游结果后才能继续当前步骤；异步传递意味着发送方和处理方在时间上解耦。异步不等于立即完成，也不等于不会丢失。若订单服务只是把通知任务放进内存便返回，进程退出后任务可能消失。若使用队列，还要说明消息何时算被接受、消费者如何确认处理、重复消息如何识别。图上画出队列，只能说明存在传递环节。
把控制流和数据流分清也很有帮助。库存调用的控制结果是预留成功或失败，携带的数据可能包含商品编号、数量、预留标识。订单写入产生订单编号和状态。通知事件只需包含下游执行任务所需的信息，不应默认携带完整地址和联系方式。字段选取既影响消费者能做什么，也影响数据暴露范围，因此在关键边旁注明数据类别，比堆满协议名更能解释设计。
这个逐步演示先展示问题与边界，再补充必要组件、调用顺序、失败分支和证据位置。每步都保留前面已经确认的关系，让读者看到图如何逐渐具备解释能力。最后出现的图不一定最复杂，但必须能回答当前问题。演示中的「待确认」标签不能被当作装饰：它表示作者尚无证据证明某项保证，应在评审中明确负责人和确认方式。
图的阅读成本需要主动控制。主图只放影响当前结论的节点，用图例统一解释实线、虚线和边界。颜色可用于突出当前步骤，但含义也要写进文字，使黑白打印和色觉差异不会破坏阅读。长描述放到图旁注释，线上的标签保持简短。图中出现缩写时，首次给出中文含义；多个系统使用相同简称时，优先改成职责名称，避免产生错误对应。
完成草图后，可以用口述做语义检查：谁发起请求，谁持有状态，谁等待谁，失败后谁知道，最终向顾客报告什么。如果回答需要临时补出图上不存在的关键关系，说明图还缺信息。如果回答被大量与问题无关的细节打断，说明视图需要拆分。此方法可以迁移到退款、预约、文件上传等流程，因为它检查的是关系与承诺，而不是某种具体技术栈。
4 关键机制续：落到订单链路
现在把关系落实到订单链路。客户端调用 POST /orders，携带商品、数量与幂等键。幂等键用于识别同次业务意图的重复提交，其有效范围和保留时间由接口约定。入口完成身份识别与基本请求检查，订单服务再校验商品和业务条件。身份有效不代表商品可售；格式正确也不代表库存充足。架构图应把不同职责放在对应节点，避免入口承担所有业务规则的错觉。
订单服务调用库存预留接口，成功后拿到预留标识，再提交订单记录。这里至少跨越订单库与库存服务这 2 个独立状态边界，不能因为时序图把动作画在相邻位置，就宣称它们会同时成功。本课使用简化流程解释这种风险：预留有期限，订单记录关联预留标识，异常情况通过查询和补偿核对。实际期限、核对周期及状态转换需要进一步设计和验证。
图中把库存调用失败和订单写入失败分开。若库存明确返回无货，订单服务可以返回业务拒绝。若库存调用超时，订单服务可能不知道预留是否已经发生。若预留成功而订单库写入失败，还可能留下暂时占用的库存。对这些情况，不能全部写成「失败后重试」。重试哪步、沿用哪个标识、如何识别已经执行的动作，决定了重试能否保持业务结果一致。
客户端超时也不意味着服务端撤销了工作。订单可能已经提交，只是响应在网络途中丢失。此时让顾客反复点击、每次都生成不同幂等键，可能产生重复订单。合理的表达应包含结果查询路径，并约定重复请求如何返回已有结果或处理中状态。幂等记录与订单写入之间也需要可靠关联；仅在日志里打印幂等键，不能提供防止重复执行的保证。
订单提交后，通知通常可以延后处理。若希望订单与待发送事件共同保存，可把事件记录写入订单数据库的同次本地事务，再由后台发布到队列，这常被称为事务发件箱。它解决订单已保存而发送意图没有记录的问题，但不自动消除重复发布。通知消费者仍需按事件标识去重，并把处理结果持久化。总览图中的异步路径，应在旁注交代这个前提。
时间预算帮助解释谁先放弃等待。假设客户端等待上限为 1500 毫秒，入口内部目标为 1200 毫秒，库存单次调用上限为 400 毫秒。不能由此推断库存可以重试 3 次，因为其他步骤、重试间隔和网络传输也占用时间。上游剩余预算不足时，应减少后续工作或及时返回约定结果。超时后已执行的动作如何核对，需要独立写明，不能用更大的超时值代替。
滑块演示只比较等待预算的分配。它使用固定的教学耗时样本，展示预算变大时哪些样本可以在期限内返回，以及等待占用如何变化。它不能预测生产成功率，也不能证明增加超时就会提高吞吐量。真实系统里，更多等待可能占用连接与工作线程，让队列继续增长。架构图的作用，是让评审者看到这项取舍发生在哪里，并知道还需要哪些测量才能决定参数。
5 动手与命令/控制台直觉
可以在隔离的教学环境中，把 1 次请求沿图走完。动手前确认服务地址、测试身份、可用商品和接口约定，不使用真实顾客信息。以下命令只是接口形状示例，假设本地服务已启动在 127.0.0.1:8080，并接受示例字段；它不负责部署服务。创建请求会产生测试订单，重复使用相同幂等键的行为应符合该服务公开的契约。
curl --include --max-time 2 \
--request POST 'http://127.0.0.1:8080/orders' \
--header 'Content-Type: application/json' \
--header 'Idempotency-Key: p9-demo-001' \
--data '{"items":[{"sku":"demo-sku-01","quantity":1}]}'先观察返回状态、响应体和请求标识，再判断这次请求在图中走到了哪里。若返回订单编号，也要检查业务状态是否为「已创建」；若接口返回「已受理」，则只能说明请求进入后续处理，不能替它补成库存已预留、订单已提交。HTTP 状态码描述接口层结果，响应体里的业务状态描述业务进度，二者应共同构成可解释的接口契约。
假设响应给出订单编号 demo-order-001，查询接口可以写成下面的形状。这个编号仅为示意，应替换为教学服务实际返回值。查询用于确认已持久化的业务结果，不应通过再次创建来猜测原请求是否成功。若服务提供按幂等键查询结果的接口，也应在图中标注入口、访问权限和有效时间，避免顾客查询到不属于自己的订单。
curl --include --max-time 2 \
'http://127.0.0.1:8080/orders/demo-order-001'然后在日志或追踪页面按请求标识搜索，依次确认入口接收、订单服务处理、库存调用、数据库提交和响应发送。日志中没有某条记录，并不能立刻证明动作没有发生：日志可能被采样、延迟上传，也可能没有覆盖该分支。要把「未找到记录」和「确认未执行」区分开。后者通常需要更可靠的业务状态、审计记录或可重复验证来支持。
在控制台查看架构时，也要保持相同直觉。实例列表回答服务运行在哪里，路由配置回答请求可能去哪里，连接数和延迟回答运行表现，数据库记录回答业务状态。它们属于不同证据层。控制台显示实例健康，只能说明所配置的健康检查通过，不能推出创建订单全链路成功；健康检查也许只访问本地页面，没有经过库存或订单库。
若教学环境允许模拟故障，可以通过预设开关让库存调用延迟，再用新测试请求观察超时与查询结果。使用相同幂等键的重试用于检查同次业务意图，使用新键用于发起新的独立请求，不应混用。记录模拟条件、开始时间、预期分支和实际结果后，把证据贴回对应箭头。这里训练的是图与观测相互对应的能力，不能把本地结果直接当成生产容量结论。
6 观测：看哪些字段与信号
可观测性在本课中指通过外部信号理解系统内部发生了什么。架构图可以成为观测索引：入口旁写请求量、错误比例和延迟，库存箭头旁写调用耗时与超时次数，数据库旁写写入结果与连接等待，队列旁写积压和最老消息年龄。指标用于发现群体变化，日志用于查看具体事件，追踪用于串联调用路径，业务记录用于确认最终结果。
请求标识用于关联某次接口尝试，追踪标识用于关联跨服务调用，订单编号用于定位业务对象，幂等键用于关联同次业务意图的多次提交。它们并不天然相同。客户端重试后，请求标识通常改变，幂等键应按约定保持不变；订单编号可能到写入阶段才生成。图旁列出这些标识何时出现、如何传递，能显著减少排查时把不同请求拼接成同条链路的风险。
时间字段应说明时间源和含义。事件发生时间与日志采集时间不同，多个节点的时钟也可能存在偏差。排查先用追踪中的父子关系确定调用结构，再谨慎比较跨节点时间。持续时间适合判断某段等待长短，但要确认是否包含排队、重试或连接建立。把不同口径的耗时直接相加，可能重复计算，也可能漏掉入口之前的等待。
延迟需要写清统计窗口和分位数。平均耗时正常，不代表尾部顾客体验正常；某段窗口里的第 95 百分位延迟表示该窗口约 95% 的观测值不高于它。不同服务的第 95 百分位不能直接相加，当作全链路第 95 百分位。成功率也要注明分母是全部请求、通过校验的请求还是独立业务意图，重试可能让这些分母产生明显差异。
业务信号能补充技术指标。创建接口错误比例升高时，应同时看已创建订单数、库存预留未关联订单数、重复订单数和待核对订单数。队列积压增加时，还应查看最老消息已经等待多久，以及消费者处理是否持续推进。队列为空并不能证明消息没有丢失；也可能是上游根本没有发布事件，需要结合订单库里的待发送记录继续确认。
字段收集要遵守最小必要原则。可以记录错误类别、耗时、测试标识和脱敏后的关联信息，不把访问凭证、支付信息或完整联系方式写入普通日志。请求标识、订单编号这类取值很多的字段，适合日志检索或追踪关联，通常不适合作为每条指标的标签，否则会带来大量时间序列。画图时应区分「可搜索字段」和「聚合维度」，避免把所有信息都塞进指标系统。
还要把告警连接到动作。只写「订单服务告警」无法指导值班人员。可以写成「创建错误比例超过约定阈值时，先确认影响范围，再查看库存调用耗时与订单提交结果」。阈值由业务目标、流量和历史基线决定，本课不指定通用数值。图上应标出观测缺口：如果无法按预留标识查询库存状态，就应把它视为排查能力不足，而不是假设库存一定已经释放。
7 常见坑与反模式
最常见的坑是组件名很丰富，业务含义很贫乏。图里画满网关、缓存、队列、数据库，却没有说明订单何时算创建成功。修正时先在图旁写成功条件，再删除与当前问题无关的节点，把剩余箭头改成具体动作。读者如果仍然无法回答顾客应该得到什么结果，就应继续补充业务状态，而不是再增加技术图标。
另一个坑是把逻辑图当作部署保证。多个服务框可能运行在相同故障域，多个实例也可能依赖相同数据库。声称「任意节点故障都不影响下单」之前，需要检查共享依赖、切换条件和剩余容量。入门图可以暂时不展开这些内容，但应明确「本图不用于证明容灾能力」。当评审问题转向可用性时，再提供能够支撑该判断的部署视图。
同步与异步混画也很危险。某条箭头标了「消息」却没有说明谁等待谁，会使评审者误判用户响应时间。若订单创建仍然等待消费者完成通知，那么即使中间存在队列，通知耗时仍可能进入用户等待路径。应通过时序图标出返回发生的位置，并写出队列接收、消息处理和业务完成之间的区别，避免用「异步」这个词替代真正的时序说明。
无条件重试容易放大故障。下游变慢时，上游增加尝试次数，会带来更多并发请求和更长等待；若操作缺少幂等处理，还可能重复预留库存。图中应写明哪些错误允许重试、总预算是多少，以及结果不确定时如何查询。对于库存明确不足这类业务拒绝，立即重复相同请求通常没有帮助；对于网络超时，则先考虑动作可能已经执行。
把数据库事务边界画得过大，会制造虚假的一致性承诺。订单库中的本地事务不能自动覆盖独立库存服务和消息队列。需要明确哪些写入能够共同提交，哪些动作依靠后续重试、去重和补偿完成。补偿也不是让时间倒流：释放库存可能失败，通知可能已经发出。图中应给补偿留下可追踪状态、重试入口和人工核对条件，而不是只写「自动回滚」。
没有图例、版本和负责人，会让图逐渐失效。相同颜色在不同图里代表不同含义，旧路径在服务拆分后没有删除，拟建组件被误当成已上线组件，都可能造成实际误判。图应有更新触发条件，例如接口契约、数据所有权或关键依赖发生变化时同步修改。负责人负责确认表达与实现的一致性，不意味着每次运行异常都由这个人独自处理。
还有一种反模式是把图当作证据本身。「图上没有缓存，所以问题不可能来自缓存」并不成立，图可能省略或过期。设计文档只能给出待验证的假设，运行配置、调用追踪和业务状态才用于确认具体事实。复盘时应记录这次排查暴露的表达缺口，并更新适用范围。架构图因此成为持续维护的沟通工具，而不是上线前完成后就不再触碰的交付附件。
8 案例：订单系统相关故障
某零售系统在活动期间出现提交订单超时。教学案例中的观测窗口为 10:00 至 10:10，入口请求量上升，客户端报告失败的数量明显增加，但订单库仍持续出现新订单。通知队列也开始积压。最初有人根据积压现象推测「通知慢导致下单慢」。这只是相关性线索，需要先查看通知是否处于同步返回路径，不能因为两个指标同时异常就认定存在因果关系。
根据现状图，订单提交后即可返回，通知通过持久化事件异步发送。抽取失败请求的追踪后发现，主要耗时出现在库存预留调用；通知消费者没有出现在这些请求的等待路径中。这些证据降低了「通知直接阻塞响应」的可能性，但尚不足以排除共享资源影响。接下来仍需检查发布任务和通知消费是否与订单服务竞争相同连接、机器资源或数据库容量。
进一步核对运行配置，发现库存服务访问存储时出现连接等待，部分预留调用超过订单服务设置的期限。对于这部分调用，订单服务只知道超时，并不知道库存最终是否完成预留。客户端也在自己的等待上限后停止等待。不同超时发生在不同位置，故障图应标出对应箭头和时间，避免把「客户端没收到结果」简写成「库存明确拒绝」。
逐步演示把相似的「失败」拆成不同状态：库存明确拒绝、库存结果未知、库存成功但订单未提交、订单提交但客户端未收到响应。每个状态都需要不同证据。对已提交订单重复创建，可能制造重复业务；对没有提交的请求只等待通知，也无法恢复订单。演示最后把查询和核对路径补到图上，说明恢复动作应以已确认状态为前提。
现场先限制新请求进入速度，降低下游压力，并暂停会增加库存调用次数的自动重试策略。采取这些动作后，仍要观察订单错误比例、库存调用延迟和连接等待是否改善，不能把动作本身当成恢复证据。扩大连接池也不是必然正确的处理：如果存储已经饱和，增加连接可能加剧竞争。临时措施需要有执行范围、回退条件和效果观察窗口。
对于结果不确定的请求，系统按幂等键、订单编号和库存预留标识进行核对。已提交订单返回已有结果；确认无订单且有孤立预留的，按约定释放或等待到期；仍无法确认的，进入待核对队列。核对任务也必须避免重复释放和覆盖新状态。顾客页面展示「结果确认中」时，应提供后续查询方式，不能无限等待，也不能提前宣称订单一定不存在。
复盘发现，图中原先只写了「库存 API」，没有标注超时后状态未知，也没有展示查询预留的能力。修订后的图增加了时间预算、状态查询和核对责任。通知积压则作为并发现象单独调查，不能因为订单入口恢复就宣布通知问题解决。案例说明，架构表达既要帮助定位主要故障，也要避免把多个同时发生的问题强行压成单个原因。
9 排查案例：证据链怎么写
证据链的目标，是让没有参与现场的人能够复查结论。先写现象和范围：「在 10:00 至 10:10，创建订单接口的客户端超时增加，影响活动商品相关请求；查询订单接口是否受影响尚未确认。」接着写观察口径、环境与数据来源。避免直接写「订单系统挂了」，因为这个说法没有说明受影响能力、持续时间和成功请求是否仍然存在。
然后建立候选解释，并写出能区分它们的证据。若怀疑入口拒绝请求，就查入口接收与转发记录；若怀疑库存等待，就查对应调用跨度及下游记录；若怀疑订单库写入失败，就核对提交错误和业务记录。候选解释不需要穷举所有可能性，但应覆盖当前图里的关键边界。每条证据都要能指向某个判断，而不是堆放与问题无关的日志截图。
记录可以采用「观察、解释、限制、下一步」的顺序。例如：「在抽取的 20 条超时追踪中，16 条主要等待位于库存调用；因此优先调查库存依赖；样本只覆盖已采集追踪，不能代表全部失败请求；下一步核对库存端连接等待和请求结果。」这比「库存有问题」更准确，也允许别人根据新增数据调整结论。抽样方式和缺失比例应尽可能注明。
接下来把技术证据连到业务状态。追踪显示订单写入跨度结束，并不一定证明事务成功提交；需要核对跨度结果定义和持久化记录。日志显示发送响应，也不证明客户端已经收到。库存返回成功，也不代表订单存在。通过请求标识找到调用，再通过订单编号或预留标识查询状态，可以把控制流和业务结果接起来，减少只根据单层信号下结论的风险。
区分事实、推断与行动同样关键。事实可以是某组记录中的库存等待上升；推断可以是连接竞争导致这组请求超时；行动可以是限流并验证等待是否下降。行动有效能够增强推断，却不自动证明全部因果关系，因为流量也可能同时回落。应记录变更时间、同期流量和其他调整，对仍未排除的因素保留说明，不为了让复盘显得完整而填入未经验证的根因。
恢复判断要覆盖用户体验和遗留状态。接口错误比例下降后，还要确认新订单可查询、孤立预留正在收敛、待核对记录有处理进度，以及通知积压是否继续下降。对每项指标写明统计窗口和负责人。无法自动修复的记录进入明确的人工流程，保留业务标识与处置依据。不要因为主图上的正常箭头已经变绿，就忽略故障期间留下的不一致状态。
最终交付的故障图应标记异常发生位置、已验证路径和未确认部分，并链接到受控的证据记录。正文可以写成：「现有样本与库存连接等待记录支持该依赖为主要延迟来源；客户端超时中包含已提交订单；已采取入口限流和状态核对；其余未关联请求仍待确认。」这种写法给出可行动结论，也保留结论边界，让后续人员能够继续补证，而不必推翻整份报告。
放进方案里
在零售订单 API 方案中，架构图应紧跟业务范围与成功定义。先说明本次覆盖创建订单、库存预留和订单结果查询，支付与履约由其他流程负责。创建成功的条件写成可检查的业务状态，并注明客户端超时后可能出现结果未知。这样，业务、开发与运维讨论的是相同承诺，后续容量和可用性目标才有明确对象。
方案提供服务总览与关键时序视图。总览交代入口、订单服务、库存服务、订单库和通知路径，标出职责与数据所有权；时序展示预留、提交、返回及异常分支。图例统一说明箭头方向、同步等待和异步传递，图旁注明环境、版本与负责人。拟建能力明确标记为目标设计，避免被当成已经具备的生产保证。
可靠性说明围绕状态边界展开。写清幂等键的范围与保留期限、超时后的查询方式、孤立预留的核对责任，以及重复消息的处理规则。若采用事务发件箱，说明订单与待发送事件的本地提交边界，并列出发布失败和消费重复的恢复方式。需要测量才能确定的期限和重试参数列为待验证项，不用经验数字代替承诺。
观测要求与图中节点对应，至少覆盖入口错误比例、关键调用延迟、订单提交结果、待核对记录和通知等待年龄。关联字段包含请求标识、订单编号与预留标识，并规定访问权限和脱敏要求。告警说明触发后的首要判断与处置入口，使值班人员能够从现象沿图找到证据，而不是临时猜测日志在哪里。
评审材料同时写出取舍：同步预留会占用等待预算，异步通知会增加事件投递与去重责任，补偿流程需要可追踪状态。验证计划覆盖正常创建、库存拒绝、下游超时和响应丢失，并以业务记录确认结果。最后约定接口、依赖或数据所有权变化时更新图，确保方案中的承诺能够持续对应实现。
10 小结：检查清单
架构图表达的核心，是把业务结果、组件职责、调用关系和证据位置连接起来。图应有清楚的适用范围，能够解释正常链路，也能够说明失败后哪些状态已知、哪些仍待确认。
- 是否写明本图回答的问题、适用环境、版本和负责人？
- 是否定义创建成功，并区分创建、支付与通知结果？
- 节点是否处于可比较的层次，职责和数据所有权是否明确？
- 箭头是否有方向与动作，图例是否说明同步和异步含义？
- 是否标出独立状态边界、超时位置及结果查询路径？
- 重试是否受幂等规则和总预算约束，补偿是否可追踪？
- 是否能从关键节点找到指标、日志、追踪和业务状态？
- 故障结论是否区分事实与推断，并注明证据限制？
- 运行方式变化后，是否有人负责同步修订图与说明？
读者应能沿着图回答：顾客看见超时时，订单可能处于哪些状态，分别去哪里确认，以及确认后由谁采取什么动作。能够回答这些问题，图才足以支持方案评审与故障协作。
下一课转向 P10 云上参考架构入门：把本章验收过的结论带进后续主题，写成可检查的方案约束。