1 端边云协同方案要回答什么
零售订单 API 的调用者并不总在稳定的机房网络里。门店收银终端可能遇到无线网络抖动，门店到中心的线路可能中断，中心服务也可能正在切换。如果把“点击下单后调用中心接口”当成完整方案，网络正常时看起来简洁，网络异常时却很难回答：顾客是否已经下单，收银员能否继续操作，恢复后会不会重复扣库存。端边云协同从这些业务问题出发，安排不同位置的系统共同完成订单流程。
本课固定使用同一个案例：零售企业有 100 家门店，每店有 4 台收银终端。终端负责录入商品、展示结果；门店网关承担边缘服务；中心订单 API 管理正式订单，并与库存、支付等系统交互。示例假设门店高峰每分钟产生 30 个订单，每条待上传事件平均 2 KB，要求断开中心连接后仍可受理限定范围的订单，最长支持 30 分钟。这里的“受理”指本地持久保存购买意向并返回待确认凭据，不代表支付成功或中心库存已经扣减。
端、边、云首先是部署位置和责任范围。端靠近使用者，擅长即时交互与设备操作；边靠近门店，能够在局域网内协调多台终端并保存门店数据；云指中心侧服务，便于汇总跨店信息、维护全局规则和对接共享系统。同一个程序可以部署在不同位置，但位置改变后，能看到的状态、能够承诺的结果以及失联后的行为都要重新判断。
方案需要先写清体验目标与业务底线。体验目标可以是“门店网络正常时，本地受理响应的第 95 百分位不超过 300 毫秒”；业务底线可以是“离线订单不得显示已支付”“同一个请求重传不得生成多个正式订单”。还要明确哪些订单允许离线，例如限定为门店现货、限额内、无需实时优惠核验的订单。涉及跨店调货或必须在线授权的操作，应提示暂不可办，不能用缓存结果伪装成确定结果。
选择架构时至少比较 3 个选项：终端直接调用中心、终端保存待传请求、门店网关统一缓冲。直接调用部署简单，但中心链路故障会直接影响受理；终端缓冲可保留录入结果，但多个终端之间缺少统一视图；门店网关能提供门店级队列与规则，却增加设备运维和本地故障处理成本。应根据门店持续营业的价值选择，而不是因为“边缘”听起来更先进就引入网关。
本课选择门店网关统一受理符合离线条件的订单。这个选择依赖 2 个前提：终端仍能连接门店局域网，网关的持久存储可用。它不会自动解决门店停电、网关损坏或支付通道失联。因此，需求、选项、架构决策记录、成本、风险与高可用设计需要连起来写，后续每个机制都要能指向原来的业务承诺。
2 职责划分与状态同步
职责划分最容易出错的地方，是多个位置都认为自己拥有最终决定权。为了避免这个问题，我们把订单正式状态的权威来源设在中心订单服务，把门店待传队列的权威来源设在网关，把终端的显示状态视为可恢复的视图。终端退出应用后，应能向网关重新查询订单受理结果；网关上传成功后，应保存中心返回的正式订单标识，而不是只在内存中显示“已发送”。
订单可以经历“待确认、已确认、已拒绝、需人工处理”等业务状态。待确认表示网关已经可靠保存，但中心尚未裁决；已确认表示中心按业务规则接受订单；已拒绝需要带可理解的原因，例如库存不足；需人工处理用于自动规则无法安全收敛的例外。传输状态则另外记录为“待上传、上传中、待重试、已获确认”。业务状态与传输状态分开，才能表达“请求已经发出，但订单是否成立仍未知”。
终端开始录入时，为这次下单生成稳定的请求标识。网关将门店标识、请求标识、订单内容、内容摘要、创建时间、规则版本一起持久保存，再向终端返回受理凭据。同一个请求标识被再次提交时，应得到已有结果；如果标识相同而内容不同，应报告冲突。不能把“同一个标识”理解成允许任意覆盖，否则网络重试可能悄悄改掉已经受理的订单。
中心接收时，在明确的去重范围内检查请求标识。对于这个案例，范围可以定义为“企业标识、门店标识、请求标识”的组合。中心需要使去重记录、正式订单写入以及最终受理结果保持一致，再返回确认。这里不要求初学者掌握具体事务实现，但必须知道：如果先回复成功，随后订单落库失败，门店会错误地认为任务已经完成。幂等承诺也要注明保留期限，期限短于可能的重传周期，就仍有重复建单风险。
同步不只是把订单向上传。中心还要下发商品目录、可离线使用的价格规则、受理额度和规则有效期。网关接收完整版本并校验后再切换，终端使用网关当前生效的版本。不能把更新到一半的目录提供给收银员。订单应携带受理时的规则版本，中心才能解释当时为什么给出这个价格，并根据约定决定接受、拒绝或转人工。
状态变化也需要可追踪的依据。中心为订单结果提供版本号，网关只接受符合协议的后续版本，终端重新查询时取最新已知结果。版本号用于判断同一订单状态的先后关系，墙上时钟用于记录和解释发生时间，两者不能互相替代。对库存、价格、订单结果分别定义权威来源与更新规则，比给所有数据笼统承诺“最终一致”更容易实现和验收。
3 断连、缓冲与冲突合并
断连并不是看到 1 次超时就能完全确认的事实。超时可能发生在请求没有到达中心之前，也可能发生在中心已经提交订单、确认报文却丢失之后。因此，网关面对超时，应将请求保留为结果未知并按协议重试。新的重试继续使用原请求标识，中心返回已有结果即可。重试的目的在于找到同一件事的结果，而不是重新表达另一次购买。
缓冲队列应写入持久介质，并具有明确容量。按每分钟 30 个订单、断连 30 分钟计算，单店需要保存 900 个待传订单；按每条事件 2 KB 计算，原始事件约为 1800 KB。这个数只是载荷估算，实际还要计入索引、日志、确认记录、文件系统开销和安全余量。若同时保存图片或详细小票，必须另算，不能继续沿用这个结果。
容量足够也不代表可以无限离线。规则会过期，门店共享库存会发生变化，未确认订单积压会增加顾客等待。因此需要同时设定队列容量、最长离线时间和离线受理额度。达到任意边界时停止新受理，并保留已有队列。界面要明确展示暂停原因。删除最早的未确认订单来腾空间，会破坏已经给顾客的承诺，不能作为默认降级策略。
恢复连接后，网关按受控速率重放。重试之间设置递增等待并加入随机变化，避免大量门店在中心恢复时同时猛发。上传失败的订单要区分临时错误与确定拒绝：网络超时可以重试，商品被禁止销售等明确业务拒绝则应结束自动重试并通知处理。重试次数与人工介入阈值是运维规则，不应通过“永远重试”隐藏异常。
冲突合并需要服从数据含义。收银员补充的备注在业务允许时可以追加，并保留来源；订单数量、支付结果和库存占用则不能简单相加，也不能用时间较晚的值覆盖。比如门店离线受理了最后 1 件商品，而中心已把它分配给其他渠道，中心应按约定拒绝或转入缺货处理。协议只能帮助系统一致地执行取舍，不能凭空创造库存。
对离线销售，可以预先分配门店可用额度，降低跨渠道争抢；也可以允许先受理再由中心确认，让顾客承担等待确认的体验。前者减少冲突，但额度分配和回收需要管理，其他门店也可能无法使用暂时闲置的额度；后者配置简单，却需要清晰的拒绝通知与补偿流程。入门阶段先选择并写清其中的业务策略，复杂的跨节点并发算法留到有明确需求时再讨论。
需要特别区分请求去重与业务补偿。去重避免同一请求产生重复订单，补偿处理已经发生但需要纠正的业务动作，例如正式取消订单后释放库存。删除本地队列不是业务取消，撤销界面显示也不等于中心撤销。对结果未知的订单，用户提出取消时仍需记录取消意图，查询中心结果并按协议处理，不能直接丢弃原请求。
4 动手：演练一次断网恢复
这次演练使用测试门店、模拟商品与模拟支付，不连接真实扣款通道。准备 1 台终端、1 个可持久保存队列的门店网关和 1 个测试中心订单 API。将离线允许范围限制为指定商品和小额订单，设置规则有效期、队列上限与上传速率。没有完整程序时，也可以使用接口模拟器与记录表演练，但必须保留请求标识、状态和确认结果这些关键字段。
先在网络正常时提交请求 A，记录终端获得凭据的时点、网关持久保存的时点，以及中心正式确认的时点。检查顺序是否符合协议：网关可靠保存后才返回待确认，中心提交完成后才返回已确认。再次提交完全相同的请求 A，预期仍得到同一个正式订单。随后使用相同标识修改商品数量，预期收到内容冲突提示，而不是新建或覆盖订单。
接着只阻断网关到中心的链路，保持终端到网关的局域网连接。提交请求 B 与请求 C，观察界面应显示待确认，网关应有 2 条待传记录，中心暂时查不到对应正式订单。重启网关服务后再次查询，记录仍应存在。这个动作验证的是持久恢复能力；如果只在页面上看见待确认，却无法重启恢复，就没有证明本地受理可靠。
恢复连接，先让中心接受请求 B，却故意丢弃返回给网关的确认。网关此时仍认为结果未知，继续重试原请求 B。预期中心只保留 1 个正式订单，并返回已有结果。随后正常上传请求 C，观察待传队列逐步减少。最后再向中心查询 B 与 C，核对正式订单标识、业务状态与网关保存的结果相同，不能仅凭队列已经清空就判定成功。
演练还要覆盖业务拒绝。将请求 D 使用的商品设为中心不可售，让网关在规则仍允许的离线窗口内受理，再恢复上传。预期 D 进入已拒绝或需人工处理状态，并能关联到原受理凭据；终端应显示后续处理方式。这里观察的是系统能否完整表达失败，不是要求所有离线请求最终都成功。
用记录表保存每个请求的输入、故障注入位置、预期状态、实际状态与证据位置。验收至少包含 4 个结果：断连期间限定订单可受理，重启后未确认记录不丢，确认丢失后的重试不会重复建单，明确拒绝能够到达操作人员。测试结束恢复网络、规则和队列配置，并清理测试订单。真实方案还应增加存储满、规则过期、恢复积压等演练，把暂未验证的情况明确列为缺口。
5 中心管控与端侧自治取舍
中心管控让规则发布、权限审计与跨店汇总更加集中，但中心不可达时，也可能让本地业务停下来。端侧自治让门店在限定条件下继续营业，却会引入规则过期、数据冲突、设备丢失和维护分散等成本。取舍应围绕业务动作展开：商品录入可以本地完成，正式支付授权依赖支付系统，跨店库存承诺通常需要中心裁决，打印待确认凭据可以由门店执行。
可以把自治边界写成规则表：动作是什么，依赖什么数据，离线时是否允许，额度是多少，规则何时过期，失败后由谁处理。对于本例，网关可以在价格规则有效且额度充足时受理现货购买意向；不能自行把未收到结果的支付标记成功，也不能把中心签发的权限提升规则改成本地永久有效。自治范围清楚，才能判断风险是否可接受。
成本比较需要把新增组件算进去。门店网关涉及采购或租赁、安装、存储、备件、远程运维和现场更换；中心涉及同步 API、去重记录、结果查询、监控与峰值容量；人员需要维护规则版本、演练故障并处理例外。只看到“减少中心请求量”，很容易漏掉大量门店上的持续维护成本。若门店允许短暂停业，直接调用中心可能更合适。
可以用统一时间范围建立成本表，例如按月汇总固定支出、正常流量支出、恢复流量支出与人工处置成本。收益则对应可测量目标，例如断连期间保留的有效订单、减少的人工补录时间。暂时无法可靠货币化的顾客体验可以单独列出，避免把所有收益硬凑成精确金额。示例数据用于估算方法，最终价格和故障频率应由实际调查替换。
高可用也要按故障域拆开。中心多可用区能降低中心单个机房故障的影响，却无法修复门店局域网或网关磁盘。门店可准备备用设备，并演练恢复队列与设备身份；若要求主网关损坏后仍无损继续受理，就需要额外的本地数据保护与切换协议。只有备用硬件而没有可恢复数据，不能承诺已经受理的订单不丢。
门店引入冗余时，还要防止 2 个网关同时对外声称拥有同一份受理额度。初步方案可以采用明确的主备角色与受控切换，在无法确认原主状态时暂停相关操作。自动切换速度越快，对角色仲裁和数据同步的要求通常越高。方案应声明支持到哪种故障、恢复需要多久、允许丢失多少已确认保存的数据，并用演练证明这些指标。
6 常见坑：所有逻辑上云
把所有业务逻辑放在中心，容易形成“终端只负责展示，所以门店很简单”的错觉。即使业务裁决集中，终端仍要处理超时、重复点击、未知结果和用户退出。若这些行为没有统一协议，每个终端就会各自猜测中心状态。门店操作人员看到的可能是失败，中心却已经生成订单，随后重复提交又形成新的购买请求。
另一个坑是为了离线，把全部中心逻辑复制到网关。完整复制会使规则发布、依赖服务和安全边界变得复杂，门店版本不一致时更难排查。本例只把必要的离线受理规则与持久队列放到网关，中心继续裁决正式订单。对于必须实时查询的数据，明确限制离线动作，通常比复制全部系统更容易建立可信的边界。
还要避免把“网关返回成功”写成含义不明的单个布尔值。成功可能指已收到、已持久保存、中心已受理或业务已完成，这些承诺差别很大。API 应返回清晰状态与可查询凭据，界面文字应与状态对应。待确认订单可以显示“已保存，等待中心确认”，但不应使用与正式订单相同的完成提示，诱导操作人员据此发货或承诺支付成功。
监控不能只看中心接口可用率。中心看起来健康时，某家门店可能已断连 20 分钟。应观察每店连接状态、规则剩余有效期、队列长度、最老待确认时长、重试比例和业务拒绝率。队列长度反映数量，最老待确认时长反映承诺拖延程度；低流量门店只有 1 条积压时，后者尤其关键。告警应能定位到门店与责任团队，并提供安全的查询入口。
安全责任同样不能因数据暂存在门店而消失。网关只保存必要订单字段，限制本地访问，使用受保护的设备身份访问中心，传输时校验对端。队列中的顾客信息要有保留期限和删除流程，日志应避免复制敏感字段。设备丢失后要能撤销身份，恢复设备也不能沿用不受控的共享密钥。这些措施服务于明确的数据与权限边界，不需要把入门方案展开成完整密码系统设计。
7 案例：时钟不同步导致状态错乱
某门店网关的时钟快了 8 分钟。收银员离线受理订单 E，网关写入本地时间 10:08；实际时间是 10:00。中心在 10:02 收到上传并确认订单，记录自己的时间 10:02。旧实现把“时间戳更大”解释为“状态更新”，于是网关认为自己的待确认状态比中心的已确认状态更新，拒绝应用中心结果。订单在中心已经成立，门店界面却一直显示等待。
值班人员最初看到队列反复重试，怀疑中心处理缓慢。如果直接重建订单，可能引入重复业务；如果清空队列，又可能失去受理记录。合理的排查从同一个请求标识开始：中心是否存在正式订单，中心返回过什么版本，网关收到确认后为什么没有应用，终端最后显示哪个状态。先重建事件关系，再判断组件故障，能避免把结果未知的订单当作不存在。
日志证据显示，中心确认已到达网关，网关却因时间戳较小而丢弃结果。问题并非网络没有恢复，而是协议使用了不可靠的排序依据。修复后，中心负责的订单结果按中心分配的订单版本应用；门店的受理记录保留本地发生时间与中心接收时间，供审计解释。终端显示状态从网关保存的业务结果读取，不再自行比较来自不同机器的时间。
时间同步仍然需要维护，因为规则过期、证书有效期与故障分析都依赖合理时间。但时间同步不能代替状态协议。跨机器时间可能存在偏差，校时也可能带来跳变；本机测量等待时长应使用适合持续计时的机制，不能简单用墙上时间相减。入门阶段记住边界即可：时间帮助观察事件，业务版本与合法状态转换决定如何接纳事件。
回归演练应分别模拟时钟偏快、偏慢以及旧消息延迟到达。预期已确认结果不会被旧的待确认视图覆盖，重复结果不改变已完成的状态，不合法的转换会留下可排查记录。对于规则有效期，如果设备时间明显不可信，网关应按约定收缩离线受理范围或暂停受理，并提示需要校时。不能因为已经修复状态排序，就继续允许使用无法判断是否过期的规则。
这次事故在架构决策记录中留下明确约束：跨节点业务状态不按设备时间戳竞争覆盖。记录同时说明适用范围、采用的中心版本规则、兼容旧消息的方法和验证证据。事故复盘的价值在于把隐含假设变成可检查的协议条款，使新增终端与替换网关继续遵守同样的状态语义。
8 把协同协议写进方案
协同协议不必从大量字段开始，而应先列出业务承诺。本例承诺网关持久保存后返回待确认；中心按请求标识处理重复提交；明确拒绝会反馈给门店；超出离线边界会停止新受理。每条承诺都对应接口、状态、持久记录与测试。如果方案只有组件连接图，没有这些约定，实施团队仍然会在异常路径上各自补全规则。
接口表至少包括提交订单、查询受理结果、上传待确认订单、查询中心结果和获取规则版本。对每个接口写明调用方、认证身份、必要字段、返回状态、超时后的动作以及重复调用语义。请求标识的生成与去重范围要统一；同标识异内容如何处理要明确；中心结果保留多久、门店断连多久后必须人工核对，也要能相互匹配。
架构决策记录可以以“采用门店网关保存限定离线订单”为题。背景写持续营业需求与网络条件；候选项写终端直连、终端缓冲、网关缓冲；决定写选择网关及原因；后果写设备成本、规则维护和冲突处置责任。还要写重新评估条件，例如门店离线需求减少，或现有网关已无法满足恢复时间。这样决策能随事实调整，而不是永久绑定某个组件。
容量与恢复指标应连在一起计算。若断连 30 分钟积压 900 条，恢复后每分钟最多上传 90 条，同时仍有每分钟 30 条新订单进入，那么净消化速度是每分钟 60 条，理想清空时间为 15 分钟。这个估算忽略了重试、中心限流与业务处理延迟，实际验收应留出余量。若上传能力只等于新增速度，积压就不会下降，线路恢复并不意味着业务已经恢复。
风险表应写触发条件、影响、预防、发现方法和责任人。例如磁盘空间不足会阻止持久受理，通过容量预留与提前告警降低风险；规则过期会使离线价格失去依据，通过有效期控制暂停受理；网关损坏可能使待传数据暂时不可用，通过备份恢复或符合目标的本地冗余降低影响。不能把“加强监控”同时当作预防、恢复和责任分配的答案。
验收材料要覆盖正常链路、断连链路和恢复链路。既看响应时间，也看重复订单数量、未确认记录是否丢失、拒绝结果是否可达、积压清空是否达标。运维手册应规定谁能暂停门店受理、谁能恢复设备身份、人工核对如何回填结果。涉及库存与支付的补偿必须走相应业务接口，避免用直接修改数据库绕过原有规则。
9 从端边云协同走向AI 大模型落地方案（P31）
端边云协同解决了计算与数据放在哪里、断连时如何行动、恢复后如何对齐的问题。进入 AI 大模型场景，这些问题仍然存在。零售订单 API 可以增加订单咨询、商品解释或异常摘要能力，但生成的文本不会自动成为可信的订单状态。模型回答“可以取消”与订单系统已经完成取消，是不同的业务事实。
延续本例，可以让终端提供交互入口，门店网关缓存经批准的说明材料，中心服务管理模型调用与订单工具接口。断连时只展示可用的本地知识，并说明无法查询最新订单；联网后再通过有权限的接口获取结果。模型提出的操作若涉及改价、取消或退款，需要经过现有业务校验与授权流程，不能因为语言表达流畅就跳过系统边界。
本课的队列、版本与可观测性也能迁移过去：请求需要稳定标识，知识材料需要版本，工具调用需要明确结果，超时后需要查询真实执行状态。下一课再讨论模型能力选择、知识接入、评估与成本等问题。本课先把订单系统本身的确定事实和恢复机制建立好，为 AI 功能提供可依赖的业务底座。
放进方案里
在零售订单 API 方案中新增“端边云协同”条款，先声明适用范围：100 家门店，每店 4 台终端，网关可在中心断连后继续受理限定现货订单，最长 30 分钟。待确认仅代表本地持久保存，支付、库存与正式订单状态以对应权威系统为准。跨店调货及需要实时授权的动作在断连时暂停。
职责图标明终端负责录入与展示、网关负责规则缓存和待传队列、中心负责正式裁决。协议写明请求标识、规则版本、业务状态与传输状态，规定持久保存后才回复受理；重复提交返回已有结果；同标识异内容报告冲突；中心结果按业务版本应用。超时保留未知状态，原请求重试；明确拒绝通知门店并进入规定的处理流程。
架构决策记录比较直连、终端缓冲、网关缓冲，并说明选择网关的持续营业收益与维护成本。容量按单店每分钟 30 条、断连 30 分钟估算为 900 条待传事件，另计存储开销与余量。恢复上传上限为每分钟 90 条时，在新增每分钟 30 条的假设下，理想清空时间为 15 分钟，实际目标通过压测确定。
风险与高可用条款覆盖中心故障、门店断网、网关损坏、存储满、规则过期与时钟异常，逐项写清检测指标、停止受理条件、恢复步骤和责任人。主备切换必须避免重复使用离线额度，备用设备必须具备匹配目标的数据恢复能力。验收提交正常下单、持久恢复、确认丢失重试、业务拒绝和积压消化的证据，并记录尚未覆盖的故障。成本表同时包含门店设备、中心容量、监控、现场维护与人工核对，作为持续运营预算。
10 小结：下一步AI 大模型落地方案（P31）
端边云协同的核心是把业务承诺分配给合适的位置，并为失联、重试和恢复写出可以执行的协议。对零售订单 API，要分清本地受理与正式确认，用稳定请求标识处理重传，用业务版本处理状态先后，用容量和恢复速率约束持续营业能力。
自测时可以回答 3 个问题：中心已经提交但确认丢失，网关为什么必须复用原请求标识？每分钟上传 30 条且新增 30 条时，积压为什么无法清空？网关时钟快了 8 分钟，为什么不能靠最后时间戳决定订单状态？如果能够从承诺、状态和证据解释答案，就可以进入 P31，将 AI 大模型能力接入这套有明确边界的订单方案。