1 零售与汽车方案要回答什么
零售大促和汽车远程更新看起来相距很远，方案面对的基础问题却很接近：大量分散的终端通过质量不稳定的网络连接中心服务，业务会在特定时刻集中发生，操作结果还必须能够解释。零售不能只证明首页打开很快，还要说明付款后的订单是否成立、库存是否真正留住、门店是否能够履约。汽车不能只证明更新包下载成功，还要说明车辆是否具备安装条件、安装中断以后能否继续安全使用、哪些车辆需要暂停更新。架构图的价值，在于把这些问题对应到明确的责任和恢复动作。
本课继续使用零售订单 API 作为贯穿案例。顾客提交订单时，接口接收商品、数量、门店和请求标识，生成可查询的订单状态，再协调库存预留、支付确认与履约。假设平时创建订单为每秒 200 次，大促入口预计达到每秒 2000 次，允许售罄商品立即返回明确结果；已经受理的订单不能因为重试而重复扣款。这里的数字都是教学假设，真实方案需要业务记录和压测数据支撑，不能把示例直接当作容量承诺。
汽车场景用于帮助我们检查边界。把订单请求换成车辆更新任务后，仍然需要身份校验、任务记录、状态查询、重试控制和分批推进；但安装动作会影响车辆功能，其风险不能套用购物车的处理方式。订单受理以后可以等待库存结果，车辆安装则必须先满足驻车、电量和软件兼容等条件。共用的是分析方法，具体的业务状态、允许延迟和安全责任要分别定义。
先把需求写成可验收的句子。例如，“创建订单在指定负载下，95% 的响应时间不超过 500 毫秒”，“请求重复提交时返回同一订单”，“门店断网后不承诺未知库存”，“更新失败的车辆能够报告当前可运行版本”。每句话都应说明测量位置、前提和失败结果。只写“高并发、高可靠、强安全”，无法判断哪种设计更合适，也无法在成本增加时说明钱花在哪里。
方案的输出可以沿着需求、选项、决策记录、成本、风险、高可用展开。决策记录常称 ADR，用来记录背景、候选方案、选择原因和代价。比如选择先持久化订单再异步预留库存，就要同时承认顾客会短暂看到“处理中”。高可用也要落到这条路径：哪个组件失效仍能受理，哪个组件失效必须停止承诺，以及积压恢复后如何保持业务结果正确。
2 门店/车端连接与高峰
终端连接不能只用“在线”或“离线”描述。门店可能能够访问公网，却暂时无法连接库存中心；车辆可能可以接收任务通知，却因信号变化无法完成大文件下载。方案至少区分连接可达、身份有效、数据足够新、操作条件满足这几种事实。终端最近 1 次成功上报只能证明当时的情况，不能证明当前库存仍有货，也不能证明车辆此刻适合安装。
门店订单的关键边界是断网期间能卖什么。如果门店拥有独立的本地配额，可以在配额范围内继续销售，并记录等待同步的交易；如果依赖全局共享库存，断网时继续出售就可能超卖。不能仅靠“恢复网络后同步”解决已经发生的承诺冲突。对本课订单 API，默认中心库存负责预留；门店离线交易属于额外能力，必须先说明配额与对账规则，不能悄悄并入接口承诺。
高峰也有不同形状。大促可能在开售后的 30 秒形成尖峰，车辆则可能在通知推送后集中检查任务，随后形成持续数小时的下载流量。请求数、连接数、带宽和后台任务数不能互相替代。每秒 2000 次小订单不一定比每秒 200 次更新下载更消耗带宽；大量轮询即使不创建新任务，也可能压垮状态查询。容量表需要分别记录入口、查询、后台处理和文件分发的峰值。
入口可以采用限流、排队和明确的重试提示，终端使用逐渐延长的重试间隔，并加入随机等待，使大量设备不在同一时刻再次冲击服务。对创建订单，客户端必须保留原请求标识；更换标识重试会把网络重试变成新订单。对车辆检查任务，可以按车辆分组错开时间，并限制每组并发。这里先理解节奏控制即可，具体算法和队列内部实现留到后续课程。
静态商品图和更新包适合通过分发层提供，减少中心服务重复传输相同内容。订单写入、库存判断和安装授权仍需要业务服务作出决定。即使文件已经缓存，终端也要校验内容完整性，更新包还要验证可信签名与适用版本。缓存命中率只说明传输效率，不能替代业务授权。将这些流量分开以后，扩容才能针对实际压力，而不是把所有请求交给同一组中心实例。
评估高峰要把持续时间一起写下。每秒新增 2000 个请求、处理能力为每秒 1500 个，持续 60 秒便会积压 30000 个请求；如果高峰结束后只剩每秒 100 个的净消化能力，清空需要约 300 秒。这个简单估算还没有包括失败重试。队列能够吸收短时波动，却不会凭空增加处理能力，等待上限、过期规则和恢复容量必须同时说明。
3 库存、履约与远程诊断
订单 API 的“成功”至少有受理成功和业务成功这 2 层含义。接口已经持久化请求，可以返回订单编号与“处理中”；只有库存预留和必要的支付步骤完成，才能推进到可履约状态。若接口返回受理结果，页面就应提供查询入口，不能立即显示“购买成功”。这种区分让慢环节可以异步执行，也让顾客知道等待的是什么，而不是在网络超时后反复点击。
库存预留需要由权威库存服务控制，不能依据商品页缓存直接扣减。可以把 1 件库存想成暂时交给某个订单的名额：预留成功后其他订单不能再使用，支付超时或取消后按规则释放。预留、确认、释放都需要绑定订单和操作标识。重复收到同一释放消息时，不能把可售数量再加 1 次；取消和支付确认相遇时，也要通过明确的状态转换决定结果。
履约涉及仓库、门店或配送系统，它们的速度和可用性各不相同。后台消费者处理订单任务后，可能已经通知仓库，却在记录结果前中断；恢复时消息可能再次送达。方案应承认重复投递可能发生，并要求接收方用履约任务编号去重。不能仅凭消息队列“可靠”就宣称端到端不会重复。对暂时无法确认的结果，应先查询、对账，再决定是否补发业务动作。
汽车远程诊断同样需要区分报告和判定。车辆上传故障码、软件版本、时间和必要的运行摘要，中心系统据此定位受影响范围；诊断报告不是直接执行修复的授权。网络中断时，终端可按存储和隐私约束保留必要记录，恢复后补传，并保留事件发生时间与接收时间。否则延迟到达的旧告警可能被误认为当前故障，使运维对错误版本采取措施。
订单和更新都需要可查询的状态记录。订单可以使用“已受理、待库存、待支付、待履约、完成、取消”，更新可以使用“待检查、可下载、已下载、待安装、安装中、待验证、完成、失败”。状态名称可以调整，但每个状态应说明谁推进、依据什么证据、超时后找谁处理。简单地增加“异常”状态会隐藏恢复差异，库存不足、支付未知和履约超时需要不同动作。
观察系统时，要把订单编号、请求标识和后台任务编号关联起来；汽车侧则关联更新活动、车辆受控标识、目标版本和执行阶段。面向日常运维的面板尽量采用汇总数据，敏感明细按职责授权查看。需要追踪的是业务经过哪些阶段、在哪里等待以及结果是否可确认，而不是无目的地收集所有终端数据。日志保留多久、谁能检索，也属于方案责任。
4 动手：对照一次大促/OTA 路径
这次练习不要求部署真实门店或车辆。准备 1 张请求记录表、1 张状态表和 1 张异常表，用纸面推演或现有测试环境都可以。固定商品 A 的可售库存为 100 件，创建订单使用请求标识 R001，订单编号为 O001。汽车侧固定更新活动 U001、目标版本 V2，并选取 10 台模拟车辆。所有车辆动作只表示状态变化，不执行真实车辆控制。
先走零售正常路径：提交 R001，服务持久化 O001，返回“已受理”；库存服务为 O001 预留 1 件，支付确认后创建履约任务，最终查询到完成。每步记录输入、输出、持久化证据和责任组件。接着让首次响应在网络中丢失，使用 R001 重试。预期仍返回 O001，库存只预留 1 件，支付与履约也各对应同一业务操作。若出现 O002，就说明请求幂等边界没有建立。
再把入口提高到每秒 2000 次，但在推演中只给后台每秒 1500 次的处理能力。记录入口拒绝数量、已受理数量、队列年龄和完成数量。超过等待期限的请求应得到可解释的状态，不能只从队列删除。将同一份表中的“入口成功率”与“业务完成率”分开，就能观察到：快速受理大量订单并不代表库存与履约能够及时跟上。
然后走汽车路径：检查车辆身份与目标版本，确认活动适用范围，下载并校验更新包，在满足安装条件后安装，启动后验证功能并上报结果。通知到达、下载完成和安装完成分别打点。让其中 2 台车辆在下载中断网，预期恢复后按协议继续下载或重新获取，不能因此记录为安装失败；再让 1 台车辆不满足电量条件，预期停留在待安装并报告原因。
对照时重点寻找“承诺点”。订单受理表示系统记住了请求，库存预留表示资源已暂时分配，付款成功表示资金状态已确认。汽车下载完成只表示内容已经到达，校验通过和安装验证通过承担不同责任。承诺点之后的失败通常需要补偿、恢复或人工处置，不能把界面状态退回初始值就当作事情从未发生。
最后写下 2 个候选方案。方案 A 让订单接口同步等待库存、支付和履约；方案 B 持久化后返回受理状态，再推进后台流程。对本案例选择 B，原因是高峰时可隔离慢环节并提供查询，但代价是状态更多、必须处理重复消息与超时。汽车侧也可异步推进任务，但安装授权必须独立检查安全前提。这就是简短 ADR：选择有依据，代价能验证，类比有边界。
5 体验与安全召回取舍
零售体验不能只看响应快慢。顾客更在意价格是否兑现、库存是否可信、支付后多久得到结果，以及失败后资金如何退回。高峰时可以暂缓非关键推荐、降低部分查询刷新频率，也可以让顾客进入有期限的等待状态；但不能为了入口成功率而隐藏库存不足。方案应列出可以降级的功能和必须保留的事实，例如订单状态查询、取消结果与资金处理进度。
汽车更新的用户体验还要服从安全边界。通知更快、覆盖更多车辆、安装更早，并不自动意味着方案更好。如果新版本影响关键功能，扩大范围前需要更充分的验证和监测。涉及安全召回时，还需由相应业务与安全责任人确定告知、维修或其他处置要求；云端“暂停推送”只是技术动作，不能替代对已受影响车辆的实际处理。
分批推进可以先覆盖少量符合条件的终端，确认结果后再扩大范围。批次需要代表性，不能只选择网络最好、配置完全相同的车辆，再把结果推广到所有车型与硬件版本。观察窗口要覆盖必要的启动和功能检查。零售发布也适合分批放量，但业务成功、库存一致和支付未知比例应纳入判断，单看接口错误率可能漏掉真实损害。
交互中的滑块只改变教学模型里的批次规模，用来观察覆盖速度与潜在影响范围。它不能推导真实故障概率，也不能代替车辆验证。较小批次通常限制首轮影响范围，却会增加推进轮数与等待时间；较大批次减少轮数，也会让监测发现问题之前已经开始执行的终端更多。最终阈值应由业务时限、支持能力、验证证据和风险容忍度共同确定。
成本也沿着取舍变化。零售需要支付常驻服务、峰值扩容、数据库、队列、监控和恢复演练的费用；汽车更新还要计入包体分发、终端回传以及失败车辆支持的成本。比较时固定时间窗口和业务量，例如 1 场持续 2 小时的大促或 1 次覆盖 10000 台车辆的活动，再列出固定费用与随量变化的费用。不能用单台实例的价格代表整条业务路径成本。
保留备用容量、跨可用区副本与较长日志会增加支出，却可能缩短中断和排查时间。反过来，无限保留日志也不等于负责，因为会增加访问面与检索负担。把每项费用对应到需求：副本支持什么故障恢复，日志支持哪类对账，分发能力满足多长时间内的下载目标。这样削减预算时，讨论的是可接受的能力变化，而非随意删除组件。
6 常见坑：中心系统单点扛峰值
常见反模式是所有流量都绕回中心的同一条路径：门店查库存、顾客刷新订单、车辆查询任务、终端下载文件，最后都占用同一组服务和数据库连接。入口增加实例以后，数据库连接先耗尽，超时引发重试，重试又带来更多请求。结果是业务流量尚未达到预计峰值，系统已经被自身的恢复行为放大压力。扩容入口只能解决入口本身的容量问题。
先画出依赖，再确定隔离方式。静态内容走分发层，查询和写入按实际一致性需求设计，订单后台工作限制并发，车辆诊断上传设置独立配额。隔离不意味着立刻拆成很多服务，也可以从资源池、队列和调用限额开始。关键是让低优先级流量无法耗尽创建订单和状态确认所需的资源，并且为被限流的客户端提供清楚的重试方式。
高可用要覆盖故障后的剩余容量。假设 2 个可用区平时各承担 50% 流量，失去其中 1 个后，另 1 个是否能接住关键请求，必须通过容量预算和演练判断。数据库切换、队列可达性、配置与密钥服务也需要纳入依赖检查。应用实例分布在多个可用区，只能说明应用层有分布，不能证明整个订单链路消除了单点。
恢复目标需要分开写：恢复业务需要多久，以及最多允许丢失多久的数据。对已经返回受理的订单，若要求已确认记录不丢失，就要明确持久化确认的条件，并说明故障切换如何满足承诺。若副本复制有延迟，切换后就可能缺少部分新记录。不能同时采用较弱的数据保护方式，又在方案里写绝对不丢失；具体复制机制本课不展开，但承诺与能力必须一致。
观察指标应从业务结果向依赖展开。订单完成率下降时，检查库存等待时间、支付未知数量、队列最老任务年龄，再看数据库与网络。车辆安装成功率下降时，先按车型、版本和阶段分组，判断是下载失败还是启动验证失败。平均值会掩盖局部故障，必须保留合适维度，同时控制明细权限。面板能快速缩小范围，比堆满所有系统指标更有用。
队列持续增长或车辆失败率越过约定阈值时，需要有明确的停止动作。零售可以收紧入口、暂停非关键任务并保护已受理订单；汽车可以停止扩大活动范围，并处理正在执行的终端。停止动作应有负责人、触发条件和恢复条件。没有恢复条件的“紧急限流”容易长期遗留，最后变成无人解释的业务损失。
7 案例：OTA 分区失败难回滚
某次教学案例中，活动准备把 10000 台车辆从 V1 更新到 V2。团队认为车辆有 2 个软件分区，更新写入备用分区，失败后切回原分区即可。首批 100 台下载与安装都顺利，于是扩大范围。随后部分车辆启动验证失败，另有车辆虽然能够启动，却因 V2 修改了共享配置而无法完整使用 V1。此时“存在旧分区”并没有带来预期的恢复能力。
先按证据拆开问题。下载校验成功只说明包体正确到达；备用分区写入成功只说明写入步骤完成；启动成功也不等于关键功能检查通过。共享配置、数据格式或外围部件版本可能没有随分区切换恢复。方案若只记录“安装成功”，便无法区分失败发生在哪里。需要同时记录原版本、目标版本、当前启动版本、验证结果和恢复尝试结果。
排查从暂停扩大范围开始，保留当前批次、车辆分组和故障时间。随后依据诊断证据区分网络中断、安装条件不足、写入失败、启动失败与功能验证失败。每类进入不同路径：网络问题等待重试，条件不足等待重新检查，安装或启动问题执行经验证的恢复策略，无法安全恢复的车辆转交相应支持流程。不能通过反复重启来替代分类，也不能对全部车辆无差别重发安装任务。
对照零售订单，类似错误是认为“数据库恢复到旧快照”就能撤销已经完成的业务。订单记录可以回退，外部支付与仓库发货却可能已经发生。恢复系统状态与补偿业务结果是不同工作。订单侧要按订单编号查询资金与履约事实，再决定退款、取消或人工处理；车辆侧要确认实际运行状态，再决定版本恢复或维修处置。两者都要求恢复动作依据当前事实执行。
案例的 ADR 应修订为：扩大活动前验证版本兼容与恢复条件，覆盖共享数据及关联部件；分阶段记录结果，达到明确标准后才确认新版本；保留暂停范围与支持流程。这里不展开启动器、分区切换和固件恢复内部实现，入门阶段先认识它们是必须由产品与工程证据保证的能力，架构图中的“回滚”箭头本身并不提供这些能力。
复盘也要检查首批样本为何没有暴露问题。如果首批全部使用新硬件与干净配置，便没有覆盖真实设备差异。后续批次应按适用条件纳入代表性组合，并明确不兼容终端的处理方法。对零售案例，则需要补充慢支付、库存竞争、重复回调和门店断网等测试条件。有效的试点不是证明最顺利的路径能走通，而是提供扩大范围所需的证据。
8 把行业峰值写进方案
把行业特点写进方案，首先要让峰值成为可计算的输入。零售写开售时刻、预计入口峰值、持续时间、查询放大比例和库存热点；汽车写活动覆盖规模、任务检查节奏、包体大小、下载窗口和安装分组。还要写正常情况下的基线，因为恢复积压时仍有新流量。缺少持续时间与流量构成的“支持每秒 2000 次”，无法支撑完整容量设计。
接着明确数据新鲜度和承诺边界。商品展示库存可以有短暂延迟，真正预留必须由权威服务确认；订单受理需要可恢复记录，付款未知不能直接视为失败。车辆诊断可以延迟上传，安装前置条件却需要按规定重新检查。将不同数据放在同一张“实时性要求”表中，写明允许延迟、权威来源和过期处理，能够避免所有数据都追求实时或所有操作都依赖缓存。
候选方案至少比较同步完成与异步受理的差别，或比较集中传输与内容分发的差别。比较维度包括用户等待、容量限制、故障影响、恢复难度和费用。选择异步以后，要把状态查询、幂等与对账成本计入；选择集中方案以后，也要写出适用规模和扩展触发条件。ADR 不要求篇幅很长，但不能只留下“考虑可扩展性，因此采用某架构”的结论。
成本估算应可追溯到负载。订单请求量影响服务与数据库操作，状态查询频率影响读流量，更新包大小乘以覆盖数量构成基础分发量，再考虑缓存、重试和分批窗口。费用尚不能精确时，可以列出低、中、高 3 档假设，标明最敏感的变量。容量与费用都受同一组业务输入约束，不能在容量表使用最大峰值，却在预算中只使用平日平均量。
风险表应记录触发条件、可观察信号、限制影响的动作、恢复负责人和残余影响。例如库存服务不可用时，入口仍可受理多少请求，等待多久后停止受理，已有订单如何查询；某车型安装验证失败时，停止哪个范围，其他组是否继续，以及谁确认恢复。还应标明哪些结论尚需压测、演练或业务签字。未知事项写出来，才能成为可推进的验证任务。
验收最后回到原始需求。用重复 R001 验证同一订单，用热点库存竞争验证不重复预留，用可用区失效验证关键路径恢复，用后台限速验证等待上限。汽车侧则检查分阶段上报、暂停扩批、失联终端重连后的任务状态和经过验证的恢复路径。所有演练先在隔离环境完成，并记录证据位置。方案至此才从组件清单变成能够评审、实施与复盘的业务承诺。
9 从零售与汽车方案走向医疗行业方案（P29）
零售与汽车的共同经验是，终端多、网络不稳和业务峰值会放大状态不清的问题。订单 API 通过明确受理、预留、支付和履约，把失败分成能够解释的阶段；OTA 通过检查、下载、安装和验证，把活动范围与恢复条件关联起来。跨行业迁移时，应该带走这些提问方式，再重新填写领域规则，而不是复制状态名称和超时数字。
进入 P29 医疗行业方案后，仍会遇到终端接入、业务高峰、数据交换与可用性，但身份权限、敏感信息、诊疗连续性与审计证据会占据更重要的位置。零售中可以等待的推荐查询，与诊疗现场需要及时取得的信息不能使用相同降级策略。汽车更新的安全前置检查也只能帮助建立意识，不能直接等同于医疗业务的专业判断与责任边界。
可以先保留本课的订单 API 作为对照基线：请求是否已受理，谁是权威数据来源，操作结果能否查询，重复请求如何处理，依赖失效时允许承诺什么。到了医疗场景，再逐项检查哪些答案需要变化。例如同样是离线缓存，是否允许保留、谁能访问、数据过期如何提醒，都必须依据具体使用环境重新确定。跨章节保持案例一致，是为了看清变化来源。
本课不要求掌握汽车控制软件、复杂库存算法或医疗标准内部细节。需要掌握的是把业务后果翻译成可评审条件：哪些失败可以重试，哪些必须先查询，哪些需要停止扩大影响，哪些必须交给具备职责的人处理。只要这些条件仍然空白，增加更多服务方框也不会让方案更完整。下一课将沿着这些问题，进一步讨论医疗场景的数据和连续服务要求。
放进方案里
在方案的“业务场景与容量”页，写明零售订单 API 的基线为每秒 200 次，大促入口预计每秒 2000 次，并注明持续时间、状态查询比例与热点商品范围。这些属于待验证假设。承诺页面区分“订单已受理”和“购买成功”：返回受理前必须保存可恢复记录，库存预留、支付确认和履约分别推进状态，客户端使用原请求标识重试并查询同一订单。
在架构选择页放入简短 ADR：比较同步完成全部操作与持久化后异步推进，选择后者以隔离慢依赖并吸收短时波动，同时承担状态查询、去重、超时与对账的实现成本。附上入口、库存、支付和履约的依赖图，注明每个阶段的权威数据来源。静态内容通过分发层提供，后台并发受到限制；关键依赖不可用时，按约定上限等待并停止新增承诺。
在容量与费用页分别列出入口处理、数据库、队列、观测、备用容量及内容分发的估算依据。用高峰持续时间计算积压，用高峰后的净处理能力计算清空时间，说明失去 1 个可用区后的关键路径容量。恢复时间和允许的数据损失分别填写，并以持久化与切换证据支撑，避免用多副本图标代替恢复承诺。
在行业风险页增加汽车 OTA 对照：车辆身份、适用版本、安装条件、分批范围和验证结果均有记录；发现异常可以暂停扩批，恢复必须覆盖共享数据与关联部件的兼容条件。最终验收附重复请求、库存竞争、依赖超时、可用区失效和更新失败分类的演练证据，标明负责人、停止条件、恢复条件以及尚未验证的假设。
10 小结：下一步医疗行业方案（P29）
零售订单 API 的关键是把入口峰值、库存承诺和履约事实连起来；汽车 OTA 提醒我们，文件到达、安装完成与安全恢复各有独立条件。完整方案应呈现需求、选项、ADR、费用、风险和高可用之间的对应关系。
自测时回答 3 个问题：接口超时后凭什么判断订单是否存在？队列增长后凭什么估计等待时间？保留旧软件分区后凭什么证明能够恢复？答案都应落到记录、条件与验证证据。P29 将继续使用这些提问方法，分析医疗行业的数据保护与服务连续性。